Subpanels and Occurences - Race condition?

[cbutcher]

I was trying to create an example project for the thread here: Subpanels-Waveform-Charts-Async-VIs and was unable to get my example working nicely.

The project (written in 2019) is attached, along with a backsaved version to 2016, which I haven't tested (only 19 installed here).

Essentially the code is very simple, and so both BDs are also shown as snippets (in case I just forgot something crucial).

The code behaves significantly differently depending on whether I wait in the launching loop, or at the beginning of AsyncVI.vi, or neither.

Is this expected? Did I make a simple mistake? Is there some odd bug here?

FP boring so not included to save space

[mcduff]

Try the following change: On the Wait for Occurrence, change the Ignore Previous to True.

mcduff

EDIT:

I also removed the Insert VI in the For loop, and closed the references.

[Ben]

In the event it can help somebody stumbling across this thread...

I wrote a Nugget about how to generate an arbitrary number of occurences that can be found here.

It was written back in about LV 8 and we did not have asynch call by ref nodes but the example should still work 

Spoiler

that thread evolved into a discuss about reentrancy...

Ben

[OregonGumby2]

You need a subpanel function call for Remove VI before you insert a new VI.  You also need to abort all VIs and close references when you hit stop.  Check out the subpanel example that ships with LabVIEW.

[cbutcher]

So, I'm not sure if anyone tried out the examples, but I followed the suggestions and still observe the same behaviour.

mcduff:

Try the following change: On the Wait for Occurrence, change the Ignore Previous to True.

I also removed the Insert VI in the For loop, and closed the references.

So I initially thought that setting Ignore Previous to True would introduce a race condition, but then I realised that I can of course move the timing to the Wait on Occurrence node. So I set this to True, and made the timeout 100ms instead of 0, and removed the Wait(ms).

I added a Close Reference to the Stop case of the caller, but I didn't expect this to change anything for such a simple example.

Removing the Insert VI demonstrates the first of my problems - until the VI is inserted into the subpanel, it doesn't "appear" to start recording data. This can be observed by removing the Insert VI in the For loop, then running the Caller.vi, waiting a little, then switching the inserted VI back and forth. The Waveform Charts in the AsyncVI clearly retain data once they "start", but until they're inserted, either they don't start, or they don't retain the data... Normally I'd use a graph, but since I'm trying to create an example for a Chart, that doesn't help me...

Ben:

I wrote a Nugget about how to generate an arbitrary number of occurences that can be found here.

I didn't know that GO gives the same occurrence each time! I initially tried to troubleshoot my VI by placing the GO inside the For loop, then Setting inside a For loop in the Stop case of the EStr, but didn't observe any change. I guess now I know why!

However, I don't think in this example it's a problem, and in the posted version of the code I'm explicitly only using one Generate Occurrence node and would expect each subVI to have the same Occurrence to check.

I may go ahead later and try using Call by Ref as you show in the nugget to generate a set of Occurrences in case that makes a difference.

OregonGumby2:

You need a subpanel function call for Remove VI before you insert a new VI.

Not sure if this does something special for the references internally, but certainly not true for observable results. Inserting a new VI will always remove the previous one. Removing an inserted VI is useful when you want the panel to be blank.

You also need to abort all VIs and close references when you hit stop.  Check out the subpanel example that ships with LabVIEW.

Reference closing addressed above in response to mcduff. I certainly won't be aborting my VIs - that's what the occurrence is for.

Other possible problems (not causes):

• Adding a Wait (or Stall Data Flow.vim, etc) to the "Numeric" input of the AsyncVI messes things up - no longer see data on the chart. Setting ignore previous to true and using the Wait on Occurrence to control timing seems to have at least partially fixed this - they all still started for me now. Maybe I had some previous occurrences (from previous runs) still "triggered" and the GO gave the same value despite separate runs. Would need to check more closely.
• Getting the string to appear seems problematic. The above-mentioned Wait can help in some circumstances. I suspect that the indicator is populated when the AsyncVI first runs, and if it is not previously inserted at that point, it doesn't correctly load the value when I do insert it. Not sure what the cause here is - but if I could understand my first problem (need to insert to see data start) then I'd probably solve this one too. Re-adding the Insert VI in the For loop, combined with the Stall Data Flow in the Async, solves this, but is a peculiar workaround (and a guaranteed(?) race condition).

[TomOrr0W]

For the chart not updating, I tried adding a property node to the Asynch.vi's block diagram, which seemed to fix the issue.

Note that you also have to set Ignore previous to true (and use a non-zero timeout) on the wait on occurrence (otherwise it will only work once).