Cycle Testing based on AI (Compare functions slowing the code drastically)

[Osa_111]

Hello Everyone, 

I am having an issue with a code that I am writing for a cycle testing. I am trying to digitally cycle (close and open) a directional control valve based on an analog input (pressure). When the valve is energized, the pressure increases to > 420 psi in around 50 ms. When the Valve is de-energized, the pressure drops to below 120 psi in around 50 ms as well.  At each pressure, there is a software dwell time of 100 ms. 

Sequence of operation:

- Energize the valve.

- Once the pressure is >= 420 psi, wait 100 ms (dwell), then de-energize the valve. 

- Once the pressure is <= 118 psi, wait 100 ms (dwell), then energize the valve. 

- Repeat until the demanded cycles are met. 

Software/Hardware used: 

cDAQ-9184 

NI 9203 (AI 4-20mA for pressure - 1 channel is used only)

NI 9375 (DI/DO two lines are only used for the Valve)

Pressure Transducer Response time (<5ms)

Labview Version 16 

The code (attached):

There is a while loop that has two DAQmx (digital output and analog input) with On Demand Sampling. I have a wait function of 1 ms so my sample rate should be 1kHz at anytime but the dwell time (the sample rate should drops to 10Hz during the 100 ms dwell time).  

Problem:

I tried the code first with a simulated task, and it was working fantastic. I tried it then with the actual instruments and setup, the code was very slow -- the loop was running  between 180 and 200 iterations per second only. I changed the dwell time to 0 ms and the wait function to 0 ms, the loop was still running 180 to 200 iterations per second. I removed all indicators, controls, reduced case structures, etc, and I put two tick timers outside the loop and took the last value of the iteration, it was still the same speed.

Cause:

When I disabled the comparison function, which check if the pressure is above 420 psi or below 120 psi, the loop start running almost 1000s iterations per second (dwell time was 0 ms and valve values were not cycling).

So I figured that the comparison function is the problem or one of the problems, but I didn't know how to overcome it. Does anyone know of any method/approach that I can apply in this case to increase the code efficiency?  

Approaches I already tried:

I tried a producer + consumer approach but it had the same problem. Even though I had a continuous sampling of pressure in one loop with a queue to the other loop where my digital outputs are. I used tick timers to count the dwell times instead of wait functions to make sure both loops are running the same speed, but still the compare functions were causing the code to slow down drastically. 

In a perfect world, I should be able to do 3 cycles(ish) per second. I was able make another temporary inefficient code that do 2ish cycles per second (Energize valve - wait 200+ ms - De-energize valve - wait 200+ ms, repeat). There are a lot of problems with this approach but it is working for now or as long as my my instruments response time is not changing. 

Sorry for the lengthy post but thank you for your time if you read all the way through here 🙂 

[Kevin_Price]

First, congrats for an unusually well-asked first question.  All the context and detail are very helpful and much appreciated.

That said, I think you've diagnosed this wrong.  There's no way that the simple comparison functions are the root cause of your slow down.  It's gotta be something about the DAQ tasks themselves, likely related to latency over the USB bus.

What was your method for "disabling the comparison function"?   If you simply ran the False case of the outer case structure, you would output a default value of Empty Array of Boolean to the DAQmx Write call for your DO task.  Odds are that gets treated as a no-op (maybe producing an undetected error), bypassing the normal time duration needed and increasing your loop speed.  If that's the case, you've pretty much identified the DO as the culprit.

Other notes: 

1. You aren't catching or reacting to DAQ task errors in your loop.   You should.

2. Windows will not reliably run 1 msec loops.  A loop with nothing but a single 1 msec Wait in it will have significant variation in timing from one iteration to the next.

3. Your dataflow makes certain time consumers additive.  First there's an AI Read that must complete before feeding data to the upper case structure.   Inside the case structure is a possible dwell time Wait.  This case structure must complete all code before feeding output data to the DO Write.

   You have another unconditional 'loop time' Wait that's in parallel, so it won't be additive to the other stuff.

