Pluto Servo - Motors won't servo correctly????

[TZak]

Still trying to tame this machine.

I have yet to figure out how to get the pluto-p board to work with the newer version of emc.2.2.2??? So I have resorted to using my old setup for testing.

I have managed to get all my servo amps and all the power issues working on this three axis setup, however my problem is I can't get the motors to servo properly.

I manage to get a servo however when I turn the motor by hand it starts to oscillate. I have tried playing around with the PID but none of my numbers seem to work.

A friend was telling me that the pluto-servo response feed-back my be too much for the amps that I am using. I would like to find this out ( and change is necessary) however I don't know how to test it? Any suggestions would be great.


Hopefully someone out the has some advice on how to tame these motors.

Thanks in advance

[samco]

I have not had a chance to look at your hal file.. But here is something to think about.

someone on the emc-users list had a similar problem.. (I think)

Hi folks, I'm trying to build my first EMC-controlled servo, and I've got some questions. I'm building it out of a small brushed DC motor (a Pittman 8322 with shaft encoder [0]) and a home-made copy of Jeff Epler's L298-based servo driver [1]. I'm controlling it with EMC 2.1.6, feeding it PDM & direction signals over a parallel port. My first question is, does this seem like a reasonable motor to make a servo mechanism from? Given the limitations of its torque output, of course. The motor specs: reference voltage: 19.1 V DC no-load current: 0.16 A Peak/Stall Current: 2.51 A Continuous Torque: 1.6 oz*in Stall Torque: 7.4 oz*in no-load speed: 7847 rpm encoder: 256 lines per revolution The first step was to read the encoder, that was easy and works fine. The encoder produces 1024 edges per revolution. I'm sampling the A and B lines at 40 KHz, so by my calculations I should be able to reliably keep track of position up to about 1100 or 1200 rpm. The next step was to spin the motor, and that's where I'm running into issues. At 0% duty cycle the motor is stopped, and at 100% it runs fast, so that's good. However, the mapping from duty-cycle to rpm is confusing. Duty cycles from 0 to about 55% give me increasing whining from the motor but no movement at all. 55 to 100% gives increasing motor speed and torque. I'm using a driver circuit basically identical to the one published by Jeff Epler (thanks Jeff!). The only power supply I have access to right now is an ATX one scrounged from some dead computer, so I'm driving the motor at only 12 V; it's rated for 19.1 V so that's probably part of my problem. Just like in Jeff's example, I run a PDM pulse train into the H-bridge enable pin, and direction and not-direction signals into the two H-bridge inputs. The resolution of my pulse generation is 100 us, so the pulse train has transitions at no more than 10 KHz, well below the 25 KHz nominal commutation frequency of the L298 H-bridge. So my main question is: What, if anything, can/should I do about the dead band from 0 to 55% duty cycle? Live with it and tune it out in the PID loop? I built this big goofy HAL "circuit" that adds 0.56 to duty cycles above 0.01, it worked but feels kind of kloodgy. What causes this motor behavior? I guess at those low duty cycles (especially given the low input voltage) the energy being fed to the motor is not enough to overcome inertia or static friction or something. I tried increasing the pulse-generating period, up around 1 KHz the motor became more responsive but also more "clicky" and it ran kind of rough. I think 10 KHz is about as slow as I want to go. If I can get this servo moving reliably I'll build two more, and put them on a McWire Mill [2]. 0: http://pittmannet.com/series8000motors.html 1: http://emergent.unpythonic.net/projects/01142347802 2: http://www.instructables.com/id/Easy...hine/?ALLSTEPS

Petew (of mesa fame http://www.mesanet.com/) came back with this answer.. (probably why I never saw this behavior either as my h-bridge turns on the bottom 2 fets durring the 'off' cycle.

This is the expected behavior of an simple HBridge operating in 'Fast-Decay-Mode' that is the switch elements are turned off in the off part of the PWM cycle. What is happening is this: In the ON time portion of the cycle the current through the motor increases at a rate of Vsupply/Lmotor. In the off time the current decreases at the same rate. At duty cycles up to ~50% the current has dropped back down to 0 before the next ON part of the cycle begins. This means that the average current in the motor is quite low (and current ripple quite high). If you look at motor current on an oscilliscope you will see that at 50% duty cycle, the current will look like a triangle wave with the peak current being Vsupply*Ton/Lmotor and a minimum of 0. If your PWM frequency is high enough, the average current in this region will be quite small (So your motor will not move) Once you get to PWM duty cycles greater than 50%, the current triangular wave never decays to 0 in the off portion of the PWM cycle, so the average current increases quickly with greater duty cycle. To solve your problem there are a couple of things to try: 1. Live with it and offset you PDM 2. Use PWM instead of PDM (If the software PWM rate is not too low). The ripple will be higher, but the average current in the 0 to 50% duty cycle range will be will be higher as well. 3. Setup your HBridges to use 'Slow decay mode' if possible. This usually means that the bottom 2 switch elements are turned on in the off part of the PWM cycle, (shorting out the motor) causing the stored energy on the motor inductance to be 'saved' between PWM cycles. This results in lower ripple, and more linear current versus duty cycle. 4. Use an HBridge with current feedback

[TZak]

Samco


Thanks for the psoting.

Just another quick question. Is there a way to set /change the pwm rate on the pluto -servo.

I am trying to change this speed. Let me know if you know which setting in the hal or ini files to change.

Thanks