PXIe control system: counter for encoders slows down performance

[mgegel]

I'm working on a control system using the PXI platform. Here's the overview:

I have a PXIe chassis. I have digital IO, analog IO, and counters on multiple boards. The system samples all inputs at the same clock tick, does computations, and then outputs them all at the next clock tick. This needs to happen repeatedly without any latency.

The current problem is performance. I can run at 30 kHz with AIO and DIO. But when I include the counter tasks, my program can only handle 8 kHz. I need this program to run faster with the counter tasks.

Why do the counter tasks slow down the software so much?

What can be done to improve performance?

Thanks.

[G-IV]

Hi mgegel,

If it was me, I would try to narrow down how much code I have to make the troubleshooting easier, or I would enable one counter at a time to see if there is a particular counter creating the problem.

--G-IV

[Roohcifer]

Hi mgegel,

To be completely honest, 30 kHz is a fairly ambitious loop rate.  Even if it is running now with the single point acquisitions and generations, any inline processing in your timed loop could have a serious impact on meeting timing.  It would be worth benchmarking just your algorithm with dummy/constant inputs and outputs on its own in a free-running while loop to see if it can be processed at 30 kHz.  If it can't, there is no need to continue down the troubleshooting path of optimizing the DAQmx code, as your algorithm will not be achievable.  Your control loop speeds may only be achievable on FPGA.

If you find that your algorithm can be processed in a trivial amount of time, then as mentioned in the previous post, try paring down the DAQ code to the minimum reproducing set.  See if you can get it to have the same behavior with, for example, just the CO task generating the pulse train and a single CI task.  If this works, then add another CI task and so on until you find the culprit.  That should simplify troubleshooting.

Also, to make your code more manageable, you should consider using subVIs to abstract away repeated code or code that doesn't need to be seen to understand the operation of the VI so that you're only exposing critical things that need to be seen on the block diagram.  This will help not only your development by increasing reusable code, but it will also reduce clutter and help both yourself and others troubleshoot your code down the line.  The initial time investment in doing so will be well worth the ease of debugging later on.

Regards,