How to Control a DC Motor using Optocouplers with an H-Bridge -- DC to Daylight 18

Hello All,

It was brought to my attention in the YT comments that I professed about the need to avoid turning on same-side H/L transistors which would short the + and - rails, but didn't account for PQWM software timing which would cause an overlapping state.

The function in question:

void motion(int dir, int pwm)
{
    if(dir == FWD)
    {
        analogWrite(H1, pwm);
        analogWrite(H2, 0);
        analogWrite(L1, 0);
        analogWrite(L2, pwm);
    }
    if(dir == REV)
    {
        analogWrite(H1, 0);
        analogWrite(H2, pwm);
        analogWrite(L1, pwm);
        analogWrite(L2, 0);
    }
}

Now that my error has been revealed,... I have a simple solution in mind. How would you handle it? What would you change about this function?

-Derek

Do it in hardware. Don't most H bridges have an additional transistor on each side to prevent those 'magic smoke' situations from occurring?  

Yep. I've seen some clever approaches using additional hardware logic to prevent no-no situations... even reducing control lines. However, I didn't want to add another layer of complexity for presentation (though in this case, the software came back to bite me anyway). Maybe those additional transistors would have been a good feature after all. 

-Derek

I can't seem to find the lecture that I was thinking of. I thought it was part of this one by Bruce Land at Cornell Uni: 

https://youtu.be/WlU-uIC2LNk?list=PLD7F7ED1F3505D8D5&t=1218

but it is missing the part I was thinking of that discussed various protection methods.  

Never control with software! I love it. This is a good tip for designing actual hardware that has the potential to lose the smoke.

Perhaps just think of Therac-25 where reliance on software over hardware interlocks was allowed in the design and the horrific consequences that followed.

I personally try do both - where possible. The software shouldn't tell the hardware to do something that is logically unsafe, and the hardware shouldn't assume that the software won't signal it to do something unsafe. The motion function in the sample I provided is actually a simple example of that. motion() was changed to only accept bytes, so it can rely on pwm never being out of range, and direction is handled in a switch that's completely ignoring invalid directions (the only side effect of such should be causing harmless extra 'stops'). It also doesn't rely on an external variable to keep track of current direction, so from the function's perspective, it can rely on no external actor accidentally modifying that variable.

I personally try do both - where possible. The software shouldn't tell the hardware to do something that is logically unsafe, and the hardware shouldn't assume that the software won't signal it to do something unsafe. The motion function in the sample I provided is actually a simple example of that. motion() was changed to only accept bytes, so it can rely on pwm never being out of range, and direction is handled in a switch that's completely ignoring invalid directions (the only side effect of such should be causing harmless extra 'stops'). It also doesn't rely on an external variable to keep track of current direction, so from the function's perspective, it can rely on no external actor accidentally modifying that variable.

Any function or method should have proper validation / abstraction / encapsulation - good programming practice... proper input validation for each and every function or method is also key. The demo code in the video is not the best example of 'good programming practice' - the goal was really to just show how the h-bridge works. Though a good takeaway from this discussion thread: Maybe it's better in making simple demos, not with the intent of making them appear more concise on screen, but more inline with how it'd be done in the real world.

I can't speak for other industries, but at least in semiconductor, hardware has the final say - for Semi (S2?) standards, there must be an exclusion zone and any access points must be interlocked - hardware loop with redundant lines that kills servo if the loop is broken. Both signals must transition within x number of milliseconds or servo is also powered down immediately. One of the unwritten rules is, never enter the 'zone' - because you never know what the software could do - like in the Therac-25 thing, race condition causing unexpected behavior. Good read by the way.