It is possible that the limitation is not the firmware but the hardware. In the section of the manual(?) posted above, it states “With FOC, the Talon FX uses sinusoidal commutation to constantly energize all three phases.”
With trapezoidal commutation, the output transistors switch at the output frequency. With the sinusoidal waveforms used in FOC, the transistors are switched at a frequency much higher than the output frequency (often at least 10X) and PWM techniques are used to approximate the sinusoidal waveform. The higher switching frequency of the transistors when using FOC can lead to two possible problems.
In general, the switching losses are proportional to the switching frequency i.e. 10X higher switching frequency leads to 10X switching losses. The conduction losses would typically stay roughly the same. The total losses are what causes the heating of the transistors in the controller. It is not clear why the TI video indicates that the switching losses can be 3X since they don’t show the actual switching frequency used.
From the “Constant Current Test - Falcon 500” graph on the VEX website, it shows the Falcon 500 reaching the thermal limit at just over 250 seconds when run at 40A and around 112 seconds when run at 60A. This would mean it would hit the thermal limit sooner if using FOC when running at these current levels. How much sooner depends on the proportion of the total losses that are due to switching losses. If the conduction losses strongly dominate in this design, the time to thermal limit will not drop by much. If the switching strongly losses dominate, the time to thermal limit will probably drop a lot.
In either case, if they are unable to deliver on an advertised feature, they should not be lying to consumers and should communicate that. If it is “just” firmware, I wish they had not made liars of themselves.
Note: My response to this thread disqualifies me from moderating it. Others will handle it.
Much of your understanding about how commutation works is incorrect. Suffice to say that the switching frequency would not be any different when comparing FOC to trapezoidal communication. If anything, FOC will make the controller more efficient. In both trapezoidal and FOC commutation, the transistors are switched in the 5-40kHz range (typically) to produce throttles between 0 and 100%. That is, to generate 90% throttle, the high side MOSFETs have a 90% duty cycle max, while commutation is happening to modulate the 3 phases, reducing the duty cycle of each phase as needed.
The only hardware needed to support FOC is at least 2 phase current sensors, a decent encoder, and an MCU powerful enough to handle the computations within a tight loop time. Other than that, it’s basically the same as a trapezoidal motor controller.
I’ve been wondering for a while if they’d managed to architect themselves out of implementing FOC/implementing FOC well. Has anyone done a teardown of the Falcon 500 with the intent of seeing if FOC is possibly limited at the hardware level (i.e: due to poor/naïve design choices)?
Given that they have phase current sensing and a high precision encoder, and they’re able to run a fairly sophisticated CAN stack and control loops on top of that, I can’t imagine how they could have locked themselves out. But maybe all of those things ate up their spare computing power, and it would take a significant rewrite to fix?
As I stated in my last post, FOC will require running at a higher switching frequency to produce the sinusoidal waveform at the desired output frequency and this leads to an increase in heating. None of the FRC motor controllers have a lot of heatsinking. Quite a few of them have published graphs showing temperature rise at various load currents and none of them are able to sustain full rated current continuously.
Even if it looks like it has sufficient heatsinking, the actual switching waveforms may have a lot of ringing due to poor layout in the circuit board and/or poor circuit design. This can also increase the losses leading to greater temperature rise.
Can you cite a source for this? The VESC performs FOC just fine at 20kHz, which is probably close to what the Falcon uses (the Talon SRX switched at 15kHz).
Everything you’re talking about is the same for both 6-step and FOC commutation.
EDIT: I’m mostly wrong, apparently FOC needs to switch all 3 half bridges at all times, where 6-step commutation only needs to switch 1 high side and 1 low side fet at a time. But other factors can impact heat generation as well. Switching frequency isn’t as much of a factor though for any potential Falcon implementation if they’re already in the tens of kHz range.
The manual indicates that FOC is already here, when it is not:
In the trapezoidal control scheme, the output transistors switch at a frequency that is directly related to the motor rpm. This frequency will vary as the motor speed ramps up from (near) zero.
In schemes such as FOC that used sinusoidal waveforms, the frequency of the sinusoidal waveform is at the same frequency that it would be with trapezoidal waveforms for any given motor rpm. In order to have the sinusoidal waveform, the transistors have to switch at a frequency higher than the frequency of the desired waveform.
I am not familiar with the Falcons since none of the teams I have worked with has them. The controllers for the 3-phase AC induction motors that I have worked on in several of my jobs typically switch the transistors in the 2-3 kHz range to make sinusoidal waveforms that range from zero to 50 or 60 Hz.
I guess I’m missing something. Don’t the phase transistors have to switch all the time to regulate the output? Or is there a separate buck stage to reduce the voltage before the commutation?
Yes, they do, hence my initial confusion. The Falcon is likely already chopping in the tens of kHz range, because it needs to set the throttle lower than 100%. If we only ever ran it at 100%, we might get fewer switching losses, but that requires a special gate driver to do so. But switching 1 phase vs 3 is a LOT more heat to deal with.
The other is they “only” sense current using two shunts instead of three. My vague understanding is that more shunts is more better for FOC implementation.
The above also assumes the use of shunts for current measurement, as opposed to, idk, a hall effect sensor?
Anyone happen to know the processor / gate driver used in Falcon FX? If the manufacturer has not released a reference implementation of FOC, that would be telling.
These all use MOSFETs and the idea is to have these full on or full off, so they do not dissipate much power – transitioning between these two states can account for most of the power loss (heat generated). Having FETs with very low on resistance and a gate driver that can get charge on to and off of the gates very quickly is important. These parts have been making fairly rapid progress. Knowing the specific parts could help to constrain things.
I have, for the purposes of work demos, run VESCs at higher frequencies to “silence” motors at the expense of lower efficiency (or so I’d assumed). Still, this was on the order of switching from 20 khz to 25-30 khz or so.
My understanding is that the realm of usable switching frequency is motor-dependent and not commutation-type-dependent. Perhaps it was a fluke but I had to set switching frequency on a VESC to under 10 khz to get a gimbal motor to run.
On the surface, those parts seem to be up to the task. There could still be some thermal limit, depending on the MOSFETs, etc. But, I suppose when Falcon 500 first came out, it was not much of a stretch to expect this to be very doable. It’s very possible that it’s just a matter of getting the right F/W, but it’s also possible that there’s some gotcha. My guess is it’s the former case though.
They will work on FOC when their’s a business case for it. Right now, there is more demand for falcons then there is supply. So adding more features will not make them sell more Falcons. They should spend their money on other development that will increase revenue.
Who remembers the days of $150 PWM motor co trollers? That was disrupted by CTRE.
Once Rev or a brand new legal motor controller supports FOC, i think Falcon will get support pretty quickly.
Why on earth should they increase revenue instead of giving the Falcon features it has already advertised? Why is this at all acceptable?
If a supplier advertises a feature, I expect to have it. Dead stop, that’s the bare minimum I expect when I buy something. When I go to the supermarket and buy an orange, I expect to get an orange. When my washing machine says it has automatic clothing level detection, I expect to be able to presss a button and let it detect the clothing level automatically. This is the barest minimum for selling a product.
FOC has been used for advertising for 3 years and it’s still extremely ambiguous whether or not it’s a feature, let alone something they’re even working on. Roping new teams into buying into your ecosystem with lies is straight up wrong, especially when many teams won’t switch to NEOs because “Falcons already work”.
So no, CTR/Vex should not focus on new product lines. They should scrub FOC from all official documents immediately or supply it as a firmware update ASAP, as promised 3 years ago.
