Modification a larger H-Bridge #21
Comments
|
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. |
|
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. |
|
The code you mention that works seems to interface with an H-bridge that
has ONE PWM input and one direction pin. However the info you attached
mentions an h-bridge that has TWO PWM inputs and zero direction pins. It
does not seem to be the same device and code is not the same.
…On Mon, Apr 17, 2017 at 4:02 PM, PierreAuge ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAccyBdKyM2Sd9N_6RWHLORvqyMPpPiwks5rw3ENgaJpZM4M-2NJ>
.
|
|
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 MOTOR_DIRECTION 5 |
|
OH weird! Youre right! One o the pwm pins is being used as a direction pin. |
|
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. |
|
Using one pin as direction means it is either 0 and you're PWM'ing the
other which goes one way ok or it is 1 and then your PWM on the other pin
is now inverted (meaning 0=MAXPWM and 255=MINPWM).
The fact that it may seem to work does not make it right.
You may have rough settling in one direction and smooth on the other or
just it may oscillate easily at times.
…On Mon, Apr 17, 2017 at 6:47 PM, PierreAuge ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAccyLJUUHHxH82JWh5Rc7pDdz9jVkDAks5rw5eigaJpZM4M-2NJ>
.
|
|
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. |
|
Hell ya, I figured it out! It was a simple coding error. pinMode(encoder0PinA, INPUT); I forgot to set the pinMode. |
|
I failed to see that. Glad you figured it out.
…On Tue, Apr 18, 2017 at 4:12 AM, PierreAuge ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAccyA07wDFgH80xdr9mqaQ25BBGvAHmks5rxBwrgaJpZM4M-2NJ>
.
|
|
This going endlessly is usually associate with wrong motor polarity. Test
again after swapping motor wires.
…On Wed, Apr 19, 2017 at 3:46 AM, PierreAuge ***@***.***> wrote:
Hello again,
Do you have any idea why I would be getting this behaviour? It is clearly
measuring the position but rather than stopping at the commanded 10 steps
it just keeps going. I haven't tuned the PID settings yet could that have
anything to do with it?
Thank you again,
Pierre
Position=0 PID_output=0.00 Target=0.00
Position=0 PID_output=0.00 Target=0.00
Position=0 PID_output=0.00 Target=0.00
Position=-171 PID_output=255.00 Target=10.00
Position=-800 PID_output=255.00 Target=10.00
Position=-1428 PID_output=255.00 Target=10.00
Position=-2056 PID_output=255.00 Target=10.00
Position=-2682 PID_output=255.00 Target=10.00
Position=-3309 PID_output=255.00 Target=10.00
Position=-3934 PID_output=255.00 Target=10.00
Position=-4557 PID_output=255.00 Target=10.00
Position=-5180 PID_output=255.00 Target=10.00
Position=-5802 PID_output=255.00 Target=10.00
Position=-6425 PID_output=255.00 Target=10.00
Position=-7046 PID_output=255.00 Target=10.00
Position=-7667 PID_output=255.00 Target=10.00
Position=-8287 PID_output=255.00 Target=10.00
Position=-8907 PID_output=255.00 Target=10.00
Position=-9527 PID_output=255.00 Target=10.00
Position=-10146 PID_output=255.00 Target=10.00
Position=-10766 PID_output=255.00 Target=10.00
Position=-11385 PID_output=255.00 Target=10.00
Position=-12004 PID_output=255.00 Target=10.00
Position=-12624 PID_output=255.00 Target=10.00
Position=-13242 PID_output=255.00 Target=10.00
Position=-13862 PID_output=255.00 Target=10.00
Position=-14482 PID_output=255.00 Target=10.00
Position=-15102 PID_output=255.00 Target=10.00
Position=-15721 PID_output=255.00 Target=10.00
Position=-16340 PID_output=255.00 Target=10.00
Position=-16959 PID_output=255.00 Target=10.00
Position=-17578 PID_output=255.00 Target=10.00
Position=-18197 PID_output=255.00 Target=10.00
Position=-18816 PID_output=255.00 Target=10.00
Position=-19436 PID_output=255.00 Target=10.00
Position=-20055 PID_output=255.00 Target=10.00
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAccyHsWQNkePVVUSsBJEzqEcUhJxoc5ks5rxWd_gaJpZM4M-2NJ>
.
|
|
Yeah I got it working, thanks again. |
|
great. congrats.
…On Thu, Apr 20, 2017 at 12:13 AM, PierreAuge ***@***.***> wrote:
Yeah I got it working, thanks again.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAccyA1yMzEWIQ071h2GaQrDUQZ6qwKUks5rxocJgaJpZM4M-2NJ>
.
|
|
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 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: 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. |
|
it seems 32 output is not enough for your motor to move.If you increase P gain the final error should become smaller. |
|
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). |
|
That is taken care of by the integral action (zeroing steady state error).
Over a while, it increases output to offset remaining error. Not only it is
possible to change Integral and Proportional gains but that is what tuning
is about and it is highly recommended to get a good response. The only
problem is that you have to find out the right values, as a too high value
may lead to oscillation. You can increase P over 5, no problems other than
possible oscillation of your system.
…On Tue, Sep 5, 2017 at 8:56 AM, bogus105 ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAccyCBqE47BAVMjwaf2W0X3VHyvh945ks5sfPC6gaJpZM4M-2NJ>
.
|
|
Hi, |
|
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. |
|
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. tried to chage it to the next smaller value: 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. |
Hello,
I'm attempting to adapt this for use with a larger H-Bridge (IBT-2) high current module.
The H-Bridge has right and left enable and pwm pins. I've changed the pin layout in the sketch to correspond with the wiring which makes the most sense in my system. I've been using these H-Bridges for a couple of years and usually have a decent grasp of their use, but it's late and I'm not making any headway.
#define encoder0PinA 8 // PD2;
#define encoder0PinB 9 // PC0;
#define M1 5 // RPWM on IBT-2
#define M2 6 // LPWM on IBT-2
#define ENABLE_1 4 R-EN on IBT-2
#define ENABLE_2 7 L-EN on IBT-2
I've attached my sketch which really has no changes with the exception of the addition of the enable pins and their being declared HIGH in the setup() function.
It's clearly late because I nearly forgot to include the problem. It's not working! :) I'm not getting any motion, it's compiling just fine and I've got serial comms but I'm not getting the HBridge to work correctly.
Any ideas, I'd really appreciate it?
Thank you,
Pierre
https://gist.github.com/PierreAuge/79c03b8b5e85f0df4993ff28212f97fb
The text was updated successfully, but these errors were encountered: