SubVI Re-entrant Option

[Iaquinto.Joe]

Our team is using a subvi to take an encoder and our optimal speed in in/s to control our drivetrain with 4 custom PID controls. We had 4 of these SubVIs (One for each wheel) and we were running into an issue where all of the PIDs were all tied together (When you manually twisted a wheel, all of them moved to compensate). We searched for awhile and we learned that when you have multiple instances of the same VI, their IO is shared on the same memory. This can be stopped by going to the front panel of the SubVI, right clicking the icon in the top right, going to VI Options, going to Execution in the drop down, and checking the radio button under "Preallocated clone reentrant execution". This allows you to call the same subvi on your crio multiple times. You will most likely need this for any custom VIs you create. I just thought this was a little obscure and deserves a thread for clarity. Good luck!

[Greg McKaskle]

You described it well, but let me give just a bit more background.

Normal subVIs act as functions in the language. By default, they act as a critical section. So resources they access can be viewed as short transactions and made safe. This is very useful for protecting access to a device or state data in a parallel environment. Normal subVIs are also not reentrant and do not support recursion. This means that any static data or state data you put in the subVI is shared across all calls to the subVI. This is good if you want one global piece of data like a sum or global running average.

When it is not what you want. When you want a piece of state data for each instance of robot, you have a few choices.

The one you outlined is to go to the VI Properties>>Execution, and enable the Preallocated reentrant property. This does two things -- it allows for multiple calls to the function to proceed in parallel, and it gives each instance its own state.

Shared clones are reentrant, but are used when there is no state data. Shared clones means that a cache of instances builds up as you run. It will only allocate for needs of simultaneous parallelism, not state data management. It also allows recursion.

Another approach is to make your subVI treat the state as a parameter and hold the state at a higher level.

A third option is to put the state into objects such as the actor pattern. This is very powerful, but not for the faint of heart.

Greg McKaskle