Synchronously displaying data in 2 graphs located in different VIs

[Nemanja123]

Hello everyone,

I am a relative beginner to LabVIEW, in that I have read some resources, done a few tutorials, and tried making some simple programs to get a feel for the program. My main project involves adding extra functionality to a LabVIEW project that is used to stimulate human tissue and record the resulting voltages (not for torture 😉 ). This point has no relevance other than it is not convenient or easy for me to test the modifications I make. This means that I have to currently make do with "proof-of-concept"-type programs and hope the proven concept will work in the real application.

Essentially, I have to make some graphs display on a second monitor. I haven't found anything that suggests that individual graphs can be displayed on another monitor, so I need to create a separate VI with the graphs to be displayed. I have already looked at how to display a VI's front panel on a second monitor, tested it, and had no problems.

My problem comes with passing data from the original graphs on the main VI, on the primary monitor, to the graphs in the second VI, on the second monitor. It seems I can do it by passing a control reference for the original graph to the second VI, or by passing the array with the original graph's data as an argument into the second VI. You can see my attempts at these two approaches in the attached files: passing the control reference (RefInput_graph_main.vi, graph_sub.vi) and passing the array (ArrayInput_graph_main.vi, ArrayInput_graph_sub.vi). The reason I am using the Simulate Signal VI is that I cannot simply do another stimulation experiment, so I need to simulate data to see if my approach works.

The problem I am having is that the waveform seen in the two graphs is not the same, and this problem occurs with both approaches. It seems like the waveform in the second graph is slightly shifted to the right with respect to the original waveform. In other words, there appears to be a time delay between the two graphs. I don't know if it because of the time in transmitting the data (unlikely), or some kaveat with the Simulate Signal VI.

My questions are:

1. What is causing the time delay? How do I eliminate it?

(The actual program only receives snapshots of voltage data after each stimulation, so it is not a continuous stream of data. I don't know whether the delay will still be present in this case.)

2. Are there other approaches to passing data between the graphs? Any other suggestions or guidelines?

(The actual program is rather complex, so it will probably not be feasible to encapsulate the original graph in a Sequence Structure like in RefInput_graph_main.vi, which makes using a control reference not feasible. Still, I'm open to ideas.)

3. Any more comments?

Thanks for your help! I'd be happy to clarify things, or modify this post to make it clearer.

Nemanja

[Nemanja123]

Just to add the fourth file I mentioned.

[Sam_Sharp · Accepted solution]

If you're using a chart (updating point by point): Create a queue and when you write to the main chart, also write to the queue. Wire the queue reference into the subVI and dequeue the elements onto the second graph.

If you're using a graph (and displaying the whole waveform): As above but use a notifier. Actually, you could just queue up the entire waveform.

The option using a queue is essentially a producer/consumer architecture, the second using a notifier is a 'broadcast'.

(Just a couple of ideas...you could also share the data using an FGV / Global)

[Nemanja123]

Thanks, Sam! It's a graph, so I'll look into notifiers. Would notifiers be faster than using FGV or globals? It has to be done in real-time, or with a negligible delay. I'm also that worried that global variables, in addition to being poor practice, will give me the same problems that the references have been giving me. Anything that's not connected by wires runs in parallel, so synchronization problems would probably occur.

[Sam_Sharp]

That's why I'm suggesting a notifier - with the FGV or Global you need to 'poll' the variable to get the updated data. With a notifier, the receiving node will execute each time you write to the original graph so the data update on the second graph will be triggered by the notifier. I can't see any reason that would give you any noticeable delays and they should be pretty efficient.

[Nemanja123]

Hey Sam (and any other readers), I implemented the notifiers. The thing is, I am not sure what the best implementation is.

In one code (Notifier1), I put the "Release Notifier" VI in the main VI. In Notifier2, the release happens in the sub VI. Is the first approach more correct? That's what I see in the Labview example for notifiers. However, the second approach gives the same results.

If you run the code (made on LabVIEW 2014), you see that the waveforms displayed in the two graphs are the same for wait times of 200 ms or higher (what is input to the "Wait until next ms multiple" VI). For shorter times, the second graph lags behind the first graph. Is there any way to fix this? In the real application, the data is acquired every 8 seconds, so this issue shouldn't occur, but I would still appreciate some idea of what the cause is.

By the way, I know there is no error handling. It's not important at this stage.

[Nemanja123]

Notifier2 files

[Sam_Sharp]

Generally, whichever VI creates the reference should be the one to destroy it - so it should be released in your Main VI. You can actually use this to your advantage because when you release the reference in the Main VI, the Sub VI will error at the wait on notification node and you can use this error to exit the SubVI (carefully...if it errors for another reason then it might exit prematurely).

Read the help documentation for the Wait and Wait on ms multiple - if you have a loop which takes 150ms to run and your wait is set to 100ms, the loop will run at a rate of 150ms (the higher of the loop execution time or the input to the wait). If you use the wait on ms multiple, it will run at a rate of 200ms because the wait will round up to the next multiple of 100ms (i.e. 200ms).

The reason for the delay is because the simulate signal is set to 'simulate aquisition timing' which means the loop will take as long as it takes to acquire 100 samples at 1000Hz (i.e. 100ms). In this case, you don't need the wait until ms multiple because your loop timing is driven by the Simulate signal VI (but you should always be aware of a loop running at full speed and maxing out your CPU).

[Nemanja123]

Sam, thanks for all your help. I think it's clear to me, and I've moved on to working with the actual application I'm supposed to modify.