I don't understand why. (Assuming two ~identical controllers.)
Thanks for grounding me AW.amberwolf wrote: ↑Feb 11, 2018 2:25 amOne possible problem:
Clock cycle start and end times won't likely match even if everything is identical in the contorllers, so PWM of FETs won't match. Exactly what that results in depends on how the controllers do their PWM.
Frequencies won't match perfectly either, so after enough clock cycles they'll drift apart far enough so that even if somehow you got the clock cycles to match up at first, they won't later.
If timing is far enough different, then even with both controllers reading the same hall signals, the first PWM cycle of one phase of one controller might overlap the last PWM cycle of the previous phase of the other controller.
That means you may have some top FETs being switch on while other bottom FETs are being switched on, and if it happens on the same phase wire then the only resistance there is would be the wire from one controller to the other (meeting at the motor phase input).
That resistance is likely to be low enough to essentially be zero, resulitng in what amounts to a shoot thru from battery positive to battery negative thru the FETs of both controllers.
If it's a short enough event, it just results in heating those two sets of FETs more than others (possibly a lot more), but once the desynchronization starts, it will probably last long enough to create enough heat inside teh controllers from that sort of event that something could overheat and fail. It might never get taht far...but it could, under the right (wrong) circumstances.
You can test the theory easily enough if you have the money to possibly throw away (I would, but I don't have controllers I can sacrifice).
Aren't there (electrolytic) capacitors in the output circuit after the mosfets; and wouldn't their ESR and /or ESL act to resist shoot through?
I'm saving my pennies to buy a couple of RC ESCs and matching small motors to play with, specifically to try and wrap my brain around some stuff that currently leaves me cold; but I'll be trying to only try things that I have a reasonable assumption won't blow anything up, cos I can't afford to.
Thank Alan!Alan B wrote: ↑Feb 11, 2018 7:32 amAt first thought it seems like paralleling controllers on sensored brushless motors is nuts. This turns out to be incorrect thinking.
On more careful analysis one realizes that the necessary synchronization is provided by the hall sensors. There is no requirement for the PWM to be in phase. The voltages are identical since the same power source is used and the FETs are merely switches that allow current to flow.
The increased current is provided by the lowered resistance of the "paralleled" FETs, each provides part of the current based on the PWM and their resistance. The inductance smooths the PWM current as usual.
It is not a perfect situation, but it has been demonstrated to work. It does not catastrophically fail.
If you think it is going to explode, or short the battery then analyze it deeper. The three phase motor's operation as it changes states is key here. The adjacent states in the six state phase cycle are compatible. At each switch point one phase goes open, and the previously open phase goes high or low. Being simultaneously in both states is not creating a short, so being in both states for a short time doesn't create problems. This is not like having both high and low FETs in the same phase driver on which creates a low resistance low inductance supply short.
There are no caps *after* the FETs, because that's the motor windings (phase wires). (There are some *before* the FETs, on the battery side, but they act like extremely low resistance batteries in parallel with the "real" ones as far as the circuit is concerned).
There are two possibilities for the PWM being in or out of sync. The start/end of each sine wave (or tapezoid); and, the start/end of the individual pulses that go to make up those waves.
This is where I move on to even more shaky ground -- which is not to say I have any great confidence in the above.
There aren't any smoothing caps on the motor side of the FETs--those are only on the battery/gate side, on the controllers I've had.
Because shoot-thru prevention inside a controller is mostly a matter of timing things so that never happens, and/or ensuring the circuits to drive the FETs are interlocked so the bottom and top FETs in any one phase of that specific controller can never be on at the same time.But if neither controller is susceptible to shoot-through from the potential that continuously exists on it associated phase winding -- whether due to the reluctance of that winding, or the back-EMP being generated in it -- then why would it be susceptible to potential coming from the other controller?
In every controller circuit I look at, from the simplest bare-bones example with its "Main capacitor", to (what I assume to be) the most well-designed and sophisticated (from here), where there are paired (polorised and non-polarised) capacitors per phase, labelled C15/C18, C16/C19 and C17/C20 respectively; there are capacitors to prevent spikes across the battery, parallel to the top & bottom mosfet circuit, that would provide current if the battery weren't able to, should both fets be open at the same time.amberwolf wrote: ↑Feb 11, 2018 11:24 pmThere aren't any smoothing caps on the motor side of the FETs--those are only on the battery/gate side, on the controllers I've had.
The only thing out there past the FETs to do smoothing is the motor windings and the wires from the FETs to the windings.
If there were caps on the FET outputs, they'd have to be non-polarized because polarity reverses during commutation.
The only concise, non-technical description of regen I've seen (from a half descent source) is this one.amberwolf wrote: ↑Feb 11, 2018 11:24 pmSomething else not covered is electric braking: ... The way it switches the FETs is different than when it's causing current to flow to the motor from teh battery, so I don't know if there's even any possiblity of shoot-thru in this case, but I suspect there is. Even if there's no battery-shoot-thru, perhaps there could be a form of shoot-thru from one phase to another.
This type of circuit (where hi-side is turned on when the loside is off) is capable of sourcing current or sinking it. The way this works is that the reversed motor current is now a forward current to the flywheel MOSFET so when this is on it shorts out the motor - whose braking current rises during this period (arrow B, reversed). The Flywheel MOSFET now turns off, but this current must keep flowing - because of the motor's inductance. So it flows as reverse current through the drive MOSFET, recharging the battery as is does so. The extra voltage for this is derived from the energy stored in the motor's inductance. The process of switching from drive to braking is entirely automatic. Moreover it is done entirely by the motor's speed exceeding the drive voltage and without any change of state or switching within the controller. The regen braking is, if you like, a by-product of the design of the controller and almost a complete accident.
Yes, those caps exist, but they are on the FET's power supply (what the FETs are switching to send to the motor), not their outputs. There are no caps on the FET outputs, with the motor phases.Buk___ wrote: ↑Feb 12, 2018 2:57 amIn every controller circuit I look at, from the simplest bare-bones example with its "Main capacitor", to (what I assume to be) the most well-designed and sophisticated (from here), where there are paired (polorised and non-polarised) capacitors per phase, labelled C15/C18, C16/C19 and C17/C20 respectively; there are capacitors to prevent spikes across the battery, parallel to the top & bottom mosfet circuit, that would provide current if the battery weren't able to, should both fets be open at the same time.
Stated simply, I'm still failing to see how the presence of the other controller's output (detected or not) at this controller output, could cause shoot through within this controller, unless this controller is already susceptible to shoot through; in which case it would occur anyway, regardless of whether the other controller's output was there or not.
That is actually almost exactly what I"m talking about, in that it is deliberately shorting the motor phases (which because of commutation plus PWM in a brushless motor is more complicated than a brushed with just PWM, which is what the 4QD site talks about) momentarily to increase the voltage output above battery voltage, so that it can cause current to flow into the battery (and create drag in the motor to slow you down).
Thanks for the link.Gregory wrote: ↑Feb 11, 2018 10:22 pmSamd was posting that he'd had some successes using two controllers a couple of years ago, but no follow up on actual road use and longevity. Personally I'd just get a bigger controller.
https://endless-sphere.com/forums/viewt ... =2&t=75186
Buk___ wrote: ↑Feb 11, 2018 10:29 pmIn every controller circuit I look at, from the simplest bare-bones example with its "Main capacitor", to (what I assume to be) the most well-designed and sophisticated (from here), where there are paired (polorised and non-polarised) capacitors per phase, labelled C15/C18, C16/C19 and C17/C20 respectively;
Very valid point. I tend to think of a brushless 3-phase controller, as 3 brushed, single phase controllers with interlaced and offset PWM.amberwolf wrote: ↑Feb 12, 2018 3:42 amRemember that in the 4QD stuff, the brushed motors do not have any commutation perfrmed by teh controller--it's all mechanical inside the motor.
But in brushless ocntrollers such as those generally discussed here on ES (especially in threads like this one), the controller not only performs PWM to control the motor speed, but also performs the commutation by swithcing between different halves of different bridges for different phases.
It's still almost the same...but not quite. And that's where the problem can arise.
Understood, but I like your explanations of this stuff, because you seem to be able to write them at a level that (eventually) penetrates my thick skull. And I thank you for that!