DaqMX timing with DI and DO tasks

[GOB34]

Understood - but at some point doing this with producer/consumer QMH leads to an unmanageable number of queues/ messaging loops!

If you put each task in a different loop how do you usually record all the data so it lines up with all the channels on all modules?

[GOB34]

one more follow up to this-

Once I write to a DO module, do those values "stick" - i.e. will the module retain those values until I change them?

Or do I need to have the Digital write in a loop constantly writing over the same values?

(sorry for the basic question but it is related to the timing questions)

to clarify, there is a loop running but the digital write only happens on demand. So the task exists the whole time.

[GerdW]

Hi GOB,

---

@GOB34 wrote:

Once I write to a DO module, do those values "stick" - i.e. will the module retain those values until I change them?

Or do I need to have the Digital write in a loop constantly writing over the same values?

to clarify, there is a loop running but the digital write only happens on demand. So the task exists the whole time.

---

• The values you write to the DO "stick" as long as you write the next/new value. (You could have tested this on your own quickly with your hardware…)
• You don't need to write "constantly" the same value, but on the other hand it doesn't matter when you write the same value again (and may simplify your VI)…
• The task should always live as long as your VI (or loop) keeps running…
• Keep in mind: the DO state ALSO "sticks" when you end your VI. When you need a defined state after finishing your VI then you need to set that state before exiting the task (and VI)…

[GOB34]

Thanks GerdW - I don’t have access to the hardware right now so can’t test DO’s on the physical device.

 I appreciate your explanation!

 Any advice on my question to message 10 above on recording the data from tasks in different loops as you described above?

[GOB34]

@GerdW-

There is still something baffling me in understanding software timing with acquisition when using the QMH structure similar to the one in the Continuous Acquisition and Logging (daqMx) template.

this is my difficulty:

The messenger loop sends messages to the acquisition loop via one queue. So the acquisition loop only runs when a message gets dequeud from that queue OR if I set up a timeout on that deque function.

As built in the template, the acquisition loop is set up for the loggging state to acquire samples then send a message to itself in the acquisition queue to go back into the logging state and repeat on and on.

this is great if using hardware timing.

if using software timing, how do you accomplish a set sample rate?

I can see making the acquisition loop a timed loop, and removing the step where the logging case calls itself - but then aren’t things just determined by the timeout on the messenger loop dequeue? 

If I keep the setup with the logging queue calling itself won’t it just run continuously at max speed because the queue is always full?

do I put a delay (wait in ms) the actual acquire step? I’m afraid of this as (1) it is sort of buried and (2) it seems like there are lots of other contributors to when the time is that that step would actually execute.

as always i appreciate your help and guidance!

[GOB34]

Would this approach work:

put a timeout on the deque of the message queue in the acquisition loop;

this will be the data rate;

Check the state enum in the “ ” case and if in “logging mode” have the “ ” case change the state enum to “acquire” ; -or- should I enqueu a message to data queue to acquire here?

go to acquire state and do one round of daqmx read (or whatever); enqueu data to data queue;

keep state in “log” but don’t send enque message to data queue to repeat logging

i will put the code here once I experiment with this but appreciate any advice along the way!

[GOB34]

Is it as simple as removing the daqMx timing in the configure hardware VI (attached) and putting a wait in the Acquire.vi?

It works, *except* I have found this issue:

In the Main VI (from the template of the Continuous Acquisition and Logging (DaqMX)) -:

• If sample rate set in the delay above is relatively quick (20Hz) - works great. Can pres start, stop etc as many times as you want. 
• If the sample rate is slow (1 Hz), it works the first time you press "Start" - then if you press stop and the second time you press "Start" the data do not update. If you press stop then "Start" again, it works! This pattern continues.

I've tried to track down if this is a result of the acquisition queue calling itself to aquire again via it's own queue, and there being an issue where the queue is already destroyed but I can't seem to track it down - it looks like it is doing the right thing flushing the queue on stop command from the messenger loop.

Thanks for the help!

[GOB34]

Hi,

any thoughts on this last post?

thanks!