Advice for communication using multiple consumer loops

[atrinh]

Hi,

I need some advice on the best way to communicate between consumer loops and event handling/producer loops. This program has an event handling loop, a state machine producer loop (correct term?) reading from the DAQmx subvi's, and 2 consumer loops (display and writing). Initially, I had a single queue where the "state" could be passed to any of the loops. I realized that this would not work and I would need a separate queue for each loop, after reading some of the forum posts. I believe this would allow me to have every loop be in the same state (e.g. waiting or acquisition). Where I am having trouble is that I am not sure how to change states if this change does not come from the same loop each time. For example, most of the change in states would come from the main state machine/producer loop where reading a device occurs. I do occasionally change states from the other loops. If I am setting up the UI, I have coded the change in state coming from the Display loop. If I am saving a calibration, I am triggering a state change from the writing loop because I want to make sure the file is written before any changes in state occurs. Is a queue the best way to handle this or should I use a notifier? This is my first time trying to create a program using queues and an event handler so any tips would be great!

Thanks,

Anton

[drjdpowell]

My best suggestion is to install and look at the JKI "state machine" template, and NOT to look at any of the NI "Producer-Consumer" designs.  Doing your application as a single loop, rather than four, will be much simpler.

[mcduff]

I agree with the good doctor. However, I will proffer the following. If you need multiple loops, use the JKI State machine for each loop and link them with User Events. This way you can send messages to any or all of the loops.

cheers,

mcduff

[drjdpowell]

---

@mcduff wrote:

However, I will proffer the following. If you need multiple loops, use the JKI State machine for each loop and link them with User Events.

---

A very good idea.  But I note that there's no obvious need for another loop here.  There are already three "hidden" asynchronous processes in action: the DAQmx Task that is feeding data into a buffer, a UI process that is drawing the graphs and front-panel indicators, and a UI process that is feeding Front-Panel Events into the Event Registration queue.  So with a single JKI loop you already have an effective four-async-process, fully-bufffered system.  

[mcduff]

Agree, a single loop will probably suffice. I would suggest the OP make use of DAQmx events, say Every N Samples acquired into Buffer. The JKI state machine has a built in event case, might as well use it.

Cheers,

mcduff

[atrinh]

Thanks for the input. I took a look at the JKI template and it was a little complicated for my understanding. I would still like to charge ahead with the current design where I have separate messaging queues for each loop. I think I have made this work but now I am having trouble viewing the data live during an acquisition. I have looked at several templates and I think I have set up the data queue properly for simultaneous viewing but I could be wrong. The program will collect data but only displays it after the collection has ended. Would you be able to provide some input here? I am specifically looking at the "lower calibration" state as I have yet to test out the other states. Only difference between the lower calibration state and say, acquisition, is that it is a shorter time period.

Thanks

[mcduff]

Haven't looked at in detail, but here is some advice, use the terminals not local variables, there is no reason to use local variables. Also there are VIs missing.

The lower calibration state needs TWO messages to function: a display lower calibration message and a data message. Are the messages in the right sequence? Think about combining your messages into 1, like the snippet shown.

mcduff

[atrinh]

Yes I do try and avoid using local variables when I can. For this instance, I have the graph control as a local variable because it will be called in two separate states (same graph for lower and upper calibration).

Regarding the second comment, I haven't had created messages like your example and I am not quite sure I understand. If I am correct, I think your example would require 1 queue that handles both a message (for state transitions) and another for data being read from the DAQmx function? I have 1 queue which handles a message (represented as an enum constant) and a second queue which takes data from the main producer loop into the display loop. I believe this is still a correct way of handling it, albeit messy because of all the wires?

I've reattached the program with associated subvi's.

Many Thanks,

[udka]

Why there is delay(Edit: wait)100ms? Anyway there is 10ms Timeout at dequeue element
-There is no need of -1 to event structure by default it is -1 unless you want to change
-How about creating project to group all the typedef, subvis together.

[mcduff]

Regarding the second comment, I haven't had created messages like your example and I am not quite sure I understand. If I am correct, I think your example would require 1 queue that handles both a message (for state transitions) and another for data being read from the DAQmx function? I have 1 queue which handles a message (represented as an enum constant) and a second queue which takes data from the main producer loop into the display loop. I believe this is still a correct way of handling it, albeit messy because of all the wires?

The idea is to use 1 queue send information around. That queue contains the next state and any data it may need. Note a state like "EXIT" would not need data, but one like "PlotStrain" would have the State "PlotStrain" along with its data values in variant form, that can be converted later.

mcduff