Craig Smith
That was easy!
- Joined
- May 25, 2001
We have recently heard a lot about two problems in C-Com WP that I would like to tell everyone what we have found about them and how to resolve them.
The first problem addresses a couple other active threads here, and that is the problem with the floating cursor in a 3D table (VE table, spark table, target a/f table) showing half of the RPM value shown in the dashboard. As mentioned here in another post, I was able to duplicate this problem in a table using a dashboard WITHOUT scaled RPM as one of the sensors. If I had just RPM, the cursor would show half of the value shown in the RPM sensor. It was immediately cured by adding the scaled RPM sensor to that dashboard. If anyone is experiencing this problem with the scaled RPM sensor in the dashboard for that table, please reply to this post and let me know that.
The second problem has to do with data in the 2D tables (warmup enrichment, idle speed, etc.) being corrupted, often resulting in large spikes and dips in the graph. We have found that this is caused when the user uses the up and down arrow keys to manipulate points on the graph. When you hold down the up/down arrow keys to raise and lower the graphs, the PC attempts to send a command to the ECU for every teeny little step shown in the graph. For example, if you are trying to raise a value from 10 to 20, and the steps are in .1 increments, there will be 100 increments to be made in order for this to happen. Holding down the arrow key to get there causes these increments to happen at a much higher speed. Because of a variance in the method and rate at which Windows sends these commands to the ECU, this can overload the ECU and corrupt the data in that graph. You won't see it on the screen until you close the graph and reopen it. The way to avoid this is to avoid holding down the arrow keys to edit these graphs. You can either type in the value that you want at that point, use the mouse to drag the line to the desired location, or use one of the trim functions (additive, percentage, etc.) to alter that value.
We will be addressing both of these issues in future versions of C-Com WP, hopefully very soon. Hopefully this answers a lot of questions for a lot of people. It was difficult for us to figure out how to duplicate these problems, but once we did it was much easier to find a resolution. Thanks to everyone for your input and patience on all this.
Again, if anyone finds anything that contradicts the findings I am reporting here, please reply to this post with specific information on what you have done.
Since I know this will be the next thing that everyone will ask, I have NO idea how we are going to handle upgrades at this point. Please allow us some time to get that figured out. We want everyone to have a properly working version of C-Com WP and we are on the case. In the mean time, the workarounds described above should yield good results. Thanks again to everyone for your input!
The first problem addresses a couple other active threads here, and that is the problem with the floating cursor in a 3D table (VE table, spark table, target a/f table) showing half of the RPM value shown in the dashboard. As mentioned here in another post, I was able to duplicate this problem in a table using a dashboard WITHOUT scaled RPM as one of the sensors. If I had just RPM, the cursor would show half of the value shown in the RPM sensor. It was immediately cured by adding the scaled RPM sensor to that dashboard. If anyone is experiencing this problem with the scaled RPM sensor in the dashboard for that table, please reply to this post and let me know that.
The second problem has to do with data in the 2D tables (warmup enrichment, idle speed, etc.) being corrupted, often resulting in large spikes and dips in the graph. We have found that this is caused when the user uses the up and down arrow keys to manipulate points on the graph. When you hold down the up/down arrow keys to raise and lower the graphs, the PC attempts to send a command to the ECU for every teeny little step shown in the graph. For example, if you are trying to raise a value from 10 to 20, and the steps are in .1 increments, there will be 100 increments to be made in order for this to happen. Holding down the arrow key to get there causes these increments to happen at a much higher speed. Because of a variance in the method and rate at which Windows sends these commands to the ECU, this can overload the ECU and corrupt the data in that graph. You won't see it on the screen until you close the graph and reopen it. The way to avoid this is to avoid holding down the arrow keys to edit these graphs. You can either type in the value that you want at that point, use the mouse to drag the line to the desired location, or use one of the trim functions (additive, percentage, etc.) to alter that value.
We will be addressing both of these issues in future versions of C-Com WP, hopefully very soon. Hopefully this answers a lot of questions for a lot of people. It was difficult for us to figure out how to duplicate these problems, but once we did it was much easier to find a resolution. Thanks to everyone for your input and patience on all this.
Again, if anyone finds anything that contradicts the findings I am reporting here, please reply to this post with specific information on what you have done.
Since I know this will be the next thing that everyone will ask, I have NO idea how we are going to handle upgrades at this point. Please allow us some time to get that figured out. We want everyone to have a properly working version of C-Com WP and we are on the case. In the mean time, the workarounds described above should yield good results. Thanks again to everyone for your input!
