Can a PC perform (near) real-time?

[Novgorod]

Hi,

I'm wondering how much of a "real-time" application I can get away with by just using a normal PC with DAQ hardware...

Currently, I'm setting up an optical interferometric delay-lock system for a project and trying to figure out what's the best way to implement a PID controller for it. The error signal is simply derived from a photodiode and the control feedback is done via a piezo actuator stage. Well, I could just use a dedicated general-purpose PID module but they seem to have problems with a periodic error signal and (at least the affordable ones) have a bit of a limited functionality, e.g. a limited range for P/I/D and no adjustable filtering. It seems like a perfect job for a low-end microcontroller, such as an Arduino - there is even a limited Labview compiler available for it. However, I might quickly run out of memory and CPU power if I want to do some advanced processing (FFT, filtering, logging etc.). On the other hand, anything with the NI realtime OS (cRIO etc.) seems to be extreme overkill for this task (not even to mention the price).

So I did some initial tests simply using a Windows PC with NI DAQ hardware and a basic PID loop - and it seems to run really fine. Since the PID loop involves a mechanical piezo stage, I "only" need few kHz of bandwidth, surely not more than 10kHz, and a loop time of ~100µs seems to be no problem for the PC and DAQ hardware. The performance might change once I start doing data processing and logging simultaneously, but this can probably be leveraged by assigning the PID-loop to one CPU-core exclusively. Of course I don't trust Windows with all its background stuff going on to be realiable enough - a single hickup can screw up the lock and make it jump to another optical cycle (the error signal from an interferometer is periodic and thus ambiguous). Is it worth to switch to some stripped-down Linux OS (with Labview support of course) to increase reliability or is there a smarter way altogether?

[crossrulz]

Another option I have not played with yet (never quite got the excuse to try it) is to use one of the RIO Ethernet expansion chassis.  They are just an FPGA (no RT) and you communicate with a version of Shared Variables.  Not so good for streaming data, but for just setting your PID coefficients, it would work well.  The NI-9147 goes for $699, which is about 1/3 the price of the cRIO-9064 that I have liked to use for most applications I have ran into over the last couple of years and about 1/2 the price of the cRIO-9063 which is a lower end version of the 9064..

[James_McN]

I would second crossrulz comments but correct and say you can also do some data streaming (with the ethernet versions you get the DMA FIFO API (but not DMA under the hood, the etherCAT is the more limited version that has the shared variable like experience)

As you have said you might be able to get a PC to keep up at the minute but there is no guarantee of that always working. LabVIEW on Linux might be possible but officially supports a subset of distros so not sure how much guidance to expect on stripping one down, and even then unless you add the real time extensions I don't believe there are any guarantees it will always run well (but likely will be better than Windows)

[Novgorod]

Thanks for the replies. I see, the 9147 seems to be the cheapest real-time system but it requires FPGA programming, which I've never done before (and I would really like to avoid opening that can of worms ). Even so, with 16bit ADC and DAC modules and the required accessories the price quickly moves into the realm of overkill for a "tiny" project like that. The cheapest NI-DAQ device suitable for the job would be a NI USB-6002 ($379) and I think that USB 2.0 should be accessible with less than 100µs of delay (so far I've only tested it with a more expensive PCI-e DAQ card), so maybe it's worth to pursue the PC solution first, since it's the cheapest and (at least for me) by far the easiest... Also, the application is not super critical and would only cost few hours of time if the PC screws up. It must work reliably (i.e. without more than ~1ms-long hickups at a time) for a period on the order of 10h and I'd be already happy if it would do it >90% of the time ;)...

[James_McN]

If you can tolerate that then certainly give it a go. You may notice quite a difference between USB and PCIe. USB is notoriously unpredictable since it depends on what else is running on the "hub" (even if it is internal to the PC) and has a relatively high latency. It sounds from this stack overflow that it is likely to be 125us or 1ms.

Also if you do try this make sure you disable USB power saving on the PC - they like to turn off the ports after a while if the computer is inactive.

[crossrulz]

I will second the avoidance of using USB.  With a test system I and working on right now, I had all kinds of problems getting a USB-6112 to work reliably.  The fix was to move which jack I had a USB-Serial adapter plugged into.  Apparently that caused a conflict of some sort on the hub.  PCI(e) and PXI(e) are the way to go if you are going with a DAQ.

[Novgorod]

Yeah, I've suspected that USB might not be suitable for anything time-critical. A PCI-e 6321 card dedicated to this would be quite a waste though, but it should be possible to share one between applications (we already have one in the lab for other purposes and I did my initial tests with it), it's just a matter of organization.

Anyway, thanks again for clarifying! Now I know what are the options and have some fiddling to do ;)...

[metux]

* use recent RT kernel (additional rt-patches by tglx+friends shouldn't be necessary for your usecase) 

* give the process rt scheduling priority (cgroups is your friend) and reserve enough physical ram (to avoid swapping)

* disable any "fancy" bios misfeatures (pwr management etc) - or better use coreboot directly

* for usb: make sure your device is the only one on the (phys) hci channel.

maybe you'd better off w/ some arm board (raspi should be enough)