Advice for communication using multiple consumer loops

[atrinh]

-The data you keep on inserting into array, isn't it you should reset when it enters stop low cal state?

Yes it does get reinitialized to an empty array but this is done in the initialization state for lower and upper calibration

-the shift registers which you initialized are not actually empty(some four elements are present with 0s

Which shift registers are you referring to? The ones containing queued data? Or in the lower display loop?

-I didn't see where you are enqueuing the exit state(where is exit button and event handling for that?)

I have not created a state for this yet but it will be a simple T/F button

-What happens if the daqmx task is not done?(are you sure this is not enqueueing data again?)

I think this might be an issue here. Based on my probe and watching how the program operates, I think it goes from initialize to a lower calibration state, collects all 2000 samples, then flips to stop lower cal and this is where we get a graph update. I thought I had designed the program so that when 1 sample is read by the DAQmx subvi, it is enqueued and subsequently dequeued in the display loop. This is my intention but it doesn't seem to operate this way. Do you have any insight here?

I have the check if task is done DAQmx subvi outputting that the task is complete.

[atrinh]

Here is a program that I want to emulate:

https://decibel.ni.com/content/docs/DOC-26558

The clustering of data is more than I need. I just want a simple acquisition of a single DAQmx device, queue the data so I can dequeue for display and writing in two separate loops. Is my design incorrect?

[mcduff]

Please do not take this personally, but it appears that you are somewhat new to LabVIEW. If the JKI template is giving problems, then go to Create Project and choose Simple State Machine. Keep everything in one loop. Multiple loops are fine, but may not be needed here and as you are finding out harder to debug.

I have opened the JKI template and poked around - I quickly became lost in the Parse State subvi with the state and args, which is why I am having a hard time understanding how this template works.

Here is how the States work in the example I sent you

UI: Status >> All is Well

Where UI is the category. Not really needed but useful for you as a programmer to organize your states. For example, I would suggest you have a DAQ category, with states like DAQ: Init, DAQ: Configure, etc

Where "Status" is the state that you want to go to
Where "All is Well" is the argument, this is optional. Here in the example I sent you All is Welll would be written to the status indicator.

All the information for each state is contained in the cluster that is passed around the loop, just unbundle. So you won't need to have many locals. Just my 2 cents.

mcduff

[Mark_Yedinak]

Why do you have 10ms timeouts on your queues? Doing so creates a polling system which is inefficient and uses quite a bit of CPU doing nothing. Also, in your fourth loop you are doing a queue status to get an element of the queue. this makes no sense. Simply use the dequeue to get the next element. Since you are using queues as broadcast mechanisms I would recommend using user events instead. Queues are good for communicating many-to-one. Events are a good way to communicate one-to-many since all tasks which registered for the event will receive it. It also seems rather strange to use the same states for each task. As can be seen in your code each loop ignores a fair portion of the messages since it does not apply to that task. Each task should have its own states with the possibility of some states being duplicated across tasks. The code will be much more complicated to understand if everything is trying to use the same states. Messages should only be sent to a task when it is needed and only messages that truly apply.

The "calibration tab" feeding the two case statements in the event loop may not work as you want. Since they will only update once and most likely will not be correct since they will update before the event occurs. If there is a delay before the next event and the user changed tabs the strings will not be processed since they already have been.

Each task/loop should serve a single purpose and only be concerned with messages specific to itself. A good design would have a defined set of messages for each loop. Independent tasks should not know or care about states of other parts of the system. They should maintain there own state machine and be updated at the appropriate times with the appropriate messages.