Best Practices for User Events

[plist]

Hey There,

So I've just started working on LabVIEW projects about a 8 months ago (taking my CLD next month) and I'm to the point where I really want to make sure I'm making correct design decisions in my program. When I first learned queues/user events I was originally just using them all willy nilly like. Now I am actually designing a pretty large program from scratch and want to make sure to make the right design decisions.

So basically I'm curious, should user events be used to pass data between parrallel loops? Or should you use them purely for "Events" i.e. just to inform other loops that things are happening? (Am I thinking too far into this?)

Thanks for your help.

Paul

[aeastet]

We use events to pass data between parallel loops all of the time. It works great. I am sure there are other ways to do this as well and this will not be the correct solution every time. Some things that you will have to understand with events is how responsive the system needs to be? How fast do you need to react to the event?

We have loops that use event data and still react very quickly to what is going on. If you are working in the windows environment you are at it's mercy.

I would say that using events is a great way to move data but make sure that you understand what you need.

[plist]

Thanks for the response. 

The portion I am looking at right now is acting as a data logger for temperature. (.2Hz-.05Hz) I have a VI being dynamically called for each Specific Action(Data Logger object) I have that will log the data. As well as verify that temperature is staying within range, and counting amount of time temperature has been in range. Each of these Specific Actions will be monitoring the same information, which aren't direct channels but averages of multiple channels.

I want to keep the actual data logging part decoupled as much as I can, so I didn't want to be calling my analog engine directly then average the temperatures within the Data Logging Loop. I also have a seperate data logging loop that doesn't care about the Data Logger objects, it is purely acts to log temperature/humidity data at all times throughout the day.

So I came to the conclusion I should use the User Event as it is a one to many situation. But as I type this it's really probably not the best idea. As I would have to update a piece of information in a Shift Register every time I called that user event, potentially affecting my Specific Action loop timing. I was going to use a single-element queue, write to it from the outer data logging loop and just preview queue elements in my Specific Action Loops, but I was thinking of queues as Many-To-One and assumed this was bad practice. 

I can upload my code once I get a better framework layed out. But if you have any ideas that would be awesome. Sorry if this is all over the place. I have tons of questions of about good practices for LabVIEW Architecture, and between reading here and the LAVA forums and coding myself, and reading other code, I'm sort of overwhelming myself with trying to decide the right path.

Paul

[aeastet · Accepted solution]

You can still use the method that you are using only inseted of storing data in a shift register store it in an action engine. This is a seperate VI that is used for data storage. Dump your data into that vi and use the vi we you need to call the data.

That is how we do it.

[plist]

Okay, I will look into doing it as an action engine. I wasn't sure if those were still the recommended practice or not since everything seemed to be moving towards OOP.

Thanks!

Paul

[Ben]

If you are developing an OOP app then you can use a DVR otherwise KISS*.

Ben

* Keep It Simple Sir

[DFGray]

For the one-to-many situation you describe, event structures are always my method of choice.  You can also use notifiers, but they are lossy.  However, they are also lighter weight and faster, so are useful in some situations.

For one-to-one or many-to-one situatuations, I use unnamed queues almost exclusively.

I use DVRs (replacement for single-element queues) and action engines only for state information, and then only if I can't store it in a local shift register.  I greatly prefer the DVRs, since I find them more scaleable and maintainable.  However, this opinion is not shared by all in the community.

Note that these recommendations are only for single-process applications.  Things get more complex when you start passing data, messages, and commands between applications or processors.  Check out the Large Apps portal on ni.com for lots of discussion on this topic.

[plist]

---

DFGray wrote:

I use DVRs (replacement for single-element queues) and action engines only for state information, and then only if I can't store it in a local shift register. 

---

I keep hearing people making mentions of DVRs being used for to access data when a shift register is not available. Am I missing something? How are you passing the DVR between loops? Do you use a FGV to send the DVR to parrallel loops? (Is that the major benefit of the DVR, passing a a reference, rather than making copies of data to send across loops?)

Sorry for my newbishness.

Paul

[Ben]

Yes.

A DVR is a special type of refence that has special opeartor you use with it.

The DVR defines the data type stored in a protected buffer and provides the mechanism required to access that data buffer in a protected manner. THe opeartion that are used by a DVR ensure only a single thread is acting on the associated buffer at any one time. Most of the operators let you work on the data "inplace" (without having to make copies).

Sincet they are not tightly coupled to a particular VI (like the SR in an AE is tightly coupled) VR allow the same sub-VIs to act on different data buffer by way of the pointers assocated with the DVR.

I hope that helps,

Ben

[plist]

Yea that definitely helps. I just wasn't sure if I was missing some inherent way of naming a DVR such that you could reference it where ever you wanted. I'm trying to get a good enough grasp on all of this stuff as well as OOP in LabVIEW such that I can start dealing with the Active Object Framework. It seems to make the most sense to me in terms of readability and expandability. 

Thanks for the help guys, I'm sure you will all hear from me again soon.