I think maybe I'm missing something basic here, but I don't know what it is.
I have two vi's with identical charts. One vi is running on a cRio with the embedded ui enabled, and the other vi runs on a host computer. I take data on the cRio and share it with the Host via a shared variable. I plot the data when received on a chart in the embedded vi, and I plot the same data on a chart in the Host ui as it comes in via the shared variable. Both charts have X-axis auto-scaling turned off, and are set to view equal times on the X-axis.
On the embedded vi, the chart behaves as i expect. I put new data in with each loop and the chart "fills up" from the right so that the data spans the entire viewport and then scrolls
The chart on the host however, doesn't "fill up". Data comes in correctly through the shared variable, and shows up at the right side of the chart, but it just gets over written each pass...in other words, it doesn't fill up, and doesn't scroll.
I verified that they are receiving the same data each iteration by zooming into just the new data portion and comparing them, and they are identical.
can someone help me understand what's happening here?
I can only think that one is a chart and one is a graph.
no, they are both definitely charts. I copy/pasted the one on the cRio to the one on the Host. I even went through methodically and checked that their settings are all the same.
Without a VI we can look at, I don't know how you expect us to help.
My guess is that your chart is history is much smaller than what you have the X axis range set for.
Both "Chart History Lengths" are the same (1024). Here is the vi that's on the host. The shared data comes in as an array of waveforms, I have a control to select which is shown...
The vi that's on the cRio is a bit more complicated. I can try to get a good representation of the important part if you think it would help.
Edit to add: I upped the Chart History Length on the host vi to 10240 to see if it changed anything and it didn't.
Here is what I'm doing in the cRio vi. I don't think this will help, but maybe... it's based on the "Voltage - Continuous Input.vi" program in the "Demonstration of Porting DAQmx Code.lvprog" project that's in "Find Examples..."
When you read in the data you're spinning the loop super fast. So it reads the same small waveform over and over.
You need a queueing system so that you don't add data that you've added before. Since waveforms have timestamps, it is the same data piled on top 10 or 100 times over and over.
A simple way to do this might to be to send out the "i" variable from the cRio bundled into a cluster with the waveform. Then only write to the graph on the local VI if the "i" value changes.
A better way would be to use an actual queue data type, but that's more complex.
Kyle... that worked! I could hug you.
I was going along on the idea that the loop didn't execute until the shared variable changed, but I guess that was naive
I didn't bundle the i with the waveform, just passed it through on its own and check it against the previous value before bothering with reading the shared waveform shared variable.
Is this a good place to start regarding queued data types?
Well, yes, that is where to learn about the "Queue" data type in LabVIEW, but since it looks like you're using a network shared variable it doesn't apply to this exact situation. The "Queue" data type in LabVIEW is only local to one application on one PC.
In this situation, I was more referring to knowing using a queue in the sense that it's one of the 8 fundamental data structures in programming.
The main part of a queue that applies here is that you need to have a way of sending data that:
* Is (usually) consumed in just one place
* Can come from one place or many places
* Ensures data is processed in order (first-in, first-out)
* Is lossless and doesn't duplicate data
Network shared variables look like they do have a FIFO setting, which kind of does this except if there isn't a new variable then you get the last one repeated over and over. So it doesn't meet that last requirement without some form of duplication checking. Without the FIFO option, it doesn't meet most of those requirements.
Your code is working OK now because your program is super simple, but a "proper" queue system would continue to work if there was a delay in your program on one end (due to the computer freezing up, a brief network connection drop, a dialog box halting execution, etc.) and as soon as the delay was over and everything resumed, your chart would still be OK. As it is now, if your chart drawing on the client PC gets paused, you just never see the missing data and you'll get a big gap.