Login    Register
User Information
Username:
Password:
We are a free and open
community, all are welcome.
Click here to Register
Sponsored
Who is online

In total there are 83 users online :: 5 registered, 0 hidden and 78 guests


Most users ever online was 155 on Mon Aug 15, 2016 1:40 am

Registered users: Bing [Bot], Doodmens, Google [Bot], Google Adsense [Bot], Yahoo [Bot] based on users active over the past 5 minutes

The Team
Administrators
Global Moderators
global_moderators.png CS

Servos with LabVIEW

All non-spudgun related discussion goes here such as projects, theories, serious questions, etc. All "off-topic" posts (aka useless posting, determined by moderators) will be removed.
Sponsored 
  • Author
    Message

Servos with LabVIEW

Unread postAuthor: PVC Arsenal 17 » Thu Mar 24, 2011 2:25 pm

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.
  • 0

Attachments
servo.png
The block called "PIC Serial Com" is the sub VI provided by my professors. Essentially you send strings of data to the "string to write" port.

In my VI, I have a sequential case structure that is executed from left to right. The structure is enclosed in a while loop so it runs indefinitely. In the first frame is the 20ms period during which the servo receives a LOW pulse. In the second frame, the servo receives a HIGH pulse for a duration of 0.6 to 2.4ms which is determined by a slider on the front panel. Changing this value *should* change the position of the servos.

Of course, it does not work as desired.
servo.png (36.86 KiB) Viewed 1598 times

PVC Arsenal 17
Major General
Major General
 
Posts: 1762
Joined: Mon Mar 27, 2006 4:18 pm
Location: United States
Reputation: 1

Unread postAuthor: Technician1002 » Thu Mar 24, 2011 3:06 pm

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.
  • 0

User avatar
Technician1002
Chief of Staff
Chief of Staff
 
Posts: 5190
Joined: Sat Apr 04, 2009 11:10 am
Reputation: 14

Unread postAuthor: POLAND_SPUD » Thu Mar 24, 2011 3:14 pm

EDIT
damn I was wrong :oops:

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
  • 0

Last edited by POLAND_SPUD on Thu Mar 24, 2011 8:51 pm, edited 3 times in total.
Children are the future

unless we stop them now
User avatar
POLAND_SPUD
Chief of Staff
Chief of Staff
 
Posts: 5405
Joined: Sat Oct 13, 2007 4:43 pm
Country: Israel (il)
Reputation: 10

Unread postAuthor: Technician1002 » Thu Mar 24, 2011 3:34 pm

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.
Image
  • 0

User avatar
Technician1002
Chief of Staff
Chief of Staff
 
Posts: 5190
Joined: Sat Apr 04, 2009 11:10 am
Reputation: 14

Unread postAuthor: jimmy101 » Thu Mar 24, 2011 3:58 pm

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.
  • 0

Attachments
circ2.gif
circ2.gif (4.92 KiB) Viewed 1557 times
Image

jimmy101
Lieutenant General
Lieutenant General
 
Posts: 3127
Joined: Wed Mar 28, 2007 9:48 am
Location: Greenwood, Indiana
Country: United States (us)
Reputation: 7

Unread postAuthor: PVC Arsenal 17 » Fri Mar 25, 2011 7:23 pm

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.
  • 0


PVC Arsenal 17
Major General
Major General
 
Posts: 1762
Joined: Mon Mar 27, 2006 4:18 pm
Location: United States
Reputation: 1

Unread postAuthor: Technician1002 » Fri Mar 25, 2011 8:10 pm

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.
  • 0

User avatar
Technician1002
Chief of Staff
Chief of Staff
 
Posts: 5190
Joined: Sat Apr 04, 2009 11:10 am
Reputation: 14

Sponsored

Sponsor
 


Unread postAuthor: PVC Arsenal 17 » Sat Mar 26, 2011 4:01 pm

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.
  • 0


PVC Arsenal 17
Major General
Major General
 
Posts: 1762
Joined: Mon Mar 27, 2006 4:18 pm
Location: United States
Reputation: 1

Unread postAuthor: Technician1002 » Sat Mar 26, 2011 5:35 pm

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.
  • 0

User avatar
Technician1002
Chief of Staff
Chief of Staff
 
Posts: 5190
Joined: Sat Apr 04, 2009 11:10 am
Reputation: 14

Return to Non-Spudgun Related Discussion

Who is online

Registered users: Bing [Bot], Doodmens, Google [Bot], Google Adsense [Bot], Yahoo [Bot]

Reputation System ©'