Returned Energy Dump board — requesting design review

Help! I just designed a circuit and I don’t know what I’m doing!

Over on Maker Forums Social, I’ve been live-posting my design work on an enhanced returned energy dump. This all started because I am considering converting the X power feed on my mill to something where I can set a table travel speed. That means more expensive electronics than the junk that Blondihacks found in the unit and I’d like to protect it!

If the table reaches a hard stop, or (horrors) I have a tool crash that hangs up the head, I’d like the controller to stop the table motion. That would require fault detection.

I would really appreciate review from folks who know more than I do about circuit design!

This part of the circuit is the original circuit from Gecko with a few part replacements for what I find available now. This part I’m reasonably confident in.

Here’s the sub-circuit for sensing fault:

This one I have no idea whether it would actually work.

My idea is that it triggers when the motor voltage rises above about 42V. 39V through D2, 1.4V (or slightly less) through the optocoupler, and about .25V through R4. (R4 of course dissipates more power as the voltage across it increases.)

Then Vcc from a microcontroller (any voltage up to the 18V maximum of the 6N139 optocoupler) will pull up the Alarm output high when it’s working, and pull it low in a fault. So it should be ~Alarm I guess; it’s inverted.

Does that circuit make sense to those here who know what they are doing? I know there are several of you. :relaxed:

More in the README.md · main · Michael K Johnson / ReturnedEnergyDump · GitLab — that repo has complete KiCad 6 files for the board, gerbers and drills, and datasheets for most if not all of the components.

I had not thought much about the "returned energy " problem when decelerating a loaded motor.

I wonder is there a difference between:

A: a motor rapidly decelerating a load under control…"Energy return occurs when a large inertial load is rapidly decelerated from a high speed. The energy stored in the moment of inertia (kinetic energy) must be removed and dissipated."

B: A motor that is being driven into a stop and stalling.

In the case of A the drive current is decreasing and a reverse current is experienced due to the energy stored in the inertial load being converted to electrical energy

In the case of B the motor is being driven and at stall the current is sharply positive and increasing.

mmmmm …

1 Like

Yes, I think that the shape of the curve is different between case A and B, though it doesn’t keep climbing indefinitely in case B of course.

I’m worried primarily about B in my case (hitting end stops), but @Mark_Rehorst tested with A in his video in Mark Rehorst's Tech Topics: Bank Account Protection Circuit for Servo/Stepper Motors where he demonstrated that merely commanding the motor to stop quickly caused a large transient to return to his power supply without the RED.

I think that case B (without an alarm sense circuit) is why the original Gecko circuit uses a huge 10W load resistor — it can dissipate a lot of power before starting to glow. The wire-wound ceramic resistors I found had short time overload rating of 2.5x, 5x, or even 10x their continuous rated power for 5 seconds, so with a working fault detect circuit, it is not clear to me that a 10W resistor is necessary. In my use case, size may end up being important (I haven’t pulled apart the power feed to see what I have to work with) and perhaps a physically far smaller 2W or 3W ceramic wire-wound resistor would be sufficient.

I suppose that a 65-75V clamping voltage MOV between the motor and ground would help dissipate very short transients that might otherwise damage the 100V components like that tremendous capacitor.

I was trying to rationalize if in case B, there is any/much reverse current that is detectable because some energy is mechanically dissipated by the impact on the stops and the current is actually increasing in the + direction until something shuts off the motor drive?
Also as the motor goes into stall and the current increases the motor terminal voltage may actually drop.

In the video test you reference the motor is stopped by reducing the drive current not by mechanically stopping it.That is except for the resistance of the gearbox. In this case (A) the motor drive goes to 0 the gearbox resistance stops the motor and the reverse current spike is the only current seen at the motors terminal.

It seems to me that if running into the stops creates this spike then a lot more CNC systems would be damaged on a regular basis. Then again maybe they are …
That said, it seems like this protection is a good idea.

On a different note, I was also wondering if you could sense the reverse current on R3 as there will be no signal across that resistance until Q1 turns on.
Would that be a simpler circuit since you do not have to worry about ignoring [filtering out] voltage changes on the motor drive under normal operation? Would this prevent false alarms? I do not know how much reverse current Q1 sees so I have no idea how big that signal might be and therefore what a good interface circuit might look like.

Case B was what happened to Mark in the first place that caused him to learn about the returned energy dump. A mistake caused him to run his servo-driven carriage in his Arrakis sand table hard into the stops, and it killed more than $200 of hardware. So his video about the RED shows case A, but his use of the circuit was triggered by case B. He demonstrates case A which doesn’t actually fry his power supply but does show rise in voltage, but it’s a smaller rise.

