LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Fastest Closed Loop PID Control with USB DAQ-6003

Solved!
Go to solution

Hello all,

 

I swear I have read forum posts with questions similar to mine, but I cannot locate them anymore.

 

My system is as follows:

 

>> 2 Kollmorgen BLDC motors with their respective servo drives

>> A NI USB-6003 DAQ to collect analog shaft position data and write analog torque commands back to the servo drives

>> LabVIEW to process the shaft positions of each motor and send the proper control signal to the USB-6003

 

Right now, if I set my DAQmx blocks to collect at above 50Hz, the control loop period becomes relatively inconsistent.

 

I am trying to nail down the bottleneck in my system and I have a hunch from the forum posts [I can no longer locate] that the USB DAQ itself may have some limitations. I'm a PhD student so I have to get rather specific about what the exact issue is...

 

However, it may very well be that I programmed my DAQmx tasks sub optimally as well. 

 

I have attached my project. I have 2 subVIs for configuring Analog Input and Output. Saved in LV2015 so hopefully more people can open it. I am using LV2020.

 

Any first hand experience or documentation people have that addresses some of these issues would be greatly appreciated. I have already read the User Manual for the USB-6003 and read as much as I could locate about the DAQmx blocks. I can't find a document that discusses using them in reference to closed-loop motion control.

 

Best,

Tom

0 Kudos
Message 1 of 3
(362 Views)
Solution
Accepted by topic author tsr26

Looking at your SubVI_configAnalogInput.vi, I don't know why you aren't getting an error.  You are creating two tasks using the same DAQ (Dev1), and even repeating channels (ai0 and ai1).  But even assuming 2 different DAQs, running two tasks over USB can be problematic.  I would invest in something like a USB-6212 (I have been using these) and put all of your AI channels into a single task.

 

As far as your analog output, you should not make is a Continuous task.  It can be an on demand task since you just write to it as some general rate.

 

Now if I was doing this, I would be using a cRIO due to the RT being able to more guarantee a desired rate.  But I am a fan of putting control loops inside of the FPGA, which really sets the loop rate.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 3
(327 Views)

I tried disabling the 2nd task which did seem to make the loop latency more consistent.

 

However, after several attempts to optimize the program for speed and running the VI profiler, I could not get the loop to run any faster than 1kHz and it was very jittery at that speed. Oddly it was most jittery at 500Hz...

 

I am lucky enough to have been able to borrow a cRIO. I do not have the FPGA module (and can't buy it), but I do have the RT module and am switching over to that target this week.

 

Thanks for the help.

0 Kudos
Message 3 of 3
(244 Views)