Handling Parallel Execution Sub-VI's in an OO sense?

[AlexA]

Hi guys,

Sorry in advance for this post being a rambly display of gross, conceptual misunderstanding, I'm putting out feelers to try and figure out a little bit about this OOP thing. As per the thread title, how would you deal with the prospect of parallel processes that need to be called from the main VI and return information to it, without creating a new object (and subsequently, a new set of data?

In my very superficial grasp of the subject I'm imagining something like the following (context is the project I'm currently working on):

I'm tasked with talking to an FPGA module, getting data from it and storing some data on disk, and presenting other data to some sort of control algorithm.

I imagine an "FPGA Communications" Class.

Data:

-FPGA Constants (certain parameters which are read once when the FPGA is started and used in future calculations)

-FPGA Reference

-FPGA Data (a constant for accepting data from the FPGA)??

Methods:

-Initialise FPGA Constants

-Start FPGA

-Stop FPGA

-Listen to FPGA FIFOs (continuous process, possibly listens to the FIFO then writes the value to the FIFO data??)

-Present FIFO Data (accesor class)??

-Trigger FPGA activity (potentially continuous process)

So I guess the key thing is how one deals with the "Listen to FPGA FIFOs" method? I've also included an accessor VI for the FPGA data. I guess one class would handle communications with 1 FPGA device. If I want to have a data processing class (I think I'm still too stuck in the idea of having tasks rather than actors), anyway, this class would access the FPGA Data presented by Communications Class and do something to it. This idea of storing real time output from an FPGA in class data and then accessing, how does this fall apart when speed becomes a requirement?

[Aristos Queue]

Short answer: How would you create an integer in LabVIEW that you could access from two different VIs? Whatever answer you choose for that question, the same answer would apply to you object question.

Longer answer: In LabVIEW, parallel access to the same block of data is a separate topic from classes. You can use a global VI, a single-element queue, a data value reference, or many other strategies for sharing any piece of data between two parallel parts of your code.

For straight up "I want to modify this object from two parallel VIs", a Data Value Reference is going to be the correct answer for sharing an object. For a more sophisticated approach that prevents some of the pitfalls of simultaneous access to the same shared data, check out this approach from NI Week 2011. There are multiple variations on that theme posted online (see Lapdog and JAMA) -- the tradeoff is both are more complicated, but at the same time, more powerful/flexible.

Ok... that's the desktop/RT system. I presume that the host target is where your FPGA communications VIs will be living. If you're actually on the FPGA target, none of the above works. Go back to my "short answer". How would you share a single integer? The answer, to the best of my knowledge about FPGA, is that isn't really possible. FPGA has no concept of pointers or shared data. Instead, you write your VIs such that only one section of the code needs the integer at any given moment, and you pass the integer into that function.

But for your host target needs, I think that should be enough info to get you started.

[AlexA]

Hey AQ,

Thanks for the input. I think trying to dive into OOP via this problem I'm working on might be a little out of reach, given the time pressure I'm under, but your input is much appreciated.

Just a quick question further to your first, short answer. My answer to your question, based on my current understanding of Labview, would be to pass a reference to the variable between VI's, but from the reading I've been doing around the internet, passing references to classes seems to be a big no no in the OOP world. Have I misunderstood something fundamental here?

[Aristos Queue]

For OO in general, no it's not a problem. In C# and JAVA, the *only* way to pass objects around is by reference.

In LV specifically, tt's not a no-no for classes any more than it is for any other LV data type. Passing around references is generally bad in a parellel environment like LabVIEW -- they tend to cause a lot of overhead and are the source of the single hardest-to-solve class of bugs. Data flow is preferred for all LV activities, regardless of the data type.

[AlexA]

Ahh, yep that matches with my understanding. The last week has been very much tinkering week for me. It's the first time I've ever created a folder called scratch code, and it's already exploded to some 20 something VI's... Back to tinkering!

Oh, I just remembered, the kind of nitty gritty guts of my question is:

Suppose I have a method that takes the reference to the FPGA and starts listening to its FIFOs and loading the result onto a queue. How does one start and stop this method while still going on to perform other methods. Is there an OOP equivalent of "Run VI"?

[lvb]

Is there an OOP equivalent of "Run VI"?

In LVOOP class = cluster. You cannot "run" a class just like you cannot run a cluster.

LVOOP methods are just VIs that have access protection. You run a method just like any other VI as long as the caller has access.