Is it possible to connect the phase wires of two vescs in parallel to run a single larger motor? The application is a boat so no regen or braking needed just power.
How about if we take this same problem but recast it as one of redundancy? There are many mission critical applications where it's worthwhile to have a second ESC which is idle and only steps in in case the the first ESC fails. Has there been any work in moving VESC in this direction?
The big problem is ensuring that both VESCs are in lockstep despite oscillator drift. The worst case scenario is that both VESCs drive oppositely, one trying to raise the common winding to VBAT, the other to 0V. This will release the magic smoke in at least one of the VESCs, so is less reliable than a single, properly specified ESC. A motor with six windings and 2 VESCs is the closest you'll get to this.
Honestly, if you're after reliability VESCs aren't really right solution, you wanna start hitting up companies like MGM Compro or Maxon or Faulhaber. The Axoim project have taken the basic VESC design and added an FPGA (amongst other things) to do a whole load of fault checking and shut the VESC down if anything looks funny.
Honestly, if you're after reliability VESCs aren't really right solution, you wanna start hitting up companies like MGM Compro or Maxon or Faulhaber. The Axoim project have taken the basic VESC design and added an FPGA (amongst other things) to do a whole load of fault checking and shut the VESC down if anything looks funny.
We're getting a little away from the topic here, but I'll bite. I would argue that, to the contrary, firmware reliability doesn't come from closed-source companies. I've done open-source and closed-source firmware and the difference isn't in the skill, it's in the testing. Both domains have incredible programmers, and incredibly bad programmers. You can even get great product from bad programmers, so long as the product is very narrowly defined and purpose-built. The real indicator is whether there's a track record of the product being successful in a myriad of use cases. (Is that the case for VESC?)
MGM Compro is an awesome place with a great track record of being used from R/C cars to full scale aviation, and if money were no object then you could pay them to thoroughly test any new features you'd like. You could also pay for independent review of their source code, schematics, and BOM to make sure it is acceptable for your application. This would be the NASA grade solution.
But if your pockets don't run millions of dollars deep, VESC has a tremendous advantage when it comes to new features because you can implement them yourself, and they get tested across an entire fleet. If you have MGM make you a bespoke feature, that feature will likely not get rolled out to anyone else, and so it becomes a maintenance burden for everyone with you as the sole tester. Every esk8er who is successfully running the firmware is demonstrating there are no hard lockups or smoking ESCs, and if new features introduce bugs then those are discovered very quickly as well.
The nice thing about ESCs is that once a problem is solved, it's solved forever. That's not to say that it's easy, just to say that once that feature exists in VESC and is in use by the community the feature gap between commercial and open-source narrows permanently. Over a long enough duration, the feature gap goes in favor of the open-source project. We've been seeing this since the days of Linux and we recently are seeing it in drone autopilots where the market outside of small niche players is entirely open-source.
Of course, when it comes to hardware selection, this is another game. Even if you took MGM Compro's schematic and layout, you wouldn't get the same quality they do unless you did the same testing and manufacturing.
Reliability doesn't automatically come from closed source companies but as they're the only seller of their ESCs you get to take advantage of their testing & quality procedures. The 6x VESC clones I ordered from JLC/LCSC are going to be a lot more questionable. Even the official Trampa VESCs lack ESD protection on the logical inputs, which isn't something I'd expect to have been left off. While I like the idealism of trickle down features it's yet to happen in any reasonable timeframe, I'm still waiting on field weakening. As for distributed testing I don't think testing the basic features loads really finds any of the edge cases where you'd actually need reliability.
However I believe OP was hoping to avoid purchasing a very large VESC and getting away with paralleling two cheaper VESCs together to achieve a similar current rating. As as been previously stated, this might be possible with brushed ESCs, but unless your motor has 6 separate phase wires you cannot do it with brushless ESCs like the VESC.
However I believe OP was hoping to avoid purchasing a very large VESC and getting away with paralleling two cheaper VESCs together to achieve a similar current rating. As as been previously stated, this might be possible with brushed ESCs, but unless your motor has 6 separate phase wires you cannot do it with brushless ESCs like the VESC.
Agreed 100%. It would be feasible to have two motors driving one chain, belt, or shaft, but requiring perfectly synchronized ESCs sounds like a disaster waiting to happen. Apologies for the confusion, I had thought you were responding to my question about redundancy, which is more of a backup board to swap in if the first board dies (without smoking the motor in the process).
I understand your point about trickle-down, but your proximity to the problem might mean you have higher expectations than many of us. For me, the ability to get hardware which can potentially control 10-20kW for under \$500, possibly as low as \$200, is revolutionary. It opens up whole new doors of testing into the product which is the single biggest weakness of any electric drivetrain.
@scootnorm, thanks for this! I'm 99% sure that the reason the youtuber so trivially gets two power stages working simultaneously is because there's only one microcontroller. The microcontroller will have one PWM timer for the entire output module. This means that everything stays perfectly in sync, with the only difference in timing being due to trace length and internal FET delays. These clock deviances are likely very fast-- on the order of nanoseconds, which is trivial in face of the overall switching frequency of 10-100kHz.
This raises the question if, in fact, two identical ESCs could be kept in sync by some kind of timing source. As I understand, the PWMs would have to be synced to a small fraction of the deadtime, which is currently ~80ns. So figure 20ns or better to be safe.
An alternative to an external sync source is to use an internal PWM from a master to drive a slave. The servo output port is driven by a PWM timer, so the board connections for this approach are already present.
That being said, this would be a modified version of parallelling multiple FETs, which is sometimes tricky.
Basicly, you could use Unity controllers for that purpose. Unity fw. has such a feature.
Actually, my thesis also is in that subject. It is succeeded about 10 years ago, and repeated on vesc design about 4years ago, and repeated on four stator bldc motor about more than 2 years ago, via a hw. solution. The project had been tested on real world conditions with a mini car (1000kg) having double stator 10Kw bldc motor. Once, one stator has been lost, and it had continued moving in reduced power (%50).
Correct me if I'm wrong, but it looks like the Unity controller does not have the feature to tie together multiple controllers. My read of the following link is that they tie togethe one controller and two output stages:
Another way could be to use SPI to transfer data between controllers with one acting as a master to calculate foc and other one to collect current measurements, send them to master and receive new pwm values to use. Also it probably needs another gpio pin to sync PWM start times.
Interesting idea for sharing the measurements. Would the main benefit of doing that be to have twice the processing power available?
probably needs another gpio pin to sync PWM start times.
It's not clear yet to me how to do this. The deadtime is 70ns, which is 14MHz. Not so coincidentally, I bet, the VESC PWM timer runs at 14MHz. So basically there is no opportunity to sync them up programatically, since the smallest integer difference between the two timers is already the deadtime. Not good.
I did see that the VESC's servo-port timer can be driven externally, so the master could emit a 14MHz signal on its servo-port pin and the slave could use that to as the clock source for its timer. That would ensure they stay in perfect lockstep. However, I'm not positive that the PWM can be driven by a timer which has an external clock source. That needs to be answered and demonstrated before going any further.
I'm also unsure if it's wise to have a 14MHz timing signal so close to high current wires. If this signal got noisy and/or corrupted, the result could be instant frying of all the FETs. All it would take is being one cycle out of alignment and the deadtime window is completely out of sync.
Basically the answer is that you cannot connect one motor to two VESCs. Under some specific circumstances you can connect one motor to two outputs of one VESC, as described above.
Implementing the feature to connect one motor to two VESCs seems like a tremendous effort to get the PWM timing right. My feeling is that the gain is not worth the effort.
Even if it works for a minute, it will be very much unreliable. Just get a larger controller.
NextGen FOC High voltage 144v/34s, 30kw (https://vesc-project.com/node/1477)
If it is a 6 phase wire motor, you can do that. So basically two motors in one.
How about if we take this same problem but recast it as one of redundancy? There are many mission critical applications where it's worthwhile to have a second ESC which is idle and only steps in in case the the first ESC fails. Has there been any work in moving VESC in this direction?
The big problem is ensuring that both VESCs are in lockstep despite oscillator drift. The worst case scenario is that both VESCs drive oppositely, one trying to raise the common winding to VBAT, the other to 0V. This will release the magic smoke in at least one of the VESCs, so is less reliable than a single, properly specified ESC. A motor with six windings and 2 VESCs is the closest you'll get to this.
Honestly, if you're after reliability VESCs aren't really right solution, you wanna start hitting up companies like MGM Compro or Maxon or Faulhaber. The Axoim project have taken the basic VESC design and added an FPGA (amongst other things) to do a whole load of fault checking and shut the VESC down if anything looks funny.
We're getting a little away from the topic here, but I'll bite. I would argue that, to the contrary, firmware reliability doesn't come from closed-source companies. I've done open-source and closed-source firmware and the difference isn't in the skill, it's in the testing. Both domains have incredible programmers, and incredibly bad programmers. You can even get great product from bad programmers, so long as the product is very narrowly defined and purpose-built. The real indicator is whether there's a track record of the product being successful in a myriad of use cases. (Is that the case for VESC?)
MGM Compro is an awesome place with a great track record of being used from R/C cars to full scale aviation, and if money were no object then you could pay them to thoroughly test any new features you'd like. You could also pay for independent review of their source code, schematics, and BOM to make sure it is acceptable for your application. This would be the NASA grade solution.
But if your pockets don't run millions of dollars deep, VESC has a tremendous advantage when it comes to new features because you can implement them yourself, and they get tested across an entire fleet. If you have MGM make you a bespoke feature, that feature will likely not get rolled out to anyone else, and so it becomes a maintenance burden for everyone with you as the sole tester. Every esk8er who is successfully running the firmware is demonstrating there are no hard lockups or smoking ESCs, and if new features introduce bugs then those are discovered very quickly as well.
The nice thing about ESCs is that once a problem is solved, it's solved forever. That's not to say that it's easy, just to say that once that feature exists in VESC and is in use by the community the feature gap between commercial and open-source narrows permanently. Over a long enough duration, the feature gap goes in favor of the open-source project. We've been seeing this since the days of Linux and we recently are seeing it in drone autopilots where the market outside of small niche players is entirely open-source.
Of course, when it comes to hardware selection, this is another game. Even if you took MGM Compro's schematic and layout, you wouldn't get the same quality they do unless you did the same testing and manufacturing.
Reliability doesn't automatically come from closed source companies but as they're the only seller of their ESCs you get to take advantage of their testing & quality procedures. The 6x VESC clones I ordered from JLC/LCSC are going to be a lot more questionable. Even the official Trampa VESCs lack ESD protection on the logical inputs, which isn't something I'd expect to have been left off. While I like the idealism of trickle down features it's yet to happen in any reasonable timeframe, I'm still waiting on field weakening. As for distributed testing I don't think testing the basic features loads really finds any of the edge cases where you'd actually need reliability.
However I believe OP was hoping to avoid purchasing a very large VESC and getting away with paralleling two cheaper VESCs together to achieve a similar current rating. As as been previously stated, this might be possible with brushed ESCs, but unless your motor has 6 separate phase wires you cannot do it with brushless ESCs like the VESC.
Agreed 100%. It would be feasible to have two motors driving one chain, belt, or shaft, but requiring perfectly synchronized ESCs sounds like a disaster waiting to happen. Apologies for the confusion, I had thought you were responding to my question about redundancy, which is more of a backup board to swap in if the first board dies (without smoking the motor in the process).
I understand your point about trickle-down, but your proximity to the problem might mean you have higher expectations than many of us. For me, the ability to get hardware which can potentially control 10-20kW for under \$500, possibly as low as \$200, is revolutionary. It opens up whole new doors of testing into the product which is the single biggest weakness of any electric drivetrain.
@scootnorm, thanks for this! I'm 99% sure that the reason the youtuber so trivially gets two power stages working simultaneously is because there's only one microcontroller. The microcontroller will have one PWM timer for the entire output module. This means that everything stays perfectly in sync, with the only difference in timing being due to trace length and internal FET delays. These clock deviances are likely very fast-- on the order of nanoseconds, which is trivial in face of the overall switching frequency of 10-100kHz.
This raises the question if, in fact, two identical ESCs could be kept in sync by some kind of timing source. As I understand, the PWMs would have to be synced to a small fraction of the deadtime, which is currently ~80ns. So figure 20ns or better to be safe.
An alternative to an external sync source is to use an internal PWM from a master to drive a slave. The servo output port is driven by a PWM timer, so the board connections for this approach are already present.
That being said, this would be a modified version of parallelling multiple FETs, which is sometimes tricky.
Curious if anyone has experience trying this?
Basicly, you could use Unity controllers for that purpose. Unity fw. has such a feature.
Actually, my thesis also is in that subject. It is succeeded about 10 years ago, and repeated on vesc design about 4years ago, and repeated on four stator bldc motor about more than 2 years ago, via a hw. solution. The project had been tested on real world conditions with a mini car (1000kg) having double stator 10Kw bldc motor. Once, one stator has been lost, and it had continued moving in reduced power (%50).
skyline1970, that's really neat to kmow. Have you got any links to those works? I'd love to look at your thesis if it's online somewhere.
It is not readily available online by the time. If a could find an environment for the work, I am planning to submit a paper about it, near future.
Correct me if I'm wrong, but it looks like the Unity controller does not have the feature to tie together multiple controllers. My read of the following link is that they tie togethe one controller and two output stages:
https://forum.esk8.news/t/variesc-tool-sro/46097/2
The problem with tying together two separate controllers is keeping the PWM timers in sync so that there's no shoot-through.
For unity super parallel firmware required.
https://github.com/variESC/variESC_Tool/releases/tag/5.02
https://forum.esk8.news/t/variesc-tool-sro/46097
branches;
main build 5.02 jan21
ver3.01 jan21
dev build 5.02 jan21
s3p build 45.00.beta3 june21
Another way could be to use SPI to transfer data between controllers with one acting as a master to calculate foc and other one to collect current measurements, send them to master and receive new pwm values to use. Also it probably needs another gpio pin to sync PWM start times.
Interesting idea for sharing the measurements. Would the main benefit of doing that be to have twice the processing power available?
It's not clear yet to me how to do this. The deadtime is 70ns, which is 14MHz. Not so coincidentally, I bet, the VESC PWM timer runs at 14MHz. So basically there is no opportunity to sync them up programatically, since the smallest integer difference between the two timers is already the deadtime. Not good.
I did see that the VESC's servo-port timer can be driven externally, so the master could emit a 14MHz signal on its servo-port pin and the slave could use that to as the clock source for its timer. That would ensure they stay in perfect lockstep. However, I'm not positive that the PWM can be driven by a timer which has an external clock source. That needs to be answered and demonstrated before going any further.
I'm also unsure if it's wise to have a 14MHz timing signal so close to high current wires. If this signal got noisy and/or corrupted, the result could be instant frying of all the FETs. All it would take is being one cycle out of alignment and the deadtime window is completely out of sync.
Basically the answer is that you cannot connect one motor to two VESCs. Under some specific circumstances you can connect one motor to two outputs of one VESC, as described above.
Implementing the feature to connect one motor to two VESCs seems like a tremendous effort to get the PWM timing right. My feeling is that the gain is not worth the effort.