Create a NI based PID control system? Advice?

[Vr6Fidelity]

I need to make a new PID control system using labview. I have a magnetically levitated shaft, spinning at 80,000 RPM and is subject to axial loads.

It is a pretty simple. One axial input, one output to an amplifier.

I need it to be fast, dynamic and stable.

Does labview have these capabilities? I suppose I would need to scan the one input channel continiously, and be continuously writing a PID derived control signal which would need to be smooth, obviously not notchy.

What hardware has the capabilities to read and write continuously and have the speed i require. I suppose 20khz input would be fast enough.

I have a current sytem that died on me (motherboard failure) but the computer which is a 486!, the card, the software are all SUPER old, and no one knows how to use it anymore. The DSP card company has been purchased several times and is totally unsupported.

So:

What hardware do you recommend?

What software? LV + PID toolkit?

Anything else?

[Graziano]

Hi Vr,
   I'd recommend LV + PID + Real-Time module, as software, and compact RIO.

   Actually, I don't know in depth compact RIO, since I use compactFieldPoint, and I don't need to do such fast sampling! (Yes, I know that 20 kHz is not fast, but fieldPoint is intended for non fast acquisition, but maybe some Ni guy will correct me...).

    Anyway, if you consider to build a PC based instrument, still consider real-time module.  Or, in general, you may look at NI boards with FPGA onboard, but I don't know these in depth too....

   Hope it helps...

graziano

[Vr6Fidelity]

What is FPGA anyway?

Do I really need realtime? It is quite expensive.

I did look at the compact RIO platform, that thing looks pretty sweet. Does the system have the capability of continuous input and output?

[Graziano]

FPGA is a reconfigurable logic, I can describe it as a kind of "programmable hardware", in the sense that the actual chip is defined in a high level description language, which define connections between logical block of the FPGA. Of course, you can find better definitions on wikipedia, i guess....

Anyway, you don't need to care about how does it works: it matters that these devices are used in real-time, reliable acquisition.

Real-Time is expensive, but consider that you can get discounts buying NI Developer suite, possibly buy one that includes Real-Time and PID module, check your country's sales representative.  In my company, we bought NI Developer suite "Control Edition", but it was about 2 years ago, nowadays, I don't know what similar product is offered by NI...

Yes, since cRIO is meant for reliable DAQ, it can do continuous sampling 24/24, 7/7.  Only take care to write a reliable software in labVIEW!

Hope it helps.... have a nice day!

graziano

[Graziano]

Here's the link for NI developer suite home, U.S. site.

[Vr6Fidelity]

Which add on has the PID toolkit and realtime?

What is realtime anyway? what is the difference between RT and regular LV?

[Ben]

An important factor in PID's is the update rate. Although I can not cite a source at the moment, it has been shown that there is an upper limit beyond which more frequent updates have no appreciable effect on improving the performance of the system.

So...

You should give some thought to how long your system can go without an update of your control signals.

If the update rate is low enough, RT (Real-Time) may not be required.

BTW:

Real-Time is a term that is used to describe a system who's response to a stimulus is bounded in time (un-like Windoze that can go off into la-la-land occationally).

Ben

[Graziano]

Hi Ben,
   I think that in PID (and control problems in general) Real-Time is mandatory, (except if the system has an upper limit phisically not exceedable, for example a PWM, in which at maximum, you have 100 % Duty Cycle, and in some case it is not harmful) .

   A common PC based application can hang indefinitely, so no matter how much time your systems can remain uncontrolled (it'd never be infinite!), you need to be sure to not loose control indefinitely.

   About your first statement, you're right, you can deduce it from basic Control systems theory, and you can also build unstable systems with "wrong" update rates (check this, it's been a long time I don't open that books! ).

    Waiting opinions on this....have a nice day!

graziano

[Ben]

Graziano,

I have controlled many temperature systems with a PC. I admit that temperature control is a slow process. But I mention this because it illustrates that as long as the output is updated frequently enough, the updates do NOT have to be periodic.

Additional point:

The PID VI that come with the PID toolkit will calculate the actual "dt" since their last call. This feature underscores the fact that PID updates do not have to be deterministic.

Have fun!

Ben

[Graziano]

Hi Ben,
   I suppose the problem is also the update frequency.  In theory,  a "slow varying" system has same characteristics as a "fast" one, only you'll have different time constraints for "closing the loop". Usually, the PC can hang for a while, and then resume, but you may have a system in which you must be sure that you never loose control, there you can't rely on a PC.  more, if you have to "close the loop" in some milliseconds, I think you'd better turn to Real-Time HW and SW.

   If I understand, you do non-uniform sampling (dt not fixed): I know for this there's much literature on this subject, so my advice is to check, to avoid building an unstable system. Just note that it is more difficult to model than "traditional" control systems.  Anyway, I suppose that NI PID toolkit embed safety someway, and check& fix for unstable behaviours....

   It'll be interesting to have a feedback.... sys!

graziano