Waveform graph in main vi not updating correctly (lagging) when subvi that produces data is called asynchronously

[mikethemartian]

I have a LabView program in which I need to asynchronously call a subvi to perform waveform capture on a PXIe-4080 and then allow LabView to command other devices during the capture. I noticed that even though I could capture the data without issue the waveform graph itself was not updating. I narrowed down the location in the vi that was causing the issue but it is unclear to me why this is happening. I reduced the main vi to a small vi named "asyncplotissue.vi" and replaced the original subvi to one named "create_waveform.vi" that simply generates one of three plots (sine, square, triangle) depending on user selection. In the main program the user can select one of three waveforms. In this case we make it a sine wave. Once they do this "create_waveform.vi" opens its front panel and shows the sine wave on the graph. However when it returns to main the plot remains empty. If the user then chooses a square wave for their second selection the "create_waveform.vi" subvi displays the square wave on the graph as expected but the main vi now shows the sine wave. If the user keeps going the main vi will continue to show the function made in the previous selection.

The subvi "create_waveform.vi" has two outputs "waveform data" and "waveform graph" which are the same node on the block diagram but just presented differently on the front panel. What I noticed is that when the "waveform data" being returned by the "Wait On Asynchronous Call" node in the main vi is connected to any indicator or subsequent code the above stated problem occurs. However once it is disconnected there is no issue and the main vi updates the graph in a timely manner. Also there is no issue when the subvi is called synchronously.

I can probably figure a workaround for my code but does anyone know why this is happening?

Thanks

Mike

[Wes_P]

Smells like a LabVIEW bug to me. I ran your code and had the same issue. One observation though - there is no reason to have both waveform graph indicators wired up to the connector pane. It is literally the same data. If you want both displays on your calling VI, just branch the wire there. That gets rid of the issue, as you noted, and preserves the desired functionality.

[mikethemartian]

Sorry I forgot to save the array filled in with the wave types the default before saving. I don't see a way to replace the file in the original post so I attached it here again. 

[mikethemartian]

Wes,

Thanks for the response, I greatly appreciate it.

Mike

[Wes_P]

My pleasure, though I'm sorry I couldn't be more help. FWIW, I see that your code was in 2019. I ran it in 2020 and had the same issue with the results lagging one iteration.

[altenbach]

I agree this is probably a compiler bug where it sees all these duplicate data paths for the same thing and optimizes too much out.

You can regain functionality by placing an always copy in the subVI, but of course it makes much more sense to only have one terminal for the same data.

Rule of thumb: If you suspect an error due to an overzealous compiler, sprinkle some "always copy" fairy dust. If it fixes the problem, we have proof!

Code-wise here are a few more suggestions:

You probably want to create that reference once outside, not with very call.

Your "button detector" and setting of t0 is a bit circuitous. Compare with the following:

Of course wiring all these errors across is quite pointless. Other wires already define the dataflow.

Also note that I would wire the blue directly to the case and make one case "default" and the other "-1".

[mikethemartian]

altenbach,

Thank you for your comments on my issue and recommendations to streamline the code. I greatly appreciate it.

Mike

[Intaris]

---

@altenbach wrote:

---

Just being a stickler for details, but AFAIK the lower example is actually not fully equivalent. While is accurately reproduces the functionality of the first loop of the original code, it does NOT reset ALL buttons like the second loop of the original example does. Fine of you only ever have one "T" value, but if there are multiple, the output of the two pieces of code will be different.