XY Graph Freezing

[Wes1s]

Hello,

This question is about the XY Graph control freezing at seemingly random times. I am continuously plotting multiplot data in an XY Graph. The data is coming from a shared variable (Array of Doubles). Element one is Time (I use Convert to TimeStamp) and it is used as the X coordinate for the remaining 4 elements. I aggregate the data using a Shift Register in a while loop and then plot the resulting data. I find that the XY Graph just stops updating at seemingly random times - sometimes after 2 points are plotted, sometimes after 10,000. 

Items to note:

- The data from the Shared Variable never stops coming in, and it does continue to change. I can drop an indicator on the wire and see the updating values.

- Wiring the same data to a Waveform Chart shows continuous updates

- Changing the X axis Display Format typically makes it work again for a while, but it always eventually freezes

- Copying into a new VI does not help

- Replacing the XY Graph or using a different kind (Like system control) does not help

- Restarting the VI without changing anything typically makes it work

- Using LabVIEW 2012 SP1

Has anybody seen this before? Any suggestions on how to fix it? I couldn't find any related posts.

My end goal is to have a continuously updating multiplot graph on my Windows Host using my timestamp values (The data is coming in from a cRIO using Scan Engine).

Thanks in advance!

[CertifiNATEtion]

Hi Wes1s, 

I downloaded your VI and generated some random data using the VI below, and I did not experience any freezing behavior on the XY Graph. 

If you generate the data on the PC, rather than the cRIO do you still see the same behavior? This would let us know if it is the Shared Variable Engine is messing up, or if it is something related to LabVIEW. 

Please let me know

-N

[Wes1s]

Ok, we might be on the right track. For some reason (at least when it stalls immediately) I am receiving a value of 0 for my TimeStamp. So I think what is happening is that the X Scale auto-scales and therefore you don't see any changes because the timescale is so wide. So then, the real issue is actually the shared variable. That poses the question of why am I getting a 0 the first time I run the VI?

This is the specific behavior:

• RT VI is running continuously - so there is never a time when the Shared Variable doesn't hold a value
• When I open my host VI and run it, the first value I receive for all values is 0
• When I abort that VI and re-run it, the first value I receive for time is the actual time
• I can close the host VI and reopen it, and I will get the same behavior
• If I FTP over my log file from the cRIO I do not see any time values of 0 (I log and send the time & temp data from the same wire)

[CertifiNATEtion]

Hi Wes1s, 

You could parse the 0's out of the timestamp, as a work-around. 

What could be happening is the shared variable is being read incorrectly, or the read is timing out, I believe the default behavior of the time out is to return a default value (0). You could also check the timed out? output to see if it is timing out on the read. 

-N

[Wes1s]

Oook. You have officially led me to the answer:

Shared Variables at timeout return their last known value. I always thought the last known value was what was hosted in the Shared Variable Engine, but it's apparently the last known value of the accessing platform (Host in this case). Therefore, when the VI starts, or even if I modify the block diagram, it returns 0 until it retrieves the most recent value from the Shared Variable Engine. Any successive timeouts just reports duplicate values of the last read.

So my solution is to place a Shared Variable read in my initialization code with a longer timeout. Once it receives its first value then the rest will behave properly. 

Thank you much for your help!

[CertifiNATEtion]

Hi Wes1s, 

Glad we could help!

Enjoy your weekend!

-N