OK, Ignore this post. I got a bit confused. I took a second look and realize now that one H Bridge is attached to 4 different Digital ports. One signal wire to each port. Then there is a 5vdc & Ground going to the H Bridge. As long as I don't run out of ports I can line up the H Bridges.

Dave

yup You just can't use a Movement Panel for the Second HBridge.

I'm facing a problem I've been dealing with for days and it is clear now that this is because I'm reaching the limits of my understanding of HBridges... which is not very high in the first place

My hbridge has its left side starting up slower than the right side, resulting in a left turn each time the robot stops and starts again.

I'm using two hbridges connected to the same EZBV4 and each of those bridges is connected to a set of two motors (because these 12V tetrix high torque motors take too many amps to be all four on the same bridge).

Could this be related ? It seems though that it is not because I tried disconnecting one bridge and working on one only and no change.

I tried different ports. Different boards too.

If anyone has an idea on where to look. I measured the current comming out of the bridges to the motors and it clearly appears that the current takes more time on one side to reach its peak than on the other side, so it is not motors related.

Hridges are both connected to D ports 19, 20, 21, 22.

thanks in advance for your help.

How are you measuring the voltage between the two to see that one is coming on before the other?

Can you physically see the first motor starting to turn before the second motor?

I cannot imagine a scenario where that would happen, unless the hbridge was behaving strangely due to extreme thermal conditions (i.e. too hot), but don't quote me on that because i don't know how the controller would behave under extreme thermal conditions.

Are you certain that one channel of the hbridge is not just merely PWM slower? Or, that your motors are displaying attributes of the physical world? In that not all motors spin the same speed at the same voltage due to the fact that they're not the same physical device sharing the same point in space/time? meaning, no motors spin the same speed without a sensor encoder and pwm modifier. Which is why you see the Kangaroo mentioned so often on this forum.

Hi DJ

The motors are of same model. But no encoder.

I do physically see one starting slower than the other.

No thermal issue from what I can see, heat sink is ok, barely warm.

pwm are identical on left and right but I tested with no pwm at all and same issue was going on.

I measure the current on both left and right outputs of the Hbridge.

left : 1,xx V then 2. xx volts then goes to pwm set max voltage.

Right : immediately 2 V and very fast goes to max voltage.

And this on both sides and even if I'm changing ports and even with different motors. I think I tried everything! I don't know how the 2 hbridges could have the same issue. I have a spare, but identical so if this is a manufacture problem it might not make a difference, although it used to work fine with the same bridge.

It used to work. I don't know what's going on. I have one spare new hbridge so I will hook it up to see if it changes anything.

I can't run any one of my scripts now, especially the docking ones, which are orientation sensitive, even using scripting in custom motor movement (adding delays, and playing with pwm).

Thank anyway for your answer.

ELfège.

That's such a strange thing - I have no idea how something like that can occur. So it's noticeable to the human eye? How much of a delay are you seeing?

Is the delay in seconds or milliseconds?

Elfege,

H-bridge model ?

I think Im gonna use encoders. I just thing know how I am supposed to use them. I guess it's a digital read value, right? In pretty sure there's already a Tuto for this I'll look it up.

I managed to lower the delay to a minimum by changing all the wires. Some wires must have had issues with time and 12-16v loads at 2 amps...

But even with brand new wires I always had a slight delay, like 20ms, which is enough to be a problem for some Operations. So... Encoders will be the next step.

Thank you all.