is PXI what we need?

[stijn_]

Hi,

we are currently looking into replacing our current hardware (made in-house). In a few days we'll visit an NI Test&Measurement roadshow; I'm pretty sure the NI folks will all go like 'yeah PXI is ideal for your application' but I'd like to get some more objective information first.

These are the requirements for a basic system:

• real-time. I'll try to explain: must be able to acquire 16channels of analog data at 20kHZ/16bit, together with (ie synchronized to the uSec) 32 digital TTL inputs sampled at the same rate, every 2mSec with a maximum jitter of a couple of uSec.
  In other words, all channels of the external analog/digital signal must make it into the software exactly 1mSec later, represented as arrays of 20 samples per channel.
• a low-latency link to an external pc running windows/linux/mac os. Ideally if the external pc would be polling that link, it should be able to react to any data on it within a mSec. I'm not sure that is even possible on a non-realtime os, but right now we poll the parallel port on XP an it seems to be doing that fine without too much jitter (seems never higher than 5mSec or so)
• we must be able to write at least the signal processing in C++, with a compiler providing support for at least TR1. Ideally the entire application would be written in Visual Studio.
• line-by-line debugging of the code. Again, ideally, this would be debugging with Visual Studio

At a first glance much of this seems possible with PXI running NI's realtime os, and programmed using LabWindows. But the site is a bit vague about what can and what cannot be done using LabWindows, plus I'm not sure how the debugging works.

Please share your thoughts about this. Recommendations for other systems than PXI are also welcome..

Thanks!

[Tim_S]

we are currently looking into replacing our current hardware (made in-house). In a few days we'll visit an NI Test&Measurement roadshow; I'm pretty sure the NI folks will all go like 'yeah PXI is ideal for your application' but I'd like to get some more objective information first.

You'll want to talk with your local NI representative about your application. You'd have to get much more indepth into what you're doing to help you with a solution, which is what many of us do for our day job. As such I don't think you're going to get a lot of help from these forums.

Otherwise...

The DAQ synchronization is a hardware and driver level capability; some NI cards can do this so pay attention when you pick your hardware.

I'm not certain if LabWindows can be compiled for the RT OS. LabVIEW can be.

Tim

[Neville D]

• real-time. I'll try to explain: must be able to acquire 16channels of analog data at 20kHZ/16bit, together with (ie synchronized to the uSec) 32 digital TTL inputs sampled at the same rate, every 2mSec with a maximum jitter of a couple of uSec.
  In other words, all channels of the external analog/digital signal must make it into the software exactly 1mSec later, represented as arrays of 20 samples per channel.
• a low-latency link to an external pc running windows/linux/mac os. Ideally if the external pc would be polling that link, it should be able to react to any data on it within a mSec. I'm not sure that is even possible on a non-realtime os, but right now we poll the parallel port on XP an it seems to be doing that fine without too much jitter (seems never higher than 5mSec or so)
• we must be able to write at least the signal processing in C++, with a compiler providing support for at least TR1. Ideally the entire application would be written in Visual Studio.
• line-by-line debugging of the code. Again, ideally, this would be debugging with Visual Studio

At a first glance much of this seems possible with PXI running NI's realtime os, and programmed using LabWindows. But the site is a bit vague about what can and what cannot be done using LabWindows, plus I'm not sure how the debugging works.

Are the 16 channels all acquired simultaneously at the same rate, and starting together? I think that is totally possible. However if you want to acquire them at different rates, then you would have to break them out on different cards since each card has only one sample clock.

The PXI is equipped with an internal trigger bus as well as RTSI lines, so you should be able to route your start trigger to a separate DIO card to start the DIO operations with the AI task.

Do you have any proprietary/non-NI hardware you will be using? I am not sure how that would translate to the PXI platform.

You could also use a PC with certain specifications on the ethernet chipset and such, as a realtime platform (check out "ETS" on NI's website). The setup might take a bit of time and research, but once established, it behaves just like a PXI platform (but cheaper, and you need a RT runtime licence). It probably will not have the PXI's star-trigger bus, which might be required in your application, but you can use the RTSI bus. Again, I am not sure if LWindows RT will run on the PC, but if LV-RT can, I am assuming it is possible with LW-RT as well. You can then buy NI's PCI versions of DAQ cards and use those in the LW-RT environment on the PC. Using this setup you can easily and cheaply upgrade the PC with the latest/fastest processor, down the road. No need for a chassis for the DAQ card as well.

However, the PXI controller comes in an extended temperature option, usually stands up quite well to harsh environments, and works right away painlessly with RT.

There is a LabWINDOWS realtime module as well which I am almost certain should run on PXI. I have never used it so no idea of its debug capabilities.

http://www.ni.com/lwcvi/realtime/

Some points learned through experience:

1 When you have a choice between "low-cost" NI hardware and more expensive, go with the more expensive. You will almost certainly need some functionality (more DMA channels etc.) in the more expensive card as you go further along your development.

2 Pay careful attention to the number of modules. ALWAYS get the 8 slot PXI chassis at the very minimum (you might need the 13 slot). I have been bitten in the past with getting the 4slot or the 5slot then being stuck with $1500 hardware that can't be upgraded or easily replaced without ending up with unused hardware.

3 Get the latest/greatest/fastest PXI controller you can (from NI since you need the RT support). Getting older hardware is a recipe for lots of pain and heartache.

If you go with PXI, you always have the option of using LabVIEW RT as well, if you think of going that route. The debug tools and communication tools there are excellent.

I have just recently finished debugging a PXI RT system with Counter, DI, DO, and image acquisition using the RT Trace execution toolkit. Its great (once you understand how it works, with the very spartan documentation available).

The network streams API would be perfect for deterministic communication as well.

Good luck and keep us appraised of your progress.

Neville.

Edited March 10, 2011 by Neville D

[Neville D]

• real-time. I'll try to explain: must be able to acquire 16channels of analog data at 20kHZ/16bit, together with (ie synchronized to the uSec) 32 digital TTL inputs sampled at the same rate, every 2mSec with a maximum jitter of a couple of uSec.
  In other words, all channels of the external analog/digital signal must make it into the software exactly 1mSec later, represented as arrays of 20 samples per channel.
• a low-latency link to an external pc running windows/linux/mac os. Ideally if the external pc would be polling that link, it should be able to react to any data on it within a mSec. I'm not sure that is even possible on a non-realtime os, but right now we poll the parallel port on XP an it seems to be doing that fine without too much jitter (seems never higher than 5mSec or so)
• we must be able to write at least the signal processing in C++, with a compiler providing support for at least TR1. Ideally the entire application would be written in Visual Studio.
• line-by-line debugging of the code. Again, ideally, this would be debugging with Visual Studio

At a first glance much of this seems possible with PXI running NI's realtime os, and programmed using LabWindows. But the site is a bit vague about what can and what cannot be done using LabWindows, plus I'm not sure how the debugging works.

Are the 16 channels all acquired simultaneously at the same rate, and starting together? I think that is totally possible. However if you want to acquire them at different rates, then you would have to break them out on different cards since each card has only one sample clock.

The PXI is equipped with an internal trigger bus as well as RTSI lines, so you should be able to route your start trigger to a separate DIO card to start the DIO operations with the AI task.

You could also use a PC with certain specifications on the ethernet chipset and such, as a realtime platform. The setup might take a bit of time, but once established, it behaves just like a PXI platform (but cheaper, and you need a RT runtime licence). It probably will not have the PXI's star-trigger bus, which might be required in your application. Again, I am not sure if LWindows RT will run on the PC, but if LV-RT can, I am assuming it is possible with LW-RT as well. You can then buy NI's PCI versions of DAQ cards and use those in the LW-RT environment on the PC.

Also, the PXI controller comes in an extended temperature option and usually stands up quite well to harsh environments.

There is a LabWINDOWS realtime module as well which I am almost certain should run on PXI. I have never used it so no idea of its debug capabilities.

http://www.ni.com/lwcvi/realtime/

Some points learned through experience:

1 When you have a choice between "low-cost" NI hardware and more expensive, go with the more expensive. You will almost certainly need some functionality (more DMA channels etc.) in the more expensive card as you go further along your development.

2 Pay careful attention to the number of modules. ALWAYS get the 8 slot PXI chassis at the very minimum (you might need the 13 slot). I have been bitten in the past with getting the 4slot or the 5slot then being stuck with $1500 hardware that can't be upgraded or easily replaced without ending up with unused hardware.

3 Get the latest/greatest/fastest PXI controller you can (from NI since you need the RT support). Getting older hardware is a recipe for lots of pain and heartache.

If you go with PXI, you always have the option of using LabVIEW RT as well, if you think of going that route. The debug tools and communication tools there are excellent.

I have just recently finished debugging a PXI RT system with Counter, DI, DO, and image acquisition using the RT Trace execution toolkit. Its great (once you understand how it works, with the very spartan documentation available).

The network streams API would be perfect for deterministic communication as well.

Good luck and keep us appraised of your progress.

Neville.

Edited March 10, 2011 by Neville D

[Grampa_of_Oliva_n_Eden]

...

Good luck and keep us appraised of your progress.

Neville.

Neville covered it quite well.

Clocking options are very robust on PXI.

Disclaimer, I am a LV guy...

You may be able to run your app on one of those USB-DAQ widgets that have RT a cRIO built-in to handle odd ball low jitter requirements.

Ben

[Grampa_of_Oliva_n_Eden]

Neville covered it quite well.

Clocking options are very robust on PXI.

Disclaimer, I am a LV guy...

You may be able to run your app on one of those USB-DAQ widgets that have RT a cRIO built-in to handle odd ball low jitter requirements.

Ben

Another option for the PXI platform I failed tommentio last night is "SCRAMNet" from Curtiss-Wright implements shared memory between machines. Data transfers are blazing fast. I have adapted them for use in LV but they were originally develoed for C. If redundancy serves any purpose in your app then concider SCRAMNet. Not only are the transfers fast but with the right hardware you can configure multple redundant paths with slef healing etc.

Ben

[stijn_]

@Neville: thanks for your in-depth answer

Are the 16 channels all acquired simultaneously at the same rate, and starting together?

yes, that's it exactly.

Do you have any proprietary/non-NI hardware you will be using? I am not sure how that would translate to the PXI platform.

we have tons of proprietary hardware, but all communication with these modules is purely analog or via TTL. So we'de use the analog/digital I/O on the PXI system to communicate with our current system.

You could also use a PC with certain specifications on the ethernet chipset and such, as a realtime platform (check out "ETS" on NI's website).

that's a pretty interesting idea but it's not scalable enough for us. For example right now we have to purchase eye trackers, with PXI we could just plug in a video acquisition board and write our own eye tracker software. Things like that seem very hard without a true bus system.

If you go with PXI, you always have the option of using LabVIEW RT as well, if you think of going that route. The debug tools and communication tools there are excellent.

we're well aware of that; but translating our C++ signal processing libraries to Labview is simply put impossible: it would be a massive job, and they're used not only for our RT device but also for offline processing etc. One option would be to put the processing in dlls and call those from Labview RT but I'm not sure that works (it does in 'normal' Labview).

Anyway, we'll certainly do some more research. A decision will be taken approx. next month so it will take a while before I can give you guys an update but I definitely will.

[Neville D]

that's a pretty interesting idea but it's not scalable enough for us. For example right now we have to purchase eye trackers, with PXI we could just plug in a video acquisition board and write our own eye tracker software. Things like that seem very hard without a true bus system.

You could get an eye tracker with a PCI slot, mounting it in the ETS (realtime) PC.. really its exactly the same as PXI, but minus the Star trigger bus. But PXI is a more robust (though expensive, when you factor in chassis+controller) solution.

Requirements for using a desktop PC as a LabVIEW Real time target

One option would be to put the processing in dlls and call those from Labview RT but I'm not sure that works (it does in 'normal' Labview).

Yes, that will work with LV-RT as well. We have written C dll's and called them in RT before.

As an aside, I notice that there is an " Real time Execution Trace Toolkit" for LabWindows as well (in the latest LW 2010 SP1 Release Notes).

Have fun!

N.

Edited March 11, 2011 by Neville D

[stijn_]

update:

after spending some time with an NI rep, we're really convinced that the PXI hardware in combination with a RealTime OS would be extremely well-suited for use. The hardware is really nice.

Major problem: the software is not. Seems RT is only possible using NI's proprietary software. Our current codebase is the result of about 5 years of work by two people, in rather advanced C++. Converting everything into C or Labview to make it run on PXI is just impossible given the time we have (and are willing) to spend on the rather boring conversion job. I was hoping it would be possible to run Windows CE on a PXI controller but apparently that's not an option.

We're looking into alternatives now, seems there are some:

- InTime. If this really does everything as advertised, we won't look any further. I mean, it sounds too good to be true: put a PCI A/D convertor in your pc, program as you always do using VisualStudio, and the thing runs it in real-time..

- An SBC/embedded PC running Windows CE. A lot (if not too much) of choice in this department, and it seems to be widely covered by the industry as well.

[Tim_S]

Major problem: the software is not. Seems RT is only possible using NI's proprietary software. Our current codebase is the result of about 5 years of work by two people, in rather advanced C++. Converting everything into C or Labview to make it run on PXI is just impossible given the time we have (and are willing) to spend on the rather boring conversion job. I was hoping it would be possible to run Windows CE on a PXI controller but apparently that's not an option.

Can you convert the existing code to a DLL? There is a KnowledgeBase article here that discusses it.

Can you split the system into real-time and not real-time "post processing"? It sounds as if you can since you are considering a SBC/embedded PC option.

Tim

[COsiecki]

What about their Real-Time Hypervisor for Windows?

http://sine.ni.com/n...g/en/nid/207302

You could do your acquisition on the RT side of the system, then shoot the data to Windows for processing with your existing signal processing. It might be something to look at.

[stijn_]

we could indeed move some part of the procssing into the non-realtime side, but the heaviest part must remain in real-time, and we want to move some of the non-realtime into the real-time side. That last one is the main poblem: we really want it to be real-time in our future system, since it's causing problems now, but it's pretty compicated and in C++ so porting it would cause seruous headaches ;P Should we move it into a dll, we would probably use debugging functionality. Apart from that, we are so used to Visual Studio that switching to another IDE would be another dealbreaker..

[Tim_S]

we could indeed move some part of the procssing into the non-realtime side, but the heaviest part must remain in real-time, and we want to move some of the non-realtime into the real-time side. That last one is the main poblem: we really want it to be real-time in our future system, since it's causing problems now, but it's pretty compicated and in C++ so porting it would cause seruous headaches ;P Should we move it into a dll, we would probably use debugging functionality. Apart from that, we are so used to Visual Studio that switching to another IDE would be another dealbreaker..

It sounds as if you like the NI hardware, but can't invest in learning the software. The RT OS on the PXI systems is Phar Lap ETS (Phar Lap is now owned by IntervalZero). The website for ETS is located here.

[Rolf Kalbermatter]

we could indeed move some part of the procssing into the non-realtime side, but the heaviest part must remain in real-time, and we want to move some of the non-realtime into the real-time side. That last one is the main poblem: we really want it to be real-time in our future system, since it's causing problems now, but it's pretty compicated and in C++ so porting it would cause seruous headaches ;P Should we move it into a dll, we would probably use debugging functionality. Apart from that, we are so used to Visual Studio that switching to another IDE would be another dealbreaker..

The NI realtime OS on non embedded systems (cRIO, cFP) is Pharlap ETS as already mentioned. This is a Win32 API compatible system with the same PE executable file format. The catch is that it does not support recent Win32 API additions after WinXP and also does not implement the entire Win32 API (partly because it's not useful or possible on an RT system) partly because the Windows functionality is not documented. Also the runtime library support installed on the system is about Visual Studio 7.1 with an option to install VS 8.0 runtime support if I remember correctly. This usually means that using newer Visual Studio versions will pull in runtime library stubs and functions that are not available on the Pharlap ETS system.

So if you have already compiled everything into DLLs, AND have that running from normal LabVIEW for Windows, AND you can compile your DLL in Visual Studio 7.1 then you are mostly done. You'll only have to check for compatibility with the DLL checker and possibly modify code to use older Win32 APIs where necessary and you are ready to debug your system in your realtime environment. The same DLL that works on your Windows system will then work on the realtime system too.

And Windows CE isn't a realtime system at all, and you'll have a lot of problems to get NI DAQ hardware working in that.

[stijn_]

The NI realtime OS on non embedded systems (cRIO, cFP) is Pharlap ETS as already mentioned.

interesting, I didn't know that. One of the systems we're going to evaluate is IntervalZero's NTX btw.

And Windows CE isn't a realtime system at all

can you elaborate?

[Rolf Kalbermatter]

interesting, I didn't know that. One of the systems we're going to evaluate is IntervalZero's NTX btw.

Don't know about NTX but just because it is similar or maybe even based on Pharlap ETS it is not very likely' that the LabVIEW RT will be able to work on that.

can you elaborate?

Windows CE is a small footprint variant of an OS with an API similar to Windows 32Bit. As such it is meant for resource challenged systems such as embedded controller, Pocket PC devices, and Mobile Phone devices (the latest not anymore as Windows Phone 7 is supposedly a rather different system). Windows CE targets typically RISC CPUs though it may be available nowadays for x86. But it has no provisions to support true realtime operation so you can't call it a realtime system. It's strength is that it can run on embedded hardware, and on source code level its fairly compatible with Windows 32 bit, but its target architecture was completely different so you couldn't move (and even if they might have x86 support nowadays which I don't know) binary modules from Windows to Windows CE, since the file format and CPU target were different.

[ShaunR]

But it has no provisions to support true realtime operation so you can't call it a realtime system.

Hmmm.

Not sure I necessarily agree with this. M$ has been touting CE as "hard real-time performance" since version 3.0 and the term "real-time" on it's own tends to mean many different things to different people. But here's a report into it's real-time capabilities and a rather excellent web-cast on its real-time features so you can decide by your criteria.

When it boils down to it. There really aren't that many "real-time" applications that are required of an OS in Labview development. The trend is to offload real-time onto dedicated hardware and NI have many fantastic PCI or PCIE solutions for this. Thats why we have seen the proliferation of FPGA. This means tat Embedded Windows is an excellent platform for real-time (or near real-time) applications.

I've actually been using Windows XP Embedded Standard for a couple of years now (not exactly the same as CE). Far cheaper than NI platform products and you can use NIs cards as well as other manufacturers and is therefore far more versatile. Once you get the right initial "image" - Labview runs on it too. We have gone down the route of having small embedded machines for specific task (e.g one for image acquisition, one for motion control, one for acquisition etc) and as replacements (or alternatives) for cRIO. So far, we have not found one instance where it hasn't been as capable. But many instances here it is far more versatile and at a fraction of the cost.

Looking forward to evaluating Embedded 7. But XP has worked so well (with Labview) that it'll probably only happen when we really have to.,

Edited May 6, 2011 by ShaunR

[stijn_]

update: we decided to go with InTime as OS, and use a variety of NI hardware depending on specific conditions. Some setups will use a simple PCIe card, for others we'll go with MXI - PXI and a couple of cards. The cards will be addressed by use of the new X-series DDK which seems to work very well (our prototype has a PXI rack with two cards synced).