manigreatus

Hi,

It seems there is very low interest in NI-GDS...

I found out that in LabVIEW 2020 that dynamic member VIs are not supported by Call by Reference node.

Regards!

Hi,

I had developed a centralized HIL system based on NI-GDS (EndevoGOOP400->Simple DVR template), but now the client's new requirements requiring me to make it a distributed system by adding cRIOs. Previously I used to launch all the processes with corresponding IOs on the same system and have made use of dynamic dispatching extensively... in short I have interface classes those in turn load different child objects, but now I want to launch these processes on different cRIOs.

Is it a good idea to launch all the objects on different cRIOs using VI server, and talking to those objects from one cRIO using VI server? The thing is if I had loaded an object and want to call its members, how shall I do it? Do I need to launch the Create.vi remotely and open the reference to the object and keep the object reference locally and use that object reference while calling the members of that object remotely? What does the following statement means?

"4.When you no longer need the VI to run on the Real Time target, close the VI reference, then the LabVIEW application reference.  Note that the dynamically called VI can only run on the real time target while the reference remains open, and that closing the reference will stop the VI on the Real Time target."

which can be found here;

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAhpSAG&l=sv-SE

When you make a source distribution of say 20 classes and deploy on a Linux-RT cRIO, and want to launch say 50 objects out of 12 deployed classes, will the remaining 8 deployed classes will be in RAM too?

Thanks!

Thanks guys for your comments!

I like to store my refs (queue, event etc) in LV2 style VIs (functional globals). That way you do not need to litter reference wires in shift registers all over your diagrams.

 

You can use the first call primitive to obtain the ref the very first time it is called, which is nice as then you do not need to care who called it first (parallel loops). See picture, in the false case the ref is just wired straight through.

 

 

 

Interesting, do you use a single variant with multiple attributes, one for each reference?

I like the first call primitive solution.

Obtain Queue using a name is planted in my brain as a serious performance bottleneck.  If you compare a simple enqueue in a loop the difference between looking up once and looking up each loop iteration can be the difference between a few msec and more than one second (order of 20000 iterations).

 

If you were to place an obtain queue inside a loop with a constant name I would think it could be recognized as a loop invariant and optimized for you.  You know, have your cake (no long bending wires) and eat it too (super fast).  No such luck.

 

What I do instead if I need the name function is construct a look up table using variant attributes.  With a constant name the variant lookup code is optimized and is essentially as fast as using a single obtain.  With a control inside the loop for a name (breaks loop invariant) the attribute lookup is still much faster than obtain queue.  It is a way to get the elegance of by-name lookup with much less of a performance hit than using obtain by name.  What do you lose?  Primarily the validity checks you usually do not care about when you are trying to shove data around quickly.  I figure that the enqueue/dequeue will complain soon enough I do not worry about catching the error upstream from there.

 

(These are vague recollections from LV11or12, maybe it got a lot better in LV13)

I did the variant based look up in the following way (after getting an advice from here by Aristos Queue), but the problem I see here is that the data reads can insert delay for data writes which I dont have in case of SEQs.

I am working on a cRIO based application in which I am using some SEQs and these SEQs are being used within different parallel processes... Is there any difference in terms of processing to keep SEQ's reference in a shift register or to obtain the SEQ reference (using a name and "Obtain Queue" function) each time it is used?

Thanks for any comments.

And, for the record, this isn't just Actor Framework. This is any sort of "here's the UI process and over here is the HW process". So "actor" as a model of the system, not as a particular instance of Actor.lvclass.

I also agree with this because I have experienced it in non-LVOOP it simplifies debugging and design; but what if you have a HAL.lvclass being stimulated by that "HW process" and you don't want to fork wire; but when you have a situation where you want to stream more than one channel up to the GUI/Controller simultaneously then what should be done? I am relating it with my HAL.lvclass:

http://lavag.org/topic/16510-dvrs-within-classes/

Thanx all for your invaluable comments! Now I am almost convinced not to have DVRs for my driver objects but the thing still in my mind is that HAL wire is going be heavy anyways so wont DVRs do better in that case?

I also agree with Todd and James; based on what you've told us I don't see how adding the DVR uses less memory and the action engine example you posted should work fine without the DVR (assuming your vi is set to non-reentrant.)

For me with DVRs  you can easily play around with arrays since you don't have data copies. The example shown was a non-reentrant vi being called from different parallel processes. As you see there shouldn't be anything wrong without DVRs so did I but the reality was different. Probably I had some other issue but it was resolved when I used DVRs. I will try to re-create the error when I get some time.

BTW> look into “Variant Attributes” as a higher-performance way of doing look-ups like that.

I did consider that but couldn't utilize them. It works very nice when you look-up against the same type of key say you are looking-up a 'data-cluster' against the 'name string' but what if you want to look-up the same 'data-cluster' against another type of key?

Random comments:

1) An “action engine” is a by-ref construct very similar in use to a DVR, so I don’t understand how you could have experience application hang with an action engine.  Having an action engine with a DVR inside it seems redundant and overly complicated.

Yes you are right, but just see the code inside dvr because of which I had to use dvr (which was not part of my design).

I don't see how this saves memory. If you're using this class strictly ByVal (not branching the HAL.lvclass wire and expecting the DVR contents to be the same on both branches), there are no duplicates of the Config data.

With the caveat that I consider it a bad practice to use references unless you are backed into a corner and have no other options, then, yes, this is a good practice. Just remember that if *any* data member of your class is by reference then things work much MUCH better if *all* data members of your class are by reference. Trying to mix by value members with by reference members is legal but results in situations that many people screw up easily (i.e. the wire forks and now half of their class is copied and half of their class is the shared reference, leading to confusion about what exactly this object represents).

