I see the trapezoidal waveforms have been removed. I was going to try them because I have a PMSM type motor that I need to run smoothly and was hoping it might work better.
I tried setting the mode to trapezoidal anyway using a snippet of old code from way back and it completely fried the board. It’s bricked. Just so others are aware of that possibility.
Trapezoidal does have it’s uses, is there a way to get simplefoc to produce trapezoidal, I need the smoothingsensor though so I might not be able to roll back to a previous version. Maybe there is one that has both… It’s sad to see regression in the feature list though.
It’s still there, in setPhaseVoltage around line 500 of BLDCMotor.cpp. It is actually a square wave though, not a true trapezoid. I don’t know if anyone ever uses a true trapezoid with ramping voltage between the sectors, but it would be fun to try implementing and see how it performs. I’d actually do a wavetable modulation mode, where you can create any waveform you like. I guess since we already use a lookup table for sine wave, it would just be a matter of swapping out the table that it uses.
Interesting idea with the wave-table modulation. I guess the “wavelet” would have to be continuous at the ends for things to work out well… otherwise I guess one could do it like you say, except that we’d probably need a separate LUT since the sine/cosine one is also used for the trig functions.
Regarding the trapezoid with ramping voltage, you can actually already achieve such waveforms (approximately) by using the voltage limits and overmodulation to give the sine waves flat tops…
If the table is a quarter wave, it would naturally prevent discontinuities and be able to use the sine code as-is, just making the table an argument to the function. That would make regular sin/cos a few cycles slower, though.
I’m not sure if there would ever be a situation where you’d want an asymmetrical waveform.
I think an assymmetrical waveform might actually be useful for cogging, though. The magnet gives a positive torque when approaching the pole and then a slight negative one when moving away from it. So you’d want to bias the torque, but I don’t know if a sine wave would also work to do that. I like the idea of leaving the symmetry of the waveform to the user. More flexible. I can always write a quick python script to get something that meets up at the ends as described but otherwise does as needed.
I could even forsee changing it during run time, using a separate system to adjust it, measure the vibration, and repeat, finding whatever waveform gives the lowest vibration. The vibration may be caused by the lower levels of the actual program, I think, at this point, making it pretty arbitrary. the frequency of the hum doesn’t even seem to scale linearly with RPM. Being able to adjust the waveform arbitrarily might be a reasonable way to solve it. Theoretically. Just saying wacky waveforms probably have their uses.
That’s also an interesting idea, but it would depend on the cogging always being the same for all teeth and poles… in practice I am not sure it is so symmetrical, and so you need a cogging LUT that goes over a full physical revolution, forwards and backwards, and not just 1/4 of a sine wave worth of data…
Well you can do something that mostly works and then do more detail later, but I have found cogging is not that consistent yeah. Just saying that cogging might actually be a case where just mirroring a waverform in various ways would be less than ideal.