-209801 Error at high speed

[thumble]

Hello,

I'm currentyl mocking up a close loop system and I meet some performance issues. The detail is in the attachement.

Best regards

[Call_Me_Vinny · Accepted solution]

thumble,

1. 4 kHz is pretty fast for a VeriStand system.  Not saying it can't be done, but just wanted you to know.  We usually run ours at 1 or 2 kHz.  If you look at your screenshot that includes the HP Loop count, you can see that your system is falling way behind.  The HP count is the number of times that your main loop has finished late.
2. Filtering DAQ errors will just ignore errors coming from your DAQ tasks (the error that you are seeing is from your AO task).
3. The DAQ error basically states that you are not keeping up with the card.  Since you are telling the card that you plan to go at 4 kHz, it's expecting a new sample from VeriStand at that rate.  However, your VeriStand loops are currently not running that fast, so when they fall behind the DAQ card throws this error because it has no data to write out. 

[thumble]

Hi Chris,

Thanks for your reply, I will retain that it's not wise to go beyond the rate of 2KHz, but I still wonder why, because the metrics (loop durations and CPU loads) are almost low.

Best regards

[Eric.M]

Hi Laurent 🙂

This was puzzling me so I decided to run the test because without so many I/O and with just the Engine Demo we should reasonably be able to run above 10kHz.

Results : I was able to meet the 4kHz quite easily with no HP Count, around 50us of HP Loop Duration (25us with NIVS 2013SP1).

Only possible pitfalls that I can think of are the MXI (I was using a "small" 8102 controller) or the DAQ board (I was using a 6368 but's it's mostly the same device).

Can you check if changing the RT controller or DAQ board has an impact ? Beware with the DAQ board if you using a simultaneous or mux'ed board 🙂

If you're still struggling can you post your definition file ?

Also, were you using the built-in DAQ features right (not a custom device) ?

[thumble]

Hi Eric,

I haven't time right now for further investigations, but as I suspect some DAQ overhead, unless it has been improved in VS2013 or VS2014, I plan to use a FPGA R series board for the I/O's, expecting the performance will be better through FPGA personalisation.

++

[Call_Me_Vinny]

thumble,

I would caution you not to necessarily expect higher performance with an FPGA card.  The issue you were seeing was a function of your VeriStand system not being able to keep up with your DAQ card, not the other way around.  I doubt that the VeriStand side overhead for handling FPGA devices is much different.

[StephenB]

Actually FPGA devices are slower at single point data exchange than DAQ devices. In fact, the 6358 is one of the fastest IO cards you can possibly use with NIVS. In our benchmarks with 2013 SP1 we hit 40kHz with it and an 8135 controller. Perhaps your RMC controller + MXI is causing your problem? Try using an 8135 instead. Also make sure 'legacy USB' is off in BIOS and Ethernet is changed to polling in MAX.

[thumble]

Hi all,

Thanks a lot for your advises

Best regards

[thumble]

Hi all,

To close this, you're certainly right about the MXI bottleneck because I’m able to run the mock-up (16 diff. AI + 4 AO + 4 Engine Demo) at 10 KHz using an embedded controller PXIe-8133 and an I/O board PXIe-6259 with only few “HP count” and even none at 8 KHz.

Best regards

[StephenB]

Awesome. Thanks for following up. I was curious.

For that specific setup here are a few more tips:

• The 8133, since it uses an older Intel processor, has a significantly higher processor frequency when in 2 core mode than when in 4 core mode. Therefore, with the 8133 (and the 9082), if you disable half the cores in BIOS... you will get higher loop rates. The 8135 and newer controllers use newer intel processors that have about the same frequency in 2 core and 4 core mode, so just leave them all enabled.
• The 6259 is a multiplexed card therefore it is much slower than a 6358. You can calculate the portion of the HP loop that the multiplexing will consume as a percent of loop time (and therefore approximate CPU utilization) with the attached VI, after simulating a PXI-6259 in MAX. In NI VeriStand, you can change the convert clock (multiplex rate) to maximum to dramatically increase the performance of this card. See the picture below: