Showing results for 
Search instead for 
Did you mean: 

CRIO 905x / 904x Chassis CPU vs Windows I5 CPU

Hi Community,


Wonder if anyone can help?


We have a dc motor control project which we drive by pwm & daqmx under labview
This all runs fine on windows but latency is an issue since the motors are driven into stall.


We would like to move to labview rt running on a crio chassis using daqmx.
The problem is choosing which crio chassis to use.

On a windows i5 computer we use around 1% of the cpu to run the control loop at 1000Hz.


Is there a way to benchmark the vi's to see which crio chassis cpu they will run on?

We are looking at crio-905x & crio-904x chassis models which support daqmx.


Any help very much appreciated.

0 Kudos
Message 1 of 6

Hi there,


Wait a minute ... before you migrate to compactrio, a few questions:


Can you describe your "latency" issue and "stall" issue?


Since you are controlling the speed of a dc motor, I'm assuming you want to be changing the duty cycle of the PWM signal, is this correct?  And how fast do you want to update the duty cycle?  Maybe 1000Hz?


When using DAQmx, you will limited to the speed of the LabVIEW while loop (approx. 1000Hz), as the duty cycle is changed by writing to the property node.


If you want to go faster, you will be limited by the DAQmx driver itself.  So the bottleneck isn't really PC vs cRIO, because DAQmx on cRIO will have same behavior.


To update duty cycle faster than 1000Hz, you will need to use FPGA mode on the cRIO with your modules.  But this is probably too much info for now, let's determine first if you need above 1000Hz update rate.




Add motion to LabVIEW in 30min or less - TENET EMotion
Finding it hard to source NI hardware? Try NI Trading Post

0 Kudos
Message 2 of 6

Hi RIObotics,


Thanks for the reply.


Thats right we are changing the PWM signal in the loop based on measured current.

When a preset current is reached at the end of travel the PWM is set low.

So the issue is the motor drive reaches mechanical limit before the loop can react fully.

This is down to the (measured) 4 to 8 ms of latency through windows.


1000Hz rate is all thats required.

When we look at NI's specifications it just states 'application dependant'

Would love a try before you buy arrangement with NI


Rgds, Bob


0 Kudos
Message 3 of 6

Hi Bob,


You mean there's no "try before you buy" evaluation with NI?  They don't provide loaner units?  Or accept returns? 😁  Sorry, just being sarcastic ... most equipment vendors are horrible about this, not just NI.  This makes it so difficult for the customer to evaluate.


Do you already have a DAQmx device for PC?  From my experience, a DAQ device should be able to meet your requirements, but it depends on how you write the program.  You can share your LabVIEW code and we can review it.  If we find that cRIO is needed, then at least you know you've exhausted DAQmx.


Alternatively, if you eventually want to use cRIO anyway, you can find some good cRIO deals from NI Trading Post.  Even if the cRIO is overkill for this project, you can use for something else.




Add motion to LabVIEW in 30min or less - TENET EMotion
Finding it hard to source NI hardware? Try NI Trading Post


Message 4 of 6

Hi John,


Thanks for looking into this.


Its a shame theres no try before buy on this one - will have a look at NI Trading Post.

(I guess its not so easy for NI to loan a varied configuration of equipment)


So been using cDAQ Chassis / DAQmx on this project.

Going to check to see if its ok to share with my current organisation.


Will check back soon...


Rgds, Bob



0 Kudos
Message 5 of 6

Generally, the latency is lower when the peripherals are closer to the controller. Unless you are using cDAQ-913x controller, otherwise the USB or Ethernet communication with the host PC is going to introduce a lot of delays.


Instrument Bus Performance – Making Sense of Competing Bus Technologies for Instrument Control

0 Kudos
Message 6 of 6