Modification a larger H-Bridge about dcservo HOT 20 CLOSED

Hi Pierre,

I think you've got it right.

But for high power motors the "OFF" cycle of PWM might need a bit more attention. The way you want the motor coil energy to decay may use the current approach or you might use the Enable pins for PWM instead. As it is the motor will brake during the off periods of PWM signal while with the latter approach the motor will coast. I guess the former approach puts more stress into the motor brushes but I have no idea how that might affect the brushes lifetime.

Anyway, using the enable pins as you do, you might want to add a motor enable/disable command for being able to disable the motor without disconnecting the controller for testing or maintenance purposes.

from dcservo.

I have many high power motors of the type I'm using. Frankly more than I know what to do with, and the cost of brushes is miniscule for these 4pole 24v motors. Compared to the cost of an industrial dc servo for the same desired application I'm not to worried about brush lifetime. I think, I should be able to tune braking response via the pid algorithm.

As of right now though I'm still not getting any action out of my motor with this code.

Works perfectly fine with this code though: https://github.com/PierreAuge/MyMachine/blob/master/ElectronicModules/DigitalServo.c

Problem is, its not responsive, and works over serial. Your implementation of servostrap, is exactly what im looking for. As I intend to implement it into some systems running both grbl and machinekit.

from dcservo.

from dcservo.

Oh no its the same device its just the jargon is a bit different. Thats my lack of experence in programming coming out.

In the linked code the enable pins are be defined as below and both pwm pins are defined but one is labeled direction.

#define ENABLE_R 8
#define ENABLE_L 9

#define MOTOR_DIRECTION 5
#define MOTOR_PWM 6

from dcservo.

OH weird! Youre right! One o the pwm pins is being used as a direction pin.

from dcservo.

Coming back to this, you're correct of course the h-bridge has no direction pin.

It does work though as it should.

Perhaps I should approach this differently. As before using one of the PWM pins on the H-bridge as a direction pin. I feel it's the wrong way to go about it. But it is working.

from dcservo.

from dcservo.

That makes sense. That code is only driving the motor at very low pulse rates so I wouldn't noticed any oscillation. And I don't have a scope to put it on. But intrinsically what you're saying makes sense.

I'll have to figure out why it's not driving it in this configuration.

from dcservo.

Hell ya, I figured it out!

It was a simple coding error.

pinMode(encoder0PinA, INPUT);
pinMode(encoder0PinB, INPUT);
pinMode(ENABLE_1, OUTPUT);
pinMode(ENABLE_2, OUTPUT);
digitalWrite(ENABLE_1, 1);
digitalWrite(ENABLE_2, 1);

I forgot to set the pinMode.

from dcservo.

from dcservo.

from dcservo.

Yeah I got it working, thanks again.

from dcservo.

from dcservo.

Pierre would you be so kind and conclude your approach to it? I have the same h-bridge (43Amps) and arduino nano on hand. I plan to hook up electrocraft DC servomotor to it.
So far used this firmware:
https://github.com/misan/dcservo/blob/master/dcservo.ino

So far it is almost ok. The problem i see is like this: if i set target to, say, X1000 then motor goes very close to X1000, it stops, no vibration. Now i'm checking its status with '?' command and i get the answer like this:
Position=975 PID_output=32.78 Target=1000.00

The question is: why my motor is not moving? It should go ezactly to 1000 position and PID_output value should reach 0 value. Now i have 25 error value, 32 PID output PWM to motor but motor is not moving (too small PWM???). Is it PID tuning issue? I checked it with another servo: Parvex servo motor (1000ppr encoder) and had the same issue.

Please reply.
Thank you!

from dcservo.

it seems 32 output is not enough for your motor to move.If you increase P gain the final error should become smaller.

from dcservo.

I checked one more thing yesterday: I played againg moving my motor back and forth from x0 to x10000, still get 50 or so error and i left it for a while. After some time i checked position with '?' again and the error was cancelled! it turned out that controller is able to set position accuratelly but it takes long time. I got the same motor connected to UHU servo drive and had no issues so i guess the problem is with control loop in software or in H-bridge (low PWM values doesn't move motor shaft).
I can see how the controller slowly increase PID output when small position error occur. The output increases in proper direction until motors shaft move - ca. 40-50 output.
Is it possible to change time constants in PID algorithm to speed up controllers response to small errors? I tried to increase gain but p = 4.2 looks like maximum, i = 1.2 and d = 0.02. Still not perfect though.

from dcservo.

from dcservo.

Hi,
Thank you for reply. I know PID principles.
i tried to use vide range of P's, as well as I and D. Basically i stick to the method of zeroing I and D and increasing P till got oscillations and then tried to smooth it out by adding little I and very little D. But it seems increasing the PID values does not remove the last final hunting for accurate position. it is still very slow as for cnc control.

from dcservo.

https://github.com/PierreAuge/dcservo/blob/master/dcservo/DCServo-IBT2.ino

Im not sure i can much beyond hat Miguel has been saying.

For my working application I use a pro mini. I use two optical encoders with a low resolution encoder disc on the motor shaft not the output shaft. (The motor I'm using has a 5:1 planetary gear box) I get 0.48 degree/pulse with that setup which far exceeds my needs. It moves to its commanded positions and the robot travels between 1m/s and 5m/s so I haven't really seen much of an issue with low PWM values.

I have several of the same motors that I've used while building my robot and as expected the pid values vary considerably. I hook it up to the scope and take my time until I get what im looking for. Which I doubt is helpful so I'm sorry about that.

I should have thought of it sooner, but i have observed that depending on which encoder i was using or if i had a bad electrical contact on any encoder i used i would get erratic position behaviour.

So now I ensure my position control works perfectly prior to any pid tuning. I save that for last, after its installed in the system. Because I've been surprised by how much the mechanics in the system have had an effect on tuning! Its like a guitar, you cant tune a string that isn't installed on the guitar.

But I'm just a student so take what I say with a grain of salt.

from dcservo.

you're right it should be tuned on the machine. Now i'm testing it on my desk so different PID values will be used.
BTN7960 datasheet says max PWM freq is 25kHz. Default PWM freq in arduino sketch is set to 31kHz:
TCCR1B = TCCR1B & 0b11111000 | 1; // set 31Kh PWM

tried to chage it to the next smaller value:
TCCR1B = TCCR1B & 0b11111000 | 2; // set 3,9kHz PWM

but still the controller doesn't set setpoint fast enough.

i'll try to load:

https://github.com/PierreAuge/dcservo/blob/master/dcservo/DCServo-IBT2.ino

as you Pierre did.

from dcservo.