Timed while loop is not executing fast enough

[SiaVahidi]

Hello all,

I need to trigger some valves cyclically and read the pressures simultanously. The timing for the valves need to be precise while the pressure reading does not really need to be controlled as long as I get some data. To do so, I am using a timed while loop to trigger the valves alternatingly. However, the loop tends to slow down. I have tried different pressure reading rates and methods and still have the problem. Originally, I want the valves to open/close every second but after a while this time increases to more than 1 second. I have attached the VI. Any help would be appreciated.

Regards,

Sia

[Norbert_B]

Sia,

which OS are you running on?

Also NEVER ACCESS FILES IN TIMED LOOPS! This is non-deterministic and the easiest explanation for inconsistent behavior.

Norbert

EDIT: You shouldn't use DAQmx Assistants in TL (Timed loops) either. They bloat execution code and will also contribute to late finishes. Use DAQmx functions instead with placing DAQ configuration, start and stop outside the loop and only read/write inside the loop.

[crossrulz]

How precise of timing do you need?

1. Timed Loops are basically a waste in Windows.

2. Use separate loops for your data acquisition and logging.

[Bob_Schor]

In a single loop, you have the following "tasks" to do:

   Acquire a single sample from 10 different Channels.

   Display each Channel on a separate 1-channel Chart.

   Do some simple logic and update some arrays.

Now, the Principle of Data Flow says that every task in the Loop must run before the loop can repeat, no matter whether or not it is an "untimed" or "timed" loop.  In addition, you cannot Display data until after you have Acquired it.  Finally, while I haven't tested this and this might not be accurate, I imagine that it takes more time to plot 10 1-channel Charts, even in parallel, than a single 10-channel Chart.

Here's a suggestion -- play "Engineer" and do a test.  Put the DAQ Assistant in a loop by itself, and see how fast it can run (maybe put it in a For Loop with a count of 1000, take the Time before the loop, the Time after, subtract, divide into 1000, and you'll have the loop speed in Hz.

What does this DAQ Assistant do?  What are you reading?  Are these the pressures that you read at 1 Hz and "do something" with?

Why not rethink the problem and make the Acquisition "smarter" (starting with getting rid of the DAQ Assistant and learning to use DAQmx directly -- do a Web Search for "Learn 10 Functions in NI-DAQmx", read the article, and apply the principles).  If you set your DAQ device to sample continuously at 1Hz, it would be the "clock", and when the points arrived at 1 second intervals, you'd have an entire second to "do everything else you needed to do inside the loop".  That's probably the way to go.

Since you seem to be learning LabVIEW, I'll let you play with this.  I'm sure you'll be able to improve it.  [Oh, yes, if you are getting rid of the DAQ Assistant, do yourself a favor and also get rid of those "Dynamic Wires" -- use simple Arrays instead).

Bob Schor

[SiaVahidi]

Norbert,

Thanks a lot for your response. I am using a 64-bit windows 7 enterprise. I have been trying to stick to DAQ assistant as I need the results quickly, but in the ned it seems like I have to go ahead and learn the DAQmx functions.

Regards,

Sia

[SiaVahidi]

crossrulz,

I need to provide a cyclic pressure by controlling the valves. So the consistency of the timing is more important than its precision (currently, after 15 minutes, I start getting occasional 2-seconds loops between my 1-second loops, and I assume it would get worse if I run for longer time).

1- I have also used a timeout inside an untimed while loop and had the same problem with timing. Except that in that case the valves did not slow down but I got a data aquisition error instead.

2- Do you mean having an additional loop with the "write to measurement file"? In that case could I just pass the data through a tunnel and record the data?

[Norbert_B]

---

@SiaVahidi wrote:

[...]So the consistency of the timing is more important than [...]

---

Exactly this is called "Determinism". Windows is no deterministic OS, so it is the wrong choice.

That being said, if the required determinism allows a jitter in low-digit seconds, Windows is sufficient. If the requirment is to have a determinism with guaranteed jitter less than ms range, you have to use a Real Time (RT) OS.

So please review your requirements and make sure to pick the correct OS for them. You can configure Windows manually to have jitter in average of about 10 ms and less, however, there can be peaks to several hundred or thousand ms (so 0.x or x s). Please note that you must not use a non-deterministic system to control high safety applications where a jitter could result in human injuries and/or death!

You still can optimize a lot of stuff, the DAQmx part being one, getting rid of file IO the other and as the others mentioned: graphical update as the third part.

Norbert

[Norbert_B]

---

@SiaVahidi wrote:

[...]

2- [...] In that case could I just pass the data through a tunnel and record the data?

---

He refers to queues. You should look into Producer/Consumer design pattern for VIs to learn about the basic functionality.

Norbert

[SiaVahidi]

Bob,

Thanks for reviewing the VI. Here is what I am trying to do:

I have a constant pressure source, and I am producing cyclic pressure inside 5 tubes by closing/opening solenoid valves cyclically. The valves are to be closed once a pressure drop is observed for more than 5 seconds (tube failure). In parallel I have 5 tubes under constant pressure (solenoid valves always open until failure). I would need the pressure readings later on to

I was assuming that my task is easy enough to be done by DAQ Assistant. Previously, I was using a regular while loop which provided a precise timing for the valves. However, it gave me error 200279 after a while. I have attached the VI here. I think that also has to do with my loop being slow. Are you suggesting that using DAQmx would increase the efficiency and therefore the loop time?

Regards,

Sia

[crossrulz]

---

@Norbert_B wrote:

---

@SiaVahidi wrote:

[...]

2- [...] In that case could I just pass the data through a tunnel and record the data?

---

He refers to queues. You should look into Producer/Consumer design pattern for VIs to learn about the basic functionality.

Norbert

---

Actually, I am saying that the DAQ stuff and logging should be in a completely separate loop.  The cyclic valve changing should be in its own loop.  So one loop changes the valves and the other reads and logs the data, not caring at all about the states of the valves.