LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can the loop time be more faster for this simple VI for PID control?

Hi all, 

 

I have a simple VI for PID control. 

360截图16720328446342.jpg

 

>The DAQ I use is NI USB 6211.

>It doesn't support the sample mode--hardware timed single point

>The program is software timed. Using my laptop, the loop time is around 1.1ms. The read vi. takes about 0.6ms, and the write vi. takes about 0.5ms. I found that at this situation, the CPU usage is less than 10%. 

 

My questions:

1. Can the loop time be even smaller with the current DAQ and laptop? I think I didn't make full use of the CPU. 

 

2. If I use a DAQ that supports hardware timed single point sample mode,  can the loop time be smaller? 

 

   I think the answer is No, because the loop time depends on the codes in the program, the codes is the same,  and the data transfer mechanisms for software timed(1 sample on demand) and hardware timed(1 sample HW timed) are both programmed IO  because there is no buffer used in both case

 

3. If I use a DAQ that supports both hardware timed single point and have a RT system embeded, can the loop time be smaller? 

 

    I think the answer is Yes, because the RT system has its only processor which can be used to fully focus on the task in the program, unlike the CPU of laptop which has to work on other tasks at the same time. 

 

Can anyone give me some advice on Q1? for Q2 and Q3, are my thoughts correct? 

 

Thanks in advance.

Jake

 

0 Kudos
Message 1 of 6
(2,846 Views)

Q1.  Probably not substantially.  USB latency is likely your limiting factor for DAQ I/O speed.   You *might* get some speedup by putting AI and AO in parallel.  To do so, you'd send your PID output to a right-side shift register.  The AO call would get its value from the left-side shift register.   (Consider treating iteration i=0 as a special case for AO where perhaps you don't write at all?).

 

Q2.  Very likely.  HW-Timed Single Point mode is supported on devices that connect via *low-latency* buses such as PCI/PCIe, or PXI/PXIe.   (Not sure, but maybe due to the bus connection supporting DMA?)

   I was recently in another thread where I slightly modified a shipping example and got 5 kHz loop rates with hw-timed single point operation and a PCIe-6341 X-series board.  

 

Q3.  RT combined with hw-timed single point would give you more *deterministic* timing with less jitter.   Determinsm is typically the most important consideration for PID hardware control.  Just note that running under RT won't necessarily be faster and it might be slower -- different RT targets have varying amounts of raw processing power.

   

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 6
(2,822 Views)

Hi Jake,

 

to add to Q3:

Most RT systems from NI (like cRIO, sbRIO) come with a FPGA.

Using this hardware you can substantially increase the loop iteration rate to the max sample rate of AI and AO…

 

As you have asked similar questions in the past: You need to collect your requirements before choosing the hardware! When you need high (and reliable) iteration rates you need to use something else than a Windows computer with an USB device…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 3 of 6
(2,816 Views)

Your read and write is currently happening sequentially- making them parallel as suggested above should make it much quicker. At max you could see a 2x speed improvement from what you have now, though it probably won't be *quite* that fast. I bet you could do 1.5x without breaking a sweat.

 

Edit: Actually, I appear to be incorrect. I just ran a test using your VI as-is on a USB-6229 and was seeing around 2-3ms execution speed, then ran it with a shift register- it was closer to the low 2's, but still not 1.5x as fast. It's probably the overhead of the USB bus doing its thing. I bet it can't actually read and write to the bus simultaneously, so even though it's "parallel" in LV it's not actually executing in parallel. Note that in an FPGA this WOULD happen in parallel, just not for this example. I do wonder if it was two separate devices though...

Message 4 of 6
(2,787 Views)

What are you trying to control? Too fast pid for certain control loops for instance hydraulic supply pressure or return pressure might end up unnecessary hunting between max/min PID outputs. You could still get away from hunting by finely tuning PID values and have a ramp on set point control. 

 

As well as above suggestions, you could increase PID speed by changing while loop with timed loop. Timed loop works even under windows target. Simply right click while loop and select 'Replace with Timed Loop'. 

 

Also when you use FPGA target, you will not use DAQ functions to read and write outputs. You would be rather reading directly using FPGA I/O nodes. You will have significantly faster loop as well as deterministic control 

ATE and Labview Consultant
https://www.easybodge.com
Message 5 of 6
(2,770 Views)

Given that I don't have any USB daq to test on, the simulated one runs on ~0.2ms. Do you use a USB 3 port, or can you test and compare in one? Can you test the code on a desktop?

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 6
(2,639 Views)