4.  Once you make your code error-aware, focus on the DAQ tasks.  Comment out the DO and AI one at a time to see how each contributes to time consumption.  So far, there's a little bit of evidence that DO may be a major contributor.

-Kevin P

[Osa_111]

Kevin, 

Thank you a lot for your time and the recommendations. 

First, congrats for an unusually well-asked first question.  All the context and detail are very helpful and much appreciated.

---

I have read (and learned) a lot from the answers in this form -- thanks to you and the many other helpful members as well. So I guess I also learned how to ask questions properly from all of your helpful answers. 

---

What was your method for "disabling the comparison function"?   If you simply ran the False case of the outer case structure, you would output a default value of Empty Array of Boolean to the DAQmx Write call for your DO task.  Odds are that gets treated as a no-op (maybe producing an undetected error), bypassing the normal time duration needed and increasing your loop speed.  If that's the case, you've pretty much identified the DO as the culprit.

Other notes: 

1. You aren't catching or reacting to DAQ task errors in your loop.   You should.

2. Windows will not reliably run 1 msec loops.  A loop with nothing but a single 1 msec Wait in it will have significant variation in timing from one iteration to the next.

3. Your dataflow makes certain time consumers additive.  First there's an AI Read that must complete before feeding data to the upper case structure.   Inside the case structure is a possible dwell time Wait.  This case structure must complete all code before feeding output data to the DO Write.

   You have another unconditional 'loop time' Wait that's in parallel, so it won't be additive to the other stuff.

4.  Once you make your code error-aware, focus on the DAQ tasks.  Comment out the DO and AI one at a time to see how each contributes to time consumption.  So far, there's a little bit of evidence that DO may be a major contributor.

---

---

I'll need to edit my post above. I made a mistake when I said the loop was running 1000 iteration per second --- that shouldn't be possible and I'll explain why below. Most likely, I put the AI read on continuous sampling mode and the DO was on no-op as you mentioned.  

I made the VI below really quick to test the DAQmx speed in 4 different scenarios and see how fast they can run. All my tasks here were set to On Demand Sampling. 

Scenario A: DAQmx AI read alone (On Demand) - Diagram-1 enabled only

Speed: 360 iterations per second (2.7 ms per iteration)

Scenario B: DAQmx DO alone - Diagram-2 enabled only

Speed: 360 iterations per second (2.7 ms per iteration)

Scenario C: Diagram-1 + Diagram-2 enabled only 

Speed: 215 iterations per second (4.65 ms per iteration) - (both loops had same speed)

Scenario 😧 Both DAQmx AI read and DO in same loop - Diagram-3 enabled only

Speed: ~200 iterations per second (5 ms per iteration) 

Scenario D explains why I am having 180 to 200 iterations per second for the code attached in the first thread. 

I never used Labview before to perform data acquisition and control in the millisecond time frame. Do you believe these number are the best that I can get with the instruments (+ software) that I am using? Or is there any way to go faster (especially in scenario C or D)? 

Thank you again for your time and help, they're really appreciated. 

[Kevin_Price · Accepted solution]

Generally speaking, you're probably pretty close to maxed out with your cDAQ system.  Here are 2 ideas that might help you incrementally, but probably not dramatically:

1. For the DO task, you really only need to perform the Write when it's time to toggle the control valves.  You don't need to repeatedly write the same data over and over during the other loop iterations.

2. For the AI task, you could consider a buffered acquisition.  Then the driver will stream data across USB in the background and your call to DAQmx Read will be retrieving from your PC, which should be a faster operation.  If you do this you should probably read all samples available.  This is the default when you don't wire a # to read.

   Note however that even if this speeds up your loop, it doesn't tell you exactly how old that "most recent sample" is at the moment you retrieve it from the PC buffer.  There's a chance that your AI data both comes in faster *and* is more stale.

-Kevin P

[Osa_111]

Kevin,

Thanks again for your time. 

Yeah I definitely need to do the first idea.

I'll also try the second idea as well and see how I can get it to work without acquiring old data. 

You have a good weekend, and I appreciate your help once again!