LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx, Timing, servo control

Hi, I'm trying to set up a system to control a servomotor while simultaneously measuring its current draw and rotational position, using LabVIEW 2013.  To control the servo, I'm using VISA to output commands to a Parallax Servo Controller.  To acquire the analog voltage signals (from a Hall-effect current sensor and from the potentiometer within the servomotor), I'm using a NI USB-6259 DAQ.  Attached is the LabVIEW code I'm using to do this.

 

The problem that I'm having has to do with timing:  I'd like to both send commands to the servo controller and sample the analog voltages at 100 Hz (every 10ms).  It seems that my system is doing this, but there is some kind of delay between sending position signals and acquiring voltages, and I don't believe it's hardware related.  Here is the output on a waveform chart of the command vs. the actual position, showing the delay:

 

delay.png I'm not sure if I have all the DAQmx stuff set up correctly.  Another thing I noticed is that if I put a delay in one of the outer while loops (going through successive tests), the DAQ seems to still be reading and logging the signals even while it's not in the Timed Loop.  If I put a Stop Task after the Timed Loop, this problem goes away, but putting a Start Task before the Timed Loop doesn't seem to help at all.  

 

Please take a look at the block diagram and let me know if you see any problems with the way I have this set up.  It's basically working, but I am just worried that the timing isn't really synchronized the way it's supposed to be.  I am guessing someone will suggest using a producer/consumer loop scheme, but will that actually fix my issues?  If so, is there example code for producer/consumer that someone can suggest?  Thanks.

 

 

 

0 Kudos
Message 1 of 7
(3,153 Views)

You might be able to do the producer consumer architecture like you suggested, but I'm not sure that would solve the timing issue either. Upon looking at your code, I think there might be some pieces missing. The easiest way to fix this would be to look at examples within LabVIEW. If you go to Help -> Find Examples... within LabVIEW and then you can navigate to some of the examples that may help you. I would like to mention that the Analog Input, Analog Output and Synchronization examples should be of particular use to you. 

 

ScreenShot.png

Rob S
Applications Engineer
National Instruments
0 Kudos
Message 2 of 7
(3,104 Views)

Rob, thanks for the input.  I looked at the examples you referenced and I don't really see what it is I'm missing -- you mentioned you thought I had pieces missing, what pieces?  I'm not doing TDMS logging, I'm not doing triggering, and it doesn't seem to make any difference if I use Start Task and Stop Task VIs.  

 

As far as the synchronization VI, I'm not familiar with the idea of master and slave channels, but also don't really see how that applies to me.  I'm not having issues synchronizing two DAQmx channels, I'm having issues synchronizing a DAQmx channel with a VISA Write task.  

 

delay2.png

In looking at some of the saved data, I noticed that there is this delay at the beginning where the analog signal starts getting recorded for apparently about 5 loops [50ms] before the servo starts moving.  I don't know why this would be, and again can't imagine hardware as the issue, because the Parallax Servo Controller should take at most 4ms to write the command (so I could understand a 1 loop [10ms] delay, but not for 5 loops). 

 

Sorry I can't be more specific about my problem, but I have just noticed this issue and didn't know where it could be coming from.

0 Kudos
Message 3 of 7
(3,072 Views)

Even though it may not seem like the start and stop tasks are necessary, they are. Those are the pieces you were missing that I was referring to. Another thing that may help speed up performance is to make sure the appropriate DAQ tasks are set to "Committed". I'll include a link to help you out. This should help improve the speed somewhat.

 

http://zone.ni.com/reference/en-XX/help/370466V-01/mxcncpts/taskstatemodel/

Rob S
Applications Engineer
National Instruments
0 Kudos
Message 4 of 7
(3,044 Views)

It could be the servo controller- note that the actual versus command tends to initially lag then lead commanded position on the rising and falling edges of the sine wave. This could occur in an mis-tuned system.

 

Are there servo tuning parameters you can adjust such as PID, acceleration, deceleration, feed-forward, etc?

Is there a load connected to the servo?

 

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
0 Kudos
Message 5 of 7
(3,039 Views)

Rob, the documentation on Start Task says:  

"Using this VI is required for some applications and is optional for others. If you do not use this VI, a measurement task starts automatically when the DAQmx Read VI runs."

 

I have tried including the Start and Stop VIs and excluding them, it seems to make no noticable difference to the problem at hand (or any other observable effect).  Also I tried explicitly forcing the Committed state as you recommend, but that did not seem to make any difference either.

 

I think the problem is not actually with the DAQ reading, rather the VISA writing.  If anything, the DAQ is ahead of where I want it to be (which is synchronized with the servo commands), not behind.

 

0 Kudos
Message 6 of 7
(3,025 Views)

AK2DM,  yes there are basically two layers of controllers beyond LabVIEW, one of which I can influence and one I cannot.  

 

The Parallax Servo Controller board should basically just be taking the 8 byte commands I give it and converting those to pulse width modulated (PWM) position signals for the servo.  There's not a lot of mystery there and I believe that's all functioning properly.  In the command I can send a ramp rate (basically like a speed) and it is at maximum speed currently.  There's a little tweaking that can be done with this board, but not much and I don't see why it would be necessary.

 

The other reality is that the servo itself has a controller inside it (PID I assume) which takes a reading from its internal potentiometer (which I've hacked into and am reading with the DAQ) and tries to match that to the PWM signal it's receiving.  I really have no influence on this whole control system or the tuning parameters for it.  Maybe someonen does (employees at Hi-Tec?), but again I don't think this is necessary.  I believe the servo is faithfully following commands, there just seems to be an initial delay between the first instruction and when it starts, but after that everything is good.  

 

It also doesn't matter how slowly I move it (changing the oscillation frequency of the command signal), it still has this delay.  There is no load at all on the servo.

0 Kudos
Message 7 of 7
(3,020 Views)