What makes chart go wonky?

[altenbach]

So it seem this bug only shows under stress and somehow the UI thread gets neglected.

Not that I would ever recommend that setting, but I wonder if setting the chart to "synchronous display" would make a difference. Just curious.

[JeffL]

Ben, I've sent you the email. Just let me know when you've uploaded your files.

[Ben]

I have passed along that app. I hopes it acts up for you.

Ben

[JeffL]

Ben, I took out the one missing VI and ran the program for 10 minutes. I did not see any wonkiness on any of the many charts, even with logging enabled. Is there something I'm missing?

[Ben]

---

JeffL wrote:
Ben, I took out the one missing VI and ran the program for 10 minutes. I did not see any wonkiness on any of the many charts, even with logging enabled. Is there something I'm missing?

---

Sorry about the false attempt there Jeff.

That code was the pre-delivered version of the app. The actual final version will never see the light of day again*, so I'll just have to find another example. (oh bother!)

Ben

* Running on secure machine inside barbed wire fences and 20 foot crash barriers with armed guards.

[CoastalMaineBird]

Here's another instance of chart misbehavior.

This time the average CPU usage was 4-6 %.  The issue with writing the debugging files is gone.

But I switched tabs from one of the text tabs to the charts tab at 20:51:25, so the instantaneous CPU load might be high.

 The charts are fed at 2 Hz regardless of whether their tab is showing or not. 

[JeffL]

Hi everyone,

I'd still be interested in seeing if it's still a problem after the 2009 installation - I'm told there are some graphical improvements (for tabs, too).

What if you modify the programs to use defer panel updates (property node for the front panel)? Are you able to observe the problem regularly or prevent it from happening (i.e. control when the front panel actually updates)?

[CoastalMaineBird]

What if you modify the programs to use defer panel updates (property node for the front panel)?

I forgot to mention it before, but I am already using DEFER UPDATES.

The DISPLAY event triggers an ACTION in my code, and I defer updates before the action, and un-defer them afterwards.

Here is another shot.  This is an actual test and right about the time the test was over, the display hiccupped.

In this case the CPU was loaded at 6-8 %, although the instantaneous load may have been much higher, since I enable some buttons, disable some buttons, and do other things when the test is over.

The chart doesn't stop when my test is over, although the program switches to a different tab when that happens.  When I switched back, it looked like this, with the messed-up Y gridlines.

At 11:45:14 the test started, 408 samples later would be  11:45:54.8, which is where the glitch starts.

 

[JeffL]

I just realized that you are using Vista (I realize now you said that at the beginning of the first post). I'm wondering if it's the difference here.

Ben, do you use XP or Vista when you see this issue arise?

[CoastalMaineBird]

I saw it on Win2K - I never used XP.