daqmx continously output

[Kevin_Price]

1. You're going to need to NOT use the DAQmx Timing vi to set up a finite pulse train.  To get retriggerable single pulses, don't use the DAQmx Timing vi at all.  Single pulses is assumed/implied when you don't use the DAQmx Timing vi.  You still need the DAQmx Trigger property node to set the "retriggerable" property.

2. My understanding is that the "initial delay" is a delay from the first trigger until beginning the first "high time" (assuming low idle state and high pulse state).  The "low time" is the delay from every subsequent trigger until beginning the "high time".  If "initial delay" == "low time", you should get consistent time delays from trigger edge to pulse edge.  That's how I read the article I referenced, though admittedly some parts of the article seem to say otherwise.

-Kevin P.

[elgigante]

Thanks a lot for the help, i am getting closer to my target.
Best regards meanwhile,
Peter Brugger

[elgigante]

Hi!
I have another question about the daqmx:
is it the correct way to aquire one single sample to define the task with the automation-manager, and then just use the daq-mx-read vi with analog-in-> single channel -> single sample -> double ?

I ask in respect to the speed, because i have to check the analog value in a loop as fast as possible to react appropriate.

Thanks,
Peter

[Kevin_Price]

I'm not familiar with the term "automation-manager."  I'm guessing this is either something new in LV 8 or else a feature known by a different name in my native country (USA), such as the DAQ Assistant or a MAX global channel/task.  I don't generally use these features so I can't comment on specifics.

However, given the earlier exacting timing needs of the counter tasks I suspect that the method you describe for Analog In won't meet your needs.  It sounds like you're describing a technique whose sampling rate depends on software loop timing.  I would have expected you to want timing based on a daq hw clock.

Here's a technique I've used that may work for you.  Outside your main loop, configure your AI task for continuous sampling and start it.  Inside the loop, you can use a DAQmx Read property node to specify that you want to read 1 or more of the most recently sampled values.  This gives you the freshest available data without ever needing to wait to retrieve future data.  The properties in question are "RelativeTo", and "Offset".  If you simply want the N most recent samples, set RelativeTo=MostRecentSample, Offset=-N.

You might get more speed by setting those properties just once after starting the task and before entering the loop, but am not sure I've tested that.  In my recent app, I always set them inside my loop because some function calls wanted recent data and others wanted to wait for future data.

-Kevin P.

[elgigante]

Hi!
i like that idea, but unfortunately i can't find a way to get values out of that read-node. there are only config-items, no item like "value". i did the config as you said above and tried to read the data from the read-vi (which is now outside) but the values don't refresh.
So please where can i get the values from?
Thanks,
Peter

[Kevin_Price]

Sorry, I didn't explicitly mention how/where to read the actual AI values.  Here's how: INSIDE the loop, right after calling the DAQmx Read property node, call the standard DAQmx Read.vi with "# to read" = N.  (same N as previous post)

-Kevin P.

[elgigante]

Hello!
Yes, now it works well!
Thanks so much for your help!
Best regards,
Peter Brugger