Servos with LabVIEW

[PVC Arsenal 17]

Another school project I've been assigned requires me to control a DC motor using a PIC board and LabVIEW. My professors have provided us with a sub VI to handle communication between the PIC and LabVIEW. I've mastered DC motors but now I'm interested in controlling an HS-55 servo being that it is much better suited for this project than a plain old DC motor.

Previously I've taken advantage of the servo library functions included with other microcontroller-based prototyping platforms (which of course use text based programming). In LabView, though, this task is much more difficult and not many examples are on the web to study.

The particular servos I have take pulses ranging from 0.6ms to 2.4ms at the standard 50Hz. Regardless of what I try in LabVIEW, the servo just moves clockwise in small increments at about 2Hz until it reaches its limit, then attempts to continue turning. This happens regardless of the pulse duration.

Here is a video of what is going on: http://s237.photobucket.com/albums/ff15 ... 011129.mp4


It's likely I've written the VI incorrectly, and that I'm misunderstanding the operation of an analog servo. Is it correct that a servo should receive HIGH pulses for the appropriate duration, followed by fixed length LOW pulse of 20ms (corresponding with 50Hz), then the next HIGH pulse?


All advice is appreciated.

[Technician1002]

There is the strong possibility that the UART for the serial port can't support a pulse string. You may wish to try pulsing a uP data port instead.

The servo may respond like that with a low data rate pulse string. The bits sent by a serial port with the start, data, parity, and stop bits may cause the servo to jitter toward one end of travel until it reaches a stop.

Do you know anyone with access to an oscilloscope?

Without access to test equipment, if you buffer the signal and feed it to a small speaker, the proper servo signal will make a constant monotone buzz with a higher order tone that will change as the servo position is changed.

The sound is somewhat like the sound of an artificial larynx where the drone of the buzz is fixed pitch, but the tonal quality changes as the user mouthes the words.

If your output does not have that monotone buzz quality to it, that is a sure sign the pulse string is incorrect.

[POLAND_SPUD]

EDIT
damn I was wrong

the servo just moves clockwise in small increments at about 2Hz until it reaches its limit, then attempts to continue turning. This happens regardless of the pulse duration

If I were you I'd check the code... you get some result but it is not what you expect...
you might have used integers where you should use bytes, or something like that

[Technician1002]

I am wondering if you have the time of the loops correct. A long servo pulse tends to move it clockwise. The direction of your servo indicates the pulse may be long and the rep rate may by 2,000mS instead of 20 mS.

The 20 ms rep rate can vary quite a bit without much affect on the servo. The pulse duration is the servo position information. Some RC transmitters with only 2 channels may have a shorter time for faster response in cars and such. Transmitters with more than 8 channels may reduce the data rate so there is a minimum reset after the transmission of the last servo pulse.

12 channels sent serially from a transmitter at max 1.5 ms each is 18ms for the string. 2ms may be too short to sync the receiver. The idle time after the last pulse has a minimum requirement by the receiver to remain in sync. The long dead time is used to reset the channel counter in the receiver.

Again I recommend using a speaker for testing. If you get a metronome tick, tick, tick, at a 2 second rate, that may be all that is wrong.

Don't forget to check if your port is active low instead of active high. A voltmeter can be used to check this. Correct is less than 1 volt DC. Incorrect is above 4 volts.

Your posted time waveform for driving a servo is correct. A 1mS pulse should drive it near center.

I'm still wondering if you are trying to send this to a UART? The attached graphic indicates a RS232 connection. You can't drive a servo off a RS232 data line with the exception of the DTR pin, which can be manipulated in some hardware.

[jimmy101]

Feed your control signal back into your PC's sound card via the MIC input. AKA, the poor-man's O-scope. Perfectly good up to 20KHz (50uS) or so.

You can probably just take your control line and put it through a resistor divider to ground. Hook the tap of the divider up to you MIC input. Might need a capacitor to keep the MIC input's DC supply voltage out'a the way.

Use Audacity, or if you PC is old google for Winscope, as the data logger.

[PVC Arsenal 17]

Thanks for the replies. I've more or less come to the conclusion that the subVI my professors have provided holds things up too much. That, and I don't know if USB2.0 can even support the data transfer. I can post the diagram of the subVI if anyone thinks they may be able to make sense of it (I certainly can't).

If my professor approves, I'll make a 555 timer circuit or program a separate microcontroller to drive the servo upon receiving a signal from the PIC Board... That shouldn't break any rules.

I was given another alternative today in the form car door lock actuator that will take on the job of the servo very nicely. Video

And I'll certainly keep the microphone "o-scope" in mind for future problems.

[Technician1002]

If using 555 timers, either use 2, one triggering the other, or use a 556 duel timer. One can be set to the 50 hz free run and the other a triggered one shot to generate your 0.5 to 1.5 ms pulse.

[PVC Arsenal 17]

Thanks for the tip. That sounds more logical than the schematics I've seen which use just one. Also, my professors confirmed that sending servo pulses the way I planned won't be possible here. They also approved of my actuator so I will certainly be using that in the project. A small payload must be released from a robot car. This actuator will provide the easiest way to do so.

[Technician1002]

By using a resistor from a data pin on the uP to the threshold pin on the 555 or 556, the trigger value can be modified so the pulse width can be controlled for a 2 position actuator. Hold or release would be simple.