Being following the thread and doing some testing with the beta versions I’m having some issues with PPM app.
I was thinking you guys might have a clue on this.
HERE IS THE SETUP:
I have 4 motors all connected together to the same shaft and all are running FOC (190kv BLDC sensored, using 12s battery).
Control mode is DutyCycle (can’t use current control as we need to precise control speed with and without load)
I have them all connected with CANbus using 4x HW6 from flipsky.
Master setting is with PPM, slaves NO APP and they run OK using PPM receiver. FW version I tested 4.2, 5.0, 5.1 and beta 5.2
HERE IS THE ISSUE:
If I pass 90 to 100% of the throttle (that reflect in above 86% of duty cycle), I have this repeatable behavior of having the motors giving a boost in speed (usually the slaves) and then locked at full speed. Sometimes it stops at about 4 to 5 seconds, other times I need to unplug power to make this to stop.
This happened to me before while using HW4.12 but it was random. Now I can replicate it and I can’t figure out the issue.
If I have the motors disconnected from the shaft (not all spinning together / mechanically locked together) this behavior does not happen in duty cycle
If I have the motors disconnected from the shaft (not all spinning together / mechanically locked together) this behavior happen if PID speed control is used
HW have 3 phase shunts, switching frequency is at 25khz,
I’m not using “sample in V0 and V7” an “High Current Sampling Mode”.
It’s a carrier to move loads, but the behavior is similar to a 4 wheel drive kart/sk8: if you take the wheels from the ground, no issues, as soon as you have all 4 wheels on the ground (locked motors together / common shaft) it happens.
I did describe it as locked motor shaft because it was the way I have to replicate the issues. It took me a while to understand why it only happens when the carrier was on the ground, as on the table, upside down, it never happens (as each motor can have their own rotation)
OK, so here goes the resuming of relevant results after a full testing day:
Combo A: Reducing the max duty cycle from 95% to 85%
Boost in speed: solved
Locked at full speed: not solved
Combo B: keep Duty Cycle at 95 and using only maximum 90% of throttle
Boost in speed: solved (it represents about 85% duty cycle)
Locked at full speed: solved
Combo C: keep Duty Cycle at 95, lower the switching frequency from 25khz to 20khz
Boost in speed: no effect (its really a thing with the max duty cycle)
Locked at full speed: seems to be even worst
Combo D: keep Duty Cycle at 95, activate both “sample in V0 and V7” an “High Current Sampling Mode"
Boost in speed: no effect
Locked at full speed: solved if throttle is pressed forward, not solved / random if throttle is pressed backwards
So, I’m not the best to make this assumptions or conclusions, but looks like frequency had some impact on the “lock at full speed” and it looks like it’s something that happens if the throttle is pressed full and usually are the slaves that gives the error and everything gets locked at full speed. Maybe related with the PPM app or canbus communications?
I think if I interrupt the canbus communication, the slave motors will be locked at full speed. Might this be something to look at?
Anyone have an ideas on how this can be addressed so the solution can be reproduced by others?
I did the tests with the duty_cycle_current_limit_start = 85%
If I disable the “sample in V0 and V7” and “High Current Sampling Mode”, I still get the motors locked at full speed
If enabled “sample in V0 and V7” and “High Current Sampling Mode”, it looks similar to have the duty_cycle_current_limit_start = 100%. It didn’t locked when going backwards (before it happens)
Looks like this locked at full speed is still not fully addresed. It might be interesting to see if other have same issue with different HW. I used HW4.12 and I can definitely see this happening as well (altough not so frequent).
Just to confirm I did all correct, here are the settings:
Aren’t you driving your motors with duty cycle mode ?
If so, duty cycle current limit shouldn’t apply. It doesn’t really makes sense.
But its implementation is maybe general for all modes.
I’ll try to see in the code how it works (when I catch some spare time).
Thanks! I really would like to find the route cause of this, but I’m not able to look into codding.
Just as food for thought, if I disconnect or quick disconnect/connect quickly the canbus wire while in full speed, it gets locked in full speed (I have snug connection, so it is not vibrations causing this).
But Might it be something related with this? I mean, on the FW routines some are processed before or not in the correct time, making it loose connection and keeps locked at full?
Hey guys! Any other ideas you might think that can help to solve this?
I’m still struggling to have this working without locking the machine at full speed and it seem I can’t find the setting that makes this work besides lower the duty cycle under 85%, as the diference to 95% makes a big difference in term of what we need.
Any comments or suggestion you might have will be really appreciated.
Thank you all again.
All i know is there was a weird fucky behaviour a while ago if you set battery amps higher than motor amps, but that was in current control mode (could be that they fixed current mode because people were complaining but didn’t look further)
Another theory is that at max erpm the esc is simply too queued up to respond to input changes, but that’s a loong stretch of imagination
Another thing to try is setting vescs at 30khz (adding v0/v7 at this point might be too much for the stm chip)
And cycling through can status message modes (default is 1_2_3_4) lower sends less info, so less to process. You find this in app config, general
Check the input, as well as measure the voltage the esc lets out in the 3.3v and 5v rails.
I’m out of ideas so far
That’s what I am wondering as well, especially as there are known settings like equal values of “max duty cycle” and “duty cycle current limit start” that cause reproducible and severe issues. Try it. The wheels lock up when they reach near max speed.
I understand that VESC gives the user a lot of freedom, but I would appreciate at least a warning from VESC tool.