Parallel loop communication using events

[Floris]

Hello,

I've been using the architecture below in my last few projects. It's based on one main loop and several DAQ loops that acquire data, all using (JKI) event based statemachines. So far I've also used events to communicate between loops as user events are non-blocking and using queues would mean either a blocking function or constantly checking if there is some data in the queue with a small timeout.

The DAQ loops connect to there respective sources, which sometime are not available, and send there data to the main loop. Doing it this way makes sure that all other data acquisition and processing loops keep running if one DAQ device is missing or has some problems. In the main loop all data is received, processed, calibration is done ete etc and then the processed data is send via network streams to a PC for display and logging. So far all data acquisition only needed to be slow, like max 10 samples a second. However, in my next project there is a lot more data to be acquired and a lot faster as well ....... so I'm wondering if the use of events for communicating between parallel loops is recommended .... also for slower data acquisition by the way. 

Like queues, events are also buffered so you don't lose any data but events are a lot slower than queues. I've made a little test VI (attached) to see the differences in sending data between loops using queues, notifiers and events. On my PC it runs really fast but on a cRIO a lot slower, however I think the speed is likely not a problem but as this is a bigger project with a lot more data and some safety critical controls (hydrogen valves) I'm just wondering if I might have overlooked some possible problems using events for communicating between loops.

Speed comparison sending two million 'datapoints'. Notifier misses a ton of datapoints but that is expected as notifiers is only last value data

	Queue	Notifier	Events
PC send	0.88	1.06	5.28
PC recv	2.12	1.06	9.01
cRIO send	10.12	21.08	50.57
cRIO recv	78.33	21.08	147.85

Been using a cRIO-9030 but for this coming project I'll be using a cRIO-9045 so that must be somewhat quicker I guess.

Anyway, as said before, I would really like to hear if I overlooked anything using events

Thanks in advance.

Best regards,

  Floris Overwater

[GerdW]

Hi Floris,

---

@Floris wrote:

this is a bigger project with a lot more data and some safety critical controls (hydrogen valves) I'm just wondering if I might have overlooked some possible problems

---

For "safety critical controls" I would employ the FPGA (with a watchdog implemented in the FPGA)…

[Floris]

Thanks for the reply. My control software is somewhat 'safety critical' as we don't want hydrogen to escape because of some wrong sequence of valve openings .... however there is an overall safety system that will shut every thing down from the hydrogen supply system. So .... it's highly undesirable it will not lead to a dangerous situation. The last time a have been using the FPGA in the cRIO has been many years ago and only once so I'm not very familiar with it and seems like I can easily make some mistakes there. I'm much more comfortable using the scan-engine and as far as I can determine it should be OK to use.

For seriously safety critical software I guess the FPGA solution is more suited indeed.

[mcduff]

---

@Floris wrote:

Anyway, as said before, I would really like to hear if I overlooked anything using events

---

I use a similar architecture, except I send an event to every loop. Each loop has a "helper" event structure that filters the messages and either passes or ignores the event. 

I have never experienced a slowdown with events; I cannot look at your VIs now, will try to look at them later. A few things that may be slowing down your event structure: if your event structure is subscribed to multiple events both user and front panel events, that can slow it down. An event structure subscribed to a single "user event" and nothing else should be almost as fast as a queue. I'll try to look at your VIs when I have LabVIEW on a computer.

[Intaris]

---

@mcduff wrote:

---

@Floris wrote:

Anyway, as said before, I would really like to hear if I overlooked anything using events

---

I use a similar architecture, except I send an event to every loop. Each loop has a "helper" event structure that filters the messages and either passes or ignores the event. 

I have never experienced a slowdown with events; I cannot look at your VIs now, will try to look at them later. A few things that may be slowing down your event structure: if your event structure is subscribed to multiple events both user and front panel events, that can slow it down. An event structure subscribed to a single "user event" and nothing else should be almost as fast as a queue. I'll try to look at your VIs when I have LabVIEW on a computer.

---

This was also my initial reaction. Events, in my memory, should not be that much slower. I have not used the most recent versions of LabVIEW though, so things may have changed. I'll be interested to see what mcduff sees.

[mcduff]

There are some issues with the benchmarking code, debugging on, ... Benchmarking is difficult, look for presentation by Altenbach for how to design effective benchmarking. 

Attaching code from a while ago by Jack Dunaway, a LabVIEW Champion. He has benchmarks in his code, look at it, and you can decide whether events are too slow for you. You are correct though; queues are the fastest transport mechanism, although I am not sure how channels compare. But typically, the difference between user events and queues is not significant.

As said earlier, for your JKI State Machine Architecture, I have used something similar to you without problems for high-speed acquisition. However, I've been on the Windows side instead RT, not sure if there is a significant difference or not. The biggest difference I can see between my implementation and yours, is that I use 1 User Event to send a message anywhere in the loop. Each loop has a helper loop that filters the user event and then decides to forward the message or ignore it. To keep the Event structure fast, try to limit the number of events that it is subscribed to. Lastly, how many messages per second do you want to send?

[Floris]

Thanks for all the replies and the example code from Jack Dunaway, really helpful.

Based on the replies and the lack of problems with events, the example code and the fact that the amount of data is not all that large I have to send between loops I guess the event based communication between loops has no obvious problems. 

Again, thanks for the help .... and boost of confidence.