Stateless Mathematics and Signal Processing VIs

[David_Staab]

Many of the Mathematics and SIgnal Processing VIs retain state, rendering them unusable inside reentrant VIs: http://digital.ni.com/public.nsf/allkb/543589DF37BA48CF8625744A00543FF3

Many of the VIs in this list (all those in my current application, unfortunately) can only work with single-channel data. When manipulating multi-channel data, you can work around that fact by running the channels serially through the VI you need, but that (1) takes much longer for large data sets or several channels, and (2) is not an option when performing live manipulation of streaming data block-by-block.

I ran into this problem while developing code in the Actor Framework, where Do.vi and Actor Core.vi (the two main framework methods) are both Shared Reentrant. Now that AF is a native feature in LV, I expect that more people will run into problems with these VIs.

We need stateless versions of these VIs so we can use multiple copies in on a multichannel data set. You can probably keep backward compatibility by pushing the core logic to a new stateless subVI and keeping the shift register or feedback node on the main VI's diagram.

[altenbach]

If you read your quoted article, it only warns against using these VI inside reentrant subVIs that are set to share clones. If you use the "preallocate clones" reentrant setting, everything is perfectly safe. Right?

I would think this idea is already implemented.

[Daklu]

"If you use the "preallocate clones" reentrant setting, everything is perfectly safe. Right?"

Actor Core.vi is reentrant and dynamic dispatch.  You can't set it to preallocate clones.

[David_Staab]

Daklu hit the nail on the head. That's what I meant in the part that says "...the Actor Framework, where Do.vi and Actor Core.vi...are both Shared Reentrant."

There is no Full Reentrancy ("preallocate clones") for LVOOP methods.

[altenbach]

Ah OK. Thanks.

[AristosQueue (NI)]

And it isn't just the Actor Framework... using shared clones is more recommended than using full clones for the desktop -- the performance to memory tradeoff is much better for most VIs.

[Brian_Powell]

Just to qualify what Aristos Queue said, using shared clones is more recommended as long as the VIs don't maintain state.  I don't want things to be quoted out of context. 😉

For more details on this topic, see this series of blog posts...

http://labviewjournal.com/2012/02/maintaining-state-1/

http://labviewjournal.com/2012/05/maintaining-state-information-in-labview-applications-part-2/

http://labviewjournal.com/2012/05/maintaining-state-3/

http://labviewjournal.com/2012/06/maintaining-state-4/

http://labviewjournal.com/2012/06/maintaining-state-5/

[Sleepy_Engineer]

So, is there a workaround for this? I just upgraded to LV 2012 and decided to buckle down and try out some OOP for the first time and implement my next very simple project using the actor framework. This simple project is, in essence, cycling power to the DUTs and then watching them (through VISA) as they boot up and send data for the first few minutes to make sure they don't freeze or get their default flash data messed up or something.

After spending a bit of time last week trying to get my mind around how OOP works and how I should structure everything I essentially came up with the following:

The Main Application -> Launches a Cycle Task Manager which dynamically launches -> DUT Controller (and which in turn launches the rest of the main classes that handle the power cycling, serial communication, reporting, etc.).

By dynamically launching the DUT Controller, I mean that you can select how many devices you want to test and it launches a new Actor (with its subActors) for each one. The problem being that each spawned DUT Controller Actor has to share clones and I get the VISA data from one DUT showing up on another DUTs front panel. Is cross-talking the right term?

A solution in the forums is to make a parent class a static dispatch so that it can be set to pre-allocate the clones, but I don't know how I would go about making a parent class to the Actor Core, and I can't change one Actor Core without changing all of them, and pre-allocating the Sub-VI's doesn't do anything since the Parent VI's are the clones that are shared.

I feel like I either

1. Botched up the whole OOP thought process and should have gone about it a completely different way

2. Am missing something simple.

In short, Is there a good way, using the actor framework, to spawn a bunch of actors and then to be able to communicate with each one independently, know which one you are talking to, and know that the data is coming from a specific actor instead of just from a random clone?

-Carl

[David_Staab]

crwrecker, this is probably the wrong place to post a question like yours. Try making a Discussion thread on NI Community in either the Actor Framework group or the LabVIEW Development Best Practices group.

[Sleepy_Engineer]

I just posted this, or at least submitted it to be posted, in the Actor Framework group, so hopefully I can get it answered there. I was jumping around and didn't realize I had entered the Idea Exchange, this was just the only thread I found that was close to what I think my issue is (;

Thanks David!

-Carl

[cgiustini1]

I totally agree with the fact that these VIs (and almost all VIs) should not retain state. Currently, they are hard to use when it comes to integrating them into larger state machines. You have no way of selecting a particular state machine to keep feeding data to. You also have no way of running different polymorphic instances of these VIs in the same loop. When all of this piles up, I find it hard to write good software with these VIs.

Why not use OOP? Since classes are so useful for representing state machines, I think NI should use LabVIEW OOP to develop classes for each of these VIs. That way all of the state info could be retained in the private data of an object, where it belongs. The VIs that currently exist would hence be methods that you call on these objects. In my opinion, this would make software design much simpler and neater! Imagine a situation where you could run 1000 DSP detectors (or any other kind of state machine) by simply autoindexing an array of objects that represent these detectors by calling the "update_state_with_new_data.vi" method. You could then process all the update states by autoindexing the resulting array of detectors and running a "read_state.vi" accessor. From there, you could pick any individual state machine and do anything you want with it (send it to another piece of code, reset that one specifically, delete other detectors from the original array, ...). Using OOP would combine the ease of use of NI's signal processing VIs with the powerful software paradigm that is object oriented design (which has NI has been pushing for with LabVIEW OOP).