Set While Loop Timing Without Delay Function?

[Gan Uesli Starling]

I managed this once before. So it does work. A menu entry of some kind. A means of setting the iteration timing of a WHILE LOOP without any kind of delay or wait function inside it.

I'm looking directly at the VI's block function. I've been staring at it for hours. It's not even all that complicated: a screen and a half of well-spaced icons. Data lines not at all crowed. While running, it iterates nicely on precise 500ms intervals, taking readings and accumulating an average. Nothing in the task about timing. Nothing, anyhow, that shows as an icon.

Sadly, I can't share it here. Company will not allow. I remember thinking at the time, "How obvious! Why have it not always done it this way?" A menu selection of some kind, affecting data collection inside a While Loop. Who has clues?

[smarlow]

If you are using a DAQ device, it's probably a hardware-timed loop.  The loop iteration interval is determined by the amount of time it takes to acquire the data.  For example, if you define a DAQmx task to acquire data at 1 kHz sample rate, and acquire 500 samples, the DAQmx read operation will take 500ms.

[Gan Uesli Starling]

On 10/25/2023 at 4:45 PM, smarlow said:

If you are using a DAQ device, it's probably a hardware-timed loop.  The loop iteration interval is determined by the amount of time it takes to acquire the data.  For example, if you define a DAQmx task to acquire data at 1 kHz sample rate, and acquire 500 samples, the DAQmx read operation will take 500ms.

Would not this task appear in the block diagram? If so, I fail to find it. Nor yet any file path leading to or from anywhere which might be a task. Still, what you describe jostles an inkling of memory. The actual loop time is 502 ms.

Edited October 30, 2023 by Gan Uesli Starling
error in unit of measure

[mhenz]

This VI

also iterates nicely on precise 500ms intervals, why?

Solution: there is a delay behind the case structure:

[crossrulz]

One of the few times Block Diagram Cleanup can be useful.

[smarlow]

3 hours ago, Gan Uesli Starling said:

Would not this task appear in the block diagram? If so, I fail to find it. Nor yet any file path leading to or from anywhere which might be a task. Still, what you describe jostles an inkling of memory. The actual loop time is 502 ms.

If there is no DAQ task in the loop, how are you collecting samples?  It's going to be impossible to tell you what is happening if you don't post the diagram.

[LogMAN]

I agree, without any code it is difficult to explain how your particular VI works.

That said, when using DAQmx you can just define the sample rate of your task and request the desired number of samples in order to achieve the desired loop time.

Here is an example that reads a voltage from a channel at a rate of 1000 Hz, 500 samples at a time.

The read function is blocking, so the loop runs at exactly 500 ms intervals.

 

Timing Example.vi

[Gan Uesli Starling]

I have pared down the VI to its barest essentials ... which I am now able to share. As you can see, there are no delays. Yet it is iterating on 500 ms very precisely (after cycle zero). How so?

I wrote it myself, a year ago, and thought it very clever at the time. Now, though, I'm at a loss.

However I did it, when I email it to myself on another PC, running a different version of LabVIEW, and assigning a different cDAQ device ... still it adheres to the 500 ms loop timing. Maybe this serves as a clue?

Example.vi

Edited October 31, 2023 by Gan Uesli Starling
Appending additional info.

[crossrulz]

What hardware are you using?  I see it is cDAQ, but what modules and chassis?

[Gan Uesli Starling]

3 hours ago, crossrulz said:

What hardware are you using?  I see it is cDAQ, but what modules and chassis?

cDAQ NI-9174 with an NI-9219

[smarlow]

The DAQmx Read VI is controlling the timing, although it's not clear how from your example.  You are not calling the DAQmx Timing function in the example, so the sample rate and number of samples per channel are not defined in the task.  See LogMAN's example in the post above for controlling the loop timing with the DAQ hardware operation.  He has defined the DAQ task to read 1000 samples at 1 kHz (the sample rate input is unwired, but has a default value of 1 kS/s), using the DAQmx timing function.  Inside the loop he is reading 500 samples at 1 kS/s, which will take 500ms.  If you want to change the period of a loop that is timed by a DAQmx read operation, you need to call the DAQmx Timing function outside the loop as LogMAN has done.  Changing the sample rate and number of samples to acquire will change the loop timing.