Trying to create multiple state machines out of same VI to monitor each cFP channel results in what seems to be shared memory between machines

[kgolden]

Hi,

I'm trying to create a state machine which monitors a single channel on a field point. I want to monitor up to 64 channels at a time, each one with different instances of the same VI. The VI itself needs to maintain information mainly through feedback nodes both in its own block diagram and subVIs within. 

All instances of this VI will be executing inside a main loop as they do not execute loops of their own as this would create 64 threads on the cFP-2200 we're using which I believe would be too much.

My attempted solution to all of this was to make the Channel Monitoring VI along with all SubVIs reentrant and "pre-allocate" for each instance. This does not seem to help as each VI seems to maintain the state of the one which ran before. Maybe I'm missing a step?

Is there a better way to approach this problem without writing a separate VI for each channel and the maintenance headache that would cause?

[kgolden]

In the traditional state machine design, there is a case statement within a while loop and the case statement maintains its state and other things through shift registers.

In my case, my SubVI is basically the case statement and it maintains everything through feedback nodes so I don't have to go outside. This is desired for maintainability and to allow some nesting to take place such that I don't have to display all 64 SubVIs and their various shift register needs on the block diagram of the main loop.

[Ben]

What you are attempting is not easy and if I describe what can be done, it will be hard to follow but I'll try anyay.

First review my Nugget on Createing unique Ocurences (read the thread not only my Nugget!)

It shows how to load multiple instances of the same template.

In your case you have to epp track of each copy of your sub-VI using the ref to the loaded VIs. You can then use "Invoke node call by reference" to invoke the instance you want let them crunch and wait for the results.

I'll stop there and see if we are getting anywhere.

Ben

[kgolden]

Hi Ben,

I actually read your document for another puzzle and it worked well, I think largely because it involved subVIs which were meant as separate threads. In that case, I used methods to alter inputs while the VI was "running."

In this case, as you know, my SubVIs are not looping inside, they are instead single calls but they do need to maintain the state at the end of their previous call, adding to the data they're tracking after they are called subsequent times. I tried the "call by reference" to call them each time. Below is a screenshot of the VI used to create the occurances and a SubVI used to execute each occurance, this subVI is embedded inside a while loop which I did not show here:

In running my tests, there still seems to be some data sharing of internal variables and feedback nodes between the SubVIs I'm calling, which I do not want. Am I approaching this in the correct way? Is what I'm trying to do even possible?

[Ben]

try the "option 8" (to open the sub-VIs as reentrant) for the Open VI ref node.

Ben

[kgolden]

Hi Ben,

Thanks for the reply. I forgot to mention that I tried both option 8 and not wiring the input. The same behavior occurred for each time. I tried it again after your suggestion just to make sure.

The way I can tell data sharing is taking place is as follows. As mentioned, the subVI is a case statement part of a state machine. The "state" is maintained by feedback node inside the VI. What is happening is the first occurance will execute and determine its state correctly. However, the second one to execute starts out with the state that the previous occurance finished with. It should not be doing this since I want it to be an entirely independent state machine. The feedback nodes for each execution should only have data that was created in that particular occurrance, not the others.

[Ben]

Wild shot in the dark...

I beileve I heard of a bug with feedback nodes... could you try using shift registers as a quick test to get you going?

If not plese post a very dumbed down example that (someone) can look at to figure out what is happening.

Sorry but I can only answer questions on the fly and have to run.

Ben

[kgolden]

Ben,

Thanks for your input and advice. Upon hearing that there may be a bug, I began to double check some things just to be sure. It turns out that one of the nested VIs inside this VI was not re-entrant when it should have been since it too had a feedback node. I changed it and everything suddenly behaved in the expected manner.

I wish there was a way to enforce or cast re-entrance on all subVIs (and their subVIs) from a top level rather than having to verify each one. Maybe there is?

Kelsey

[Ben]

Thanks for the update. Glad to hear it functioning as expected.

Re: force re-entrancy ?

No way that I know of off-hand and there are cases where I would want to force it.

Example:

What if all of your sub-VI need to acces as single AE?

Congratulations for pulling this stunt off!

Ben