Which NI device can be used to achieve fast loop time in a simple PID control application?

[cli21]

Hi all, 

I built a simple PID controller using labview based on single-point IO, and the device I used is NI-USB 6211 DAQ. I found that the loop time is around 1.1ms which is not fast enough for my application. I was told the large loop time is due to the USB 2.0 bus latency, and I was suggested to use a device which operates on PCI or PCIe buses. (please refer to the following original thread if needed)

https://forums.ni.com/t5/LabVIEW/Can-the-loop-time-be-more-faster-for-this-simple-VI-for-PID/m-p/384...

I know that NI M and X series cards support PCI or PCIe buses, but I don't want to use any of them because these cards have to be installed on the motherboard of a PC which is not convenient for my application where the device under test will very often be moved from one place to another. I would like to choose a more portable or external NI product. 

I then first looked into cDAQ and cRIO systems and found that their chassis don't support PCI bus. I then looked into PXI systems, they do support PCI, however, I think for such a simple control application as mine, there is no need to use such a powerful and expensive system. 

It seems there is no suitable NI device matches my requirements，i.e. supports PCI bus for faster single-point IO speed and works externally to a PC for portability. Is this really the case? 

In addition, in the above original thread, I was told that using a FPGA can shorten the loop time a lot ( the loop time can be as short as sample time?). I am new to FPGA and know little about it. I will be grateful if anyone could explain to me why FPGA can shorten the loop time? 

If FPGA really works, I want to buy a NI myRIO-1900 wihch combines a Xilinx FPGA and a dual-core ARM Cortex-A9 Zynq processor, I wonder will this portalbe device achieve my goal? I found that the bus connector for this myRIO is either usb2.0 or WIFI, if this device can achieve control with small loop time, does it mean the loop time is not limited by the latency of the bus used?

Thanks in advance!

[crossrulz]

For industrial applications, you will want to look into the sbRIO line.  Architecture-wise, it is very similar to a cRIO (RT microcontroller with an FPGA).  And, yes, you will probably want to put your PID code in the FPGA and use the RT as a way of logging and/or sending updates to the PC via an Ethernet connection.

[Kevin_Price]

To the OP: please take this in the spirit it's intended -- an attempt to be helpful along with a heavy dose of pragmatism.

The recommendation from crossrulz is sound in terms of hardware capability but it would need to be implemented by a relatively advanced LabVIEW programmer that's already familiar with both RT and FPGA particulars under LabVIEW.

I was in the thread you linked and another thread of yours about the same app some time ago.  I mean no offense, but I don't suspect you're ready to tackle the learning curves involved in a short time frame.   Heck, *I'm* not ready to handle the FPGA part and I've been doing regular LabVIEW since before Y2K.

So from a very pragmatic point of view, take a step back to assess the following likely tradeoffs:

1. Go with cRIO or sbRIO, hire out the programming to an Alliance Partner with appropriate expertise.  You'll need to spend time carefully defining *all* your requirements up front.  You'll get a package that meets those requirements in a reasonably short time frame.  It'll cost you $$$ to hire this expertise for such custom work.  Because you won't have gone through the learning curve yourself, you may not be able to make your own mods and upgrades to the delivered code.

2. Go with cRIO or sbRIO.  Do it yourself and tackle the learning curves.  You should still spend time carefully defining the same requirements up front.  You'll spend a lot of time learning, trying, backing up, trying again, etc.   The project won't be "done-ish" for a long time.  The end result probably won't meet all the requirements reliably but may be close enough often enough to live with.  You won't be spending direct $$, but again, you'll spend lots of time.

3. Put together a desktop system on a cart.  Make it RT-compatible, but stick with Windows as an OS (for now).  Put an X-series PCIe card in it.  Define your requirements up front.  Spend a much more modest amount of time developing the code yourself.  The end result may not quite meet all requirements all the time (due to Windows), but may be close enough often enough to live with.  It's less convenient to move around than a laptop, but likely manageable.

4. Consider converting the desktop to LabVIEW RT.   Use a separate hard drive.   Expect some significant learning curve, but quite a bit less than what you'd have faced in #2.  Partly because it's only RT instead of RT *and* FPGA.  Partly because you'll be starting with generally-working application code.

I can't say which option is "best" because it depends on your priorities.  Just want to give you a wider view into the tradeoffs that come with different approaches.

-Kevin P

[bseguin]

I have some doubt about the requirement speed. What are you trying to control?

Most of the time, people have misconception about PID. PID can in some way predict your system value in the future. witch mean that most of the system out there can works very well with a loop of more than 1 second. SO the question asked in other thread from you, What are you trying to control?

I am afraid that you try to over design the thing.

I was able to do system with RIO and with DAC as well as with small controller like Arduino. The spec varies from +- 0.001 degC to having system that control 32 different heater on the same DAQ. I was also be able to control steam valve and chamber big enough to fit a car inside. I was also be able to control pneumatic system. I can even tell you that I had to teach how PID are working to environmental chamber manufacturer who where our supplier. So before designing anything, be sure you understand what you are doing. If not, as suggested above, use a trusted supplier to do it for you.There is a lots of physic and mathematics knowledge involve in any system that you control by PID and when PID goes wrong, you might even kill someone.

Benoit

[wiebe@CARYA]

And of course PID, being the general "go to" controller, is usually OK-ish at best. Or so my process engineer keeps telling me.

PID is easy, and well accepted, but it isn't very good at controlling processes. It is often a good enough, but rarely the best solution.

They are usually (per definition) fast with overshoot, or slow with no overshoot. There are solutions, but AFAIK, they are all hacks around the standard PID algorithm.

PID might not be the best solution.

[Yamaeda]

1 ms sounds slow to me, but that might be a USB thing as you mention. You can e.g. offset it by grabbing 10 samples at a time and work on that. 

/Y