Question about re-usuing subVIS.

[rajiv85]

So I have a few questions about SubVIs that am a bit confused.

I understood so far that  aims of the subVis are to reduce the size of the program and make it more readable and understandable, but also to  save programming time and reuse the code.

However when I made a SubVI, simple example: averaging an array of doubles. I save it with a file name in my project. Now when I use it again, I saw that Labview is actually using the same SubVI, just writing different values in a race condition like situation such that the array has values from all the 4 channels it is reading from.

I thought that the SubVi would work independantly.

So how do I re-use a SubVi and avoid this?

Now I saw it is even communicating across 2 completely different and independant Vis. So this leads me to another question:

2.If the SubVI is 'non reentrant' by default when it is made and seems to work across independant VIs,  so it looks like it would work the same as a FGV? So what is the point of making an FGV when making a simple SubVi, writing to it and reading from it seems to be working the same as Writing to an FGV and reading from it?

>> In the second question am trying to understand the difference between an FGV with write and read with action engine, and a simple SubVi which has a control as input and an indicator as output ( with no action machine).

[jackstokley · Accepted solution]

Hi there,

It sounds to me like your logic for averaging the array of doubles may include an uninitialised shift register which is storing the values, just like an FGV.

It sounds like you have a good knowledge of FGV's, so you should know that the basic FGV works by using uninitialised shift registers and a non-reentrant VI as a method for storing data, so if you're doing this in your subVI it will store the values in the shift register during operation.

If your averaging algorithm makes use of uninitialised shift registers and your problem is using two of these at the same time, you may have more luck setting the execution mode to 'Preallocated clone reentrant execution' which will ensure that each call to your subVI creates a new seperate version of the VI in memory. This would prevent it averaging all of your seperate datastreams together.

Attaching your subVI to your post would be really beneficial so that we can see what's going on inside of it so that I can make more direct comments and help you out.

Jack

[rajiv85]

Thank you Jack:

So these are still being worked out so the code is not 'clean' and it is part of a little bit larger SubVi.

1. The SubVi in question is this one=> I read the last values and make an average:

2. Since I have 2 channels where I need it, I used it for 2 channels as seen here:

And it is getting these arrays from an FGV which is being read. The FGV is being written to in another SubVI.

In this case I saw that the arrays of each other contained values from either channels in a race condition like situation.

=> So now I guess the solution for this is to go on VI properties and select in execution,  'preallocated clone re-entrant' to solve this issue. Thanks for confirming!

[rajiv85]

But in this case: what still confuses me is to identify what is the difference then, with a simple SubVI which has a control as input and an indicator as output, no action engine..to be used for storing values and be read across VIs.. which is also non reentrant.. it seems to have all the properties of an FGV.. then why make an FGV if that would also work? :S 

[pincpanter]

If the subvi has no internal storage, the two instances act independently, as you expected.

What makes you think there is a race condition?

[Yamaeda]

---

@rajiv85 wrote:

Thank you Jack:

So these are still being worked out so the code is not 'clean' and it is part of a little bit larger SubVi.

1. The SubVi in question is this one=> I read the last values and make an average:

2. Since I have 2 channels where I need it, I used it for 2 channels as seen here:

And it is getting these arrays from an FGV which is being read. The FGV is being written to in another SubVI.

In this case I saw that the arrays of each other contained values from either channels in a race condition like situation.

=> So now I guess the solution for this is to go on VI properties and select in execution,  'preallocated clone re-entrant' to solve this issue. Thanks for confirming!

---

No, if it's non-reentrant, you only ever have 1 copy and the data it works on is the data it gets through the inputs. The 2nd block waits until the 1st one is done. If it looks like it's "copied" it's because it's already done several or haven't reached the 2nd one yet.

A well written sub-vi should be immune to this and e.g. not use uninitlized shift registers or use the preallocated clones as parallell usages would give the wrong data in the shift register otherwise. 

If you think FGVs and normal sub-vi's work the same there's some (fundamental) misunderstanding.

Also, there's a Mean.vi function for the averaging. 🙂

/Y

[rajiv85]

I will need to make more tests and come back to this to understand what happened.

I was clearly having in the array of my SubVi values from both channels and this resulted in the average value of my channel being abnormal. 

[jackstokley]

The snippets of code which you show here look like they should work fine without the need to switch the execution mode as the subVI does not make use of shift registers/memory. My suggestion would be that your arrays are somehow jumbled up before you get to this point.

As others have mentioned, your fundamental understanding of subVI's and FGV's is a little shakey so perhaps playing with them in simple practice VI's may be useful for you; there's plenty of simple examples when you search for them.

From a best practices point of view, it's also really important that you change the icon of subVI's or you'll get them all confused with each other!

[rajiv85]

Thank you for the responses!

[rajiv85]

Hello Yameada,

Thank you for your valued inputs. Nevertheless, today I was able to replicate the observation I made which led me to my assumptions.

So attached are 2 Vis having the same SubVI. As you will see even when run separately they output the same result. Even when I reset one, the other is reset as well.

Since it is non reentrant by default, it looks like it is working like an FGV, just without the action engine.

But as Jack pointed out, it does have a shift register in that particular case.

While in the previous case I posted, there was no shift register and yet data from the second channel was inserted in the array within the SubVI of the first channel in a race condition like behaviour. This I will need to replicate again and show (I will come back to this.)

However in that case here, clearly a better understanding of the working of the SubVI is needed to avoid these. But from what I see here, it looks like this simple SubVi is working like an FGV=> as it is non reentrant so it has by default the non race condition behavior and since it is always reading the same values?