My understanding was that it fried the power supply and the control board. Because it’s a servo, I expect that there is a full H-bridge there, but by the design of the RED it has to be between the supply and the H-bridge, so the H-bridge needs to be robust. I think what happened to him was that the power supply was killed, and the control board was killed not by frying the H-bridge but by overwhelming the voltage regulator from the supply voltage that it shared with the motor. He is using integrated servos that have the servo control circuit integrated with the motor in a single body, and talking to the controller at the logic level, so presumably there is protection inside that unit of some sort for the power circuits. But it was his power supply and control board that were fried when he ran into a physical stop (case B).

As I understand it, It’s not primarily rotor inertia; it’s the collapsing magnetic field that spikes the voltage. But this goes beyond what I’ve studied.

I’d like to understand this better, and doing some experiments on the bench probably make sense. I think I’d like to characterize this with smaller motors first that won’t kill my bench power supply! :smiling_face:

You know, I thought about that…

My initial circuit used a photodiode optoisolator instead of a darlington optoisolator, and then I didn’t have to provide a separate supply voltage for fault sense. I added the supply to support the darlington opto to reduce power dissipation in R4. But if I sense across R3, then I need to provide separate power for the sense circuit, and that’s not isolated. I’d like the sense power supply to be isolated from motor power supply (it could logically have a different reference ground) and specifically for it to be from the power supply for the control circuit rather than the motor power supply. Ultimately it’s not clear to me that it’s simpler than the diode-referenced voltage divider and optoisolator I came up with. (I could be missing something though. I recognize that “programmer tries to design electronics” can be something of a spectator sport. :rofl:)

I could use an op-amp to sense R3 if I add a separately controlled power source for the sense circuit, in which case I could use a photodiode optoisolator. But then I have to make sure that supply is also protected from the spikes that this circuit is designed to detect! :smiling_face: Quis custodiet ipsos custodes…

In any case, I really should at least consider adding a MOSFET to invert the alarm signal, so that the alarm is active-high. That will probably better match user expectation. A small-signal MOSFET like a BS170 would be fine. (Amusingly, I think they are larger than the SOT-23 power MOSFETs I have!)

Perhaps AC couple to R3 as you only need to see the reverse current pulse.

This is where I display my ignorance; my recollection of “AC coupling” has been capacitive ­— wouldn’t that require a shared ground reference?

How about using a “rpm sensor” instead for the case of a blocked spindle?
This could be done with a simple photodiode mounted to the spindle and a NE555 IC for detecting the moving spindle. As long as pulses are comming with a maximal delay, the output could be enabled. This could also be used to “synchronize” the feed with the rpm.

1 Like

Good idea…

Yes capacitive, you only need to see the reverse current spike.

The ground would be shared but not aware of that as a problem?

I agree that some bench tests should be performed to better characterize the reverse current spike.

I’m thinking of a small motor with a wand on the shaft. It spins and an interposer flips up and stops it.

The simple version is stopping it with your fingers ;).

Since we have no idea how big the reverse current and voltage spike, my non technical intuition, warns that sensing at the motor might be unpredictable.

Another consideration: how fast does the alarm and response have to be before anything is damaged?

Not all crashes stop the spindle turning. And that’s not the primary purpose; I want to stop when hitting hard stops.

I’m trying to avoid ground loops.

I don’t think that’s well established generally; I haven’t even decided whether to try to use the existing motor or replace it with a different one. I’m going to try to avoid depending on this circuit; it would be a backup. I’ve never actually hit the limit switches on my mill except when I was testing where to put the stops for it.

Don’t know if this is applicable but the Ruida has not only homing switches but also limit switches specifically for this.

Most don’t use them, but the + inputs such as LmtX+ on the Ruida is the input for a limit switch…

Just seems like a simple solution, but if you want an electronic one… I guess it’s not much help…

Here is a Ruida layout with home (red) and limit switches (green)…

:smiley_cat:

On large and powerful machines those limit switches could save the machine from destroying itself.
But software has become smarter and seems to know something about overscan and speed but as they say, better safe than sorry.

In this case, no. The bed has lots of inertia, and the limit switch that shipped with the original power feed has springs in it to allow it to trigger before it actually hits the end, and even that isn’t enough to slow it down enough in time.

I don’t have a good answer but have been following this with interest.