10-17-2009 09:37 AM
OK, so I implemented the code shown in the example VI above into my real project, since I am trying to implement. The only difference is that there are TWO charts and TWO switches in the real case.
But I just react to the switch change by assigning Scale #1 to plot #1 or plot #0 and if the switch is set to SAME, then I copy SCale0.Range to Scale 1.Range, every display cycle.
But it showed a NEW behavior: when the chart gets full, it just refuses to scroll !
I checked the code over and over and there's no difference between the example and my real project..... except:
My real project does a DEFER PANEL UPDATES when it does new data to the graph.
If I disable that, it works just like the example.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
10-19-2009 09:53 AM
10-19-2009 10:00 AM
JeffL wrote:
Steve, I was able to see the grid lines situation as you showed in that VI in LV 2009f2. Ben, you spoke with Chris on the phone and we've escalated the issue to R&D on CAR 192152.
Thank you!
Ben
10-19-2009 10:02 AM
Steve, I was able to see the grid lines situation as you showed in that VI in LV 2009f2.
Great. I can call you as a witness at my insanity hearings.... 
Blog for (mostly LabVIEW) programmers: Tips And Tricks
10-20-2009 10:24 AM
02-11-2010 11:20 AM - edited 02-11-2010 11:23 AM
More wonkyness, same program, same charts.
This time, when I started a test 8-9 seconds into the data, the bottom plots shot up, went BACKWARDS (left) and started drawing crap over there.
In spite of the AUTOSCALE Y property being ON, you can see that the top chart is NOT autoscaling.
It's not so obvious in the bottom one, but it's AUTOSCALE Y property is ON, and it is ALSO not autoscaling.
If I turn AUTOSCALE Y OFF, nothing changes.
If I then turn it ON, it autoscales, and the data appears like it should.
Maybe the AUTOSCALE code is wonky, and drawing data outside the existing scale causes corruption of some kind....
Blog for (mostly LabVIEW) programmers: Tips And Tricks
02-12-2010 10:43 AM
05-20-2010 02:31 PM
OK, I have simplified this and can now reproduce it on demand. See attached VI.
This VI is similar in technique to the real code that shows this bug.
To make the bug happen, set the DISABLE UPDATE DEFERMENT constant to FALSE (on the diagram).
Then run the VI and play with the SAME SCALE switches (that will accelerate it's appearance, thogh it will eventually appear without it).
Set that constant TRUE and the bug will not appear.
I deferred panel updates, because the update process in the real case updates two charts, and 60+ indicators on other tabs.
The logic is that the EVENT structure is notified of new data and puts it into a Shift Reg. An ACTION is posted into the action queue.
The next loop sees the non-empty queue and DEFERS UPDATES while it processes the action.
In this simplified example, the only action is PLOT DATA.
When the plot is done, the next loop finds an empty queue and thus terminates the DEFER status.
It seems like the chart gets confused when scale changes occur while DEFER UPDATES is on.
My next step is to test this in LV 2009.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
05-20-2010 02:34 PM
Alas, this bug is in 2009 (9.0f3) as well:
Blog for (mostly LabVIEW) programmers: Tips And Tricks
05-20-2010 02:38 PM
CoastalMaineBird wrote:OK, I have simplified this and can now reproduce it on demand. See attached VI.
...
It seems like the chart gets confused when scale changes occur while DEFER UPDATES is on.
...
I can confirm that my apps that exibited that flaw DID USE Defer FP updates.
Nice work Steve!
Ben