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

Nice episode.

I like the use of the optocouplers, safety first.

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.

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.

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

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

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.  

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

Ha. I cringed a little when I used int's as well, but it's a fine line - keeping a simple presentation vs. the most efficient way to write code.

Anyway, I like your solution!

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

const byte FWD = 0;
const byte REV = 1;

const byte H1 = 3; // PWM pin 3
const byte H2 = 5; // PWM pin 5
const byte L1 = 6; // PWM pin 6
const byte L2 = 9; // PWM pin 9

const unsigned long DWELLTIME = 2000; // time mS to hold at max speed
const unsigned long PWMSTPTIME = 10; // mS delay between PWM changes
const unsigned long STOPTIME = 25; // mS delay between direction changes
const byte PWMMAXVAL = 255; // 8-bit PWM so 0 - 255


byte direction = FWD;


void stop() {
  analogWrite(H1, 0);
  analogWrite(H2, 0);
  analogWrite(L1, 0);
  analogWrite(L2, 0);
  delay(STOPTIME);
}

void motion(const byte dir, const byte duty) {
  static byte current_dir = 2; // keep track of current h-bridge direction, initialized to invalid state

  // Check for direction change (or first execution)
  if(dir != current_dir){
    stop();
    current_dir = dir;
  }
  
  switch(dir){
    case FWD:
      analogWrite(H1, duty);
      analogWrite(L2, duty);
     break;
    case REV:
      analogWrite(H2, duty);
      analogWrite(L1, duty);
      break;
  }
}

void ramp_pwm(const byte start, const byte end){
  if(start == end) return;
  const short step = end > start ? 1 : -1;
  
  // ramp profile
  for(short pwmvalue=start; pwmvalue != end; pwmvalue += step){
    motion(direction, pwmvalue);
    delay(PWMSTPTIME);
  }
}

void setup() {
  Serial.begin(9600);
}

void loop() {

  // ramp up profile
  ramp_pwm(0, PWMMAXVAL);

  // dwell in plateau
  delay(DWELLTIME);

  // ramp down profile
  ramp_pwm(PWMMAXVAL, 0);

  // swap direction
  direction ^= 1;
}

Something like this, maybe.
I tried to keep it relatively simple, but my sensibilities scream about using int when it's not necessary (or non-stdint types for that matter, but I compromised).