There actually is no integral loop on the speed loop at all by default, it has an integral term implemented but by default it’s zero and just a pure proportional controller (most applications don’t really need an integral term on the speed controller since there’s usually some outer loop such as a flight controller, human-in-the-loop, etc. so some proportional error is not a relevant problem). This problem still exists even when the integrator is disabled. All the integrators do have wind-up protection.
In this case, it’s the slew-rate limited input command request that gets saturated beyond the motor’s max speed which is a feed-forward calculation not an integral control loop. There are possible solutions to improve this (may look at it some day but not a high priority upgrade), but it’s a bit more tricky than a basic integrator because there’s no easily calculable speed command to limit it to, other than perhaps using motor KV and DC voltage although I like to try to avoid things like that since if the user has a poorly measured or set KV it wouldn’t work right.
Good answer, thank you. It means the parameters were set ridiculous slow for the input signal slew rate. I use to set them on a kelly controller in an electric vehicle below 0.5s for a foot pedal with hall sensor to damp it. Is it possible to make this asymmetrical for control by humans? I like to reduce or shut down the power without further delay after a short qualified filter time and raise the power by a limited slew rate. Especially when the input signal returns to 0.
Yes, the default is extraordinarily slow taking seconds to reach a high motor speed. This is so that there is the highest chance of initial stability during spin-up in the auto-tune wizard. Most users would want to greatly increase the slew rate limits after setting up the motor.
It does have asymmetrical support, the speed loop section has independent slew up and slew down parameters, so you could have it slowly ramp up but very quickly stop when letting off. It also allows speed-dependent slew limits so you can have it slowly increase up to some low speed such as gently starting up to idle then have fast response getting up into the higher throttles.
Are you talking about synchronous rectification? Arc is always synchronous drive on the power stage.
If you mean freewheel as in zero torque, can’t really do that in speed mode since it’s always trying to maintain a particular speed but in torque mode, 0A command is effectively zero torque and the motor would just coast to a stop (or accelerate with no resistance if there’s external forces such as a vehicle going down a hill)
I am now using the ARC200 in my build it replaced the Trampa VESC6 that did not quite have the pop to deliver the power required for lift off.
The ARC200 is working great so far. Not very hot after use (mounted on water cooled bed), silent operation of the motor and some really nice settings options. I especially like the RPM limits settings that let you find kind of a sweet spot for your “top speed”.
`After speaking with our Arc200 engineering team, it sounds like this is something that will need to be addressed via a future firmware update. It has been added to the next firmware release changes to be addressed. I’m not exactly sure how the fix will be implemented but probably in the form of a log reset function in the GUI.
I don’t have an exact timeline but it sounds like the next update would be likely to be released in the next several weeks.`
For any of those that may be interested. I have now ordered a second ARC200 for another build. Thats how good it is. I have even been able to run mine with just a heatsink and without watercooling in a closed hatch for 25 minutes ride time.
I don’t know whitch plug to plug the end of the PWM primary cable into. PWM, Throttle , ENC then after that I don’t know whitch throttle input to select in the software.
I did build it for for the VESC but work with the ARC also since is has almost the same dimensions. Pic 
)
