I used the driver for the DC Motor Shield in a project I did. That diver can be found here:
My project can be found here:
When I drove the motor with a positive signal it worked as I would expect but when I drove it back it did not respond as I expected. So, I looked at the driver and made a modification to the Move function. But, after thinking about I I probably should have just figured out how to make it work as designed.
The line in question is line 49:
if (speed1 < 0)
_pwm1.Set(1000, (byte)(100 - Math.Abs(speed1)));
When I sent a small signel the motor would drive full and then slow down as I went from -1 to -100. I wanted it to start slow and go up instead so I changed it to:
if (speed1 < 0)
Anyway, maybe someone could explain it to me so I can use the driver as designed.
This is the signel I expected.
To understand you need to know how the processor pins are connected to the H-bridge. You need to examine how the motor control board works. The software driver should drive it properly
Hey thanks for the response. I guess that is what I am trying to do with this question. I am not an expert in electronics so if there is a resource, ralated to the motor shield, that I can look at to better understand this I would be happy to review it. As it is I am just trying to understand why sending a single of -1 would run the motor at full power and -100 would turn the motor off. This just does not make sense to me.
I was using this shield today and it still looks like there is a bug in the driver. In the Move method, if the speed is negative, the current code (downloaded from the tinclr website) has a calculation for
100 - Absolute(speed)
This looks like it should just be Absolute(speed). Until you modify this line of code, you cannot seem to move the motor in reverse. It lo0oks like the driver needs to be fixed.
I came across the same issue with the DFRobot 2A motor shield. I have modified the driver here:http://www.fezzer.com/project/215/dfrobot-2a-dc-motor-driver/
Since I did not own the other shield, I wasn’t sure if it was working correctly.
That is supposed to be like that, although
100 + speed
will do the same, maybe a bit faster?
Basically the PWM value must invert for reverse.
The motor is driven when the PWM pin and the DIR pin isn’t the same value.
For forward the DIR pin is 0, so the speed is determined by how much the PWM pin is 1. Thus 90% will give you a 1 90% of the time, which will give you 90% speed.
For reverse things change a bit. The DIR pin is 1, so the speed is determind by how often the PWM is 0. Thus the 90% for the PWM will give you 1, 90% of the time, but a 0 only 10% of the time, which will give you 10% speed.
I can’t find the circuit to check if the pins are connected correctly, and I don’t own one to measure it.
I do know that I had a problem on my own design where reverse worked fine, but forward was weird. After LOTS of searching i realised that if both pins are 0 then the driver turns off. Thus the DIR pin, set to 0, disabled the driver when the PWM was 0. Big mess.
No, I am pretty sure there is a bug in the driver. Once you make the cahnge to the code, it all works great. To verify, you don’t even need motors connected - just look at the LEDs. The move(-m, x) command never goes into reverse the way the code on the website sits right now.
OK, I understand that the driver works - it just doesn’t work as expected. And, a change to the code makes it work as expected. The circuit does not seem to tie the PWM and direction signals together logically as explained by Errol, but maybe.
Regardless, when a user sends the driver a value of 100, he probably expects it to go forward at 100%. When he sends a -100, he expects reverse 100%. None of my students expected that in order to turn in reverse 80%, you would send the method a value of -20. Especially since the driver is the one recalculating the value then sending the PWM code a value of 80 anyway.
Maybe the described situation is correct for some motor driver boards, but it doesn’t seem correct for this one. This driver is taking the -20, converting it to +80, setting the direction bit on the board and then sending the +80 to the PWM.
It just seems like sending the -80 in the first place makes the most sense. The parameters to the move are called speed1 and speed2. I do not expect a speed of -100 to be an actual speed of 0 as it is currently coded or a speed of -80 to be an actual speed of 20 as it is currently coded.
Maybe this was done to match up with some older motor driver convention, but I think it makes the driver much harder to use - or it is a bug. Maybe it made it easier to code the moveramp function.
The example by Gabriel on Fezzer.com works as I would expect. My suggestion is that the one on the TinyClr website be inspected to determine if it is really working as expected by GHI.
We will give it a try. My understanding that is not critical as you guys have it working…thanks to the open source drivers
As I understand the are 2 pins - one for direction and one for speed.
Wouldn’t this be the right way of doing it?
_dir1.Write(speed1 < 0);
I assume that _dir1(true) is reverse and _dir1(false) is forward. It is a linear function. Absolute value controls the speed and sign of the value controls direction.
Yes, Architect, the code you give works correctly.