the reason why I chose this practice is a recent experience with a simple LV action engine being used in a GUI based application with different parallel processes. The application hangs when I tried to look for different parameters in the configuration, and the issue was resolved by using DVRs as shown below. I that case I was just having 100 I/Os with scaling info and in case of HAL I might end up with more than 200 I/Os including scaling info and calibration (a separate object) as well. 

Why not.

This will help you access the same object even if you branch the HAL Wire.

Also it helps you locking the resource.

Memory Wise, I think it could be an advantage, if the Aggregated Object Contains Huge amount of data.

By replacing that with a 4byte DVR reference value, the HAL-Wire don't become so heavy.

So e.g. if you branch the Hal-wire, or when you go into many SubVIs, those SubVIs has to allocate memory for this Huge amount of data.

 

But should you ever branch a ByValue Wire?

If you want to run things in parallel and accessing one object, you have to go with the Actor approach, or...just use ObjectByReference.

//Mike

It seems a very valid point to replace heavy HAL-wire with just a 4byte DVR ref. currently I have no intentions of branching if I need then I would go with the Actor approach or simply having an independent process.

Is it a good practice to keep objects as DVRs within another object as shown below

In this case I am loading different drivers within HAL and I have no intentions to void dataflow by using DVRs rather I want to keep less memory for HAL.

Then, is it correct to say that dataflow is inherently actor oriented?

Not necessarily but it can be utilized to achieve the actor-oriented design.

Because an actor is not and cannot be defined by a single VI. A VI is one function. A .lvclass *is* simple -- it is a set of functions, and the Actor class defines an entire Actor. You just don't have the richness to define functionality in a single VI. Besides, most actors need private support functions.

I didn't mean a single VI with "Actor VI", of course a single VI can't do the job that efficiently. Actually I meant to say that some type of file .lvclass (say .lvactor) that will hold all the stuff (messages, functions, etc.) related to that actor. Currently you define actor by one .lvclass and messages to it are some other .lvclass; why don't we combine these together? I mean if you are using actors then these should be actors not objects. Anyway  it would be almost the same thing what we currently have, I thought if we abstract OO part from actors then it would be easier to play with them.

"On the question of whether LV is object oriented or actor oriented: Neither, inherently. Both of those are design styles, and they are orthogonal to each other. One speaks to a way of data packaging (object) and the other speaks to a way of controlling execution flow (actor). It is possible to design a system that is pure procedural, purely object oriented, purely actor oriented, or both. Such systems can be built in just about any programming language. Having said that, various languages provide syntax support to make it easier to implement these designs. LabVIEW supports object-oriented programming through the .lvclass files and related features. LabVIEW supports actor-oriented programming through the queues and VI Server systems. The Actor Framework provides syntax to unify the two, though there are plenty of other ways to achieve that effect."

Thanks for your explanation. But I see a VI/module in LabVIEW as an actor which implies that LabVIEW is inherently actor-oriented (AO). We can implement an actor even without using VI server and queues by just having a while loop and a local. For me one of the most attractive things in LabVIEW is its simplicity, you can design complex systems even without knowing the programming paradigms (say AO) and that's the beauty. I think in Actor Framework things have been made pretty complex by mixing OO and AO. At this point I have a question that is Actor Framework reflecting what is described here:

http://ptolemy.eecs.berkeley.edu/publications/papers/07/classesandInheritance/Classes_Final_LeeLiuNeuendor.pdf

For advanced users its really a nice idea to introduce two different programming paradigms and then show them how these can be combined but for average users it is complex. I think apparently we needed  "inheritance" and  "encapsulation" from OO in AO why not introduce something say "Actor VI" and associate encapsulation, inheritance etc. with that without having a .lvclass. In this way we can abstract the OO stuff from the design since in Actor Framework one needs to keep track of classes and also the actors which makes it complex. Please give your suggestions and correct me if I am wrong since my goal is just to keep LabVIEW simple but powerful

Thanks all for your replies.

So I guess my interpretation (I'm not an expert on actor-oriented programming, by any means) is that an actor (or a component) is a way of programming that emphasizes concurrency (and as such looks somewhat like dataflow, which is, I think, why LabVIEW appears in the abstract of one of the papers).

But my understanding is actor-orientation and dataflow do not fall in the same category, actor-orientation is a design notion and dataflow is a Model of Computation (MoC). Which is almost same as James wrote

"The model of computation is how the software executes. In 'G' this is the dataflow paradigm. I would suggest that OOP or Actor oriented programming is a higher level than that. It is a means of design rather than execution and so we can use OOP with dataflow or other paradigms."

If you get deeper into the definition of Actor-Oriented design you can design heterogeneous systems by utilizing different of MoCs not just dataflow.

Object-oriented programming aligns well with that concept since it emphasizes encapsulation, but of course it would be possible to implement actors or components without objects.

It seems a very good explanation but here I still have the same point as in my first post that why in one design notion (i.e. actor-orientation) you needed another one (i.e. object-oriented).

Please correct me if I am wrong since I am also an engineer not a computer scientist

This is my first post on LAVA although I have been using LabVIEW for five years.

I thought LVOOP in LAVA is the best place to ask this question so I am doing. I have been considering the Models of Computations (MoC) in LabVIEW, it is based on actor oriented design that is utilizing data-flow programming MoC and bla bla... But I couldn't answer myself why Object Oriented programming paradigm was required in an Actor oriented based design. Either we have a relation with OOP based languages that's why pushing OOP into LabVIEW or LabVIEW is not actually based on actor oriented programming paradigm or actually I don't understand it

If LabVIEW is based on actor oriented design then shouldn't we exploit actor oriented design principles?

OBS! Remember this post is not related to Actor Oriented Design Pattern available in LV 2012.

regards,

Imran

Certified LabVIEW Developer