Solenoid control: Max Acceleration/Deceleration [ Edited ]

In order to control a Solenoid, we need to have an ON/OFF-ish control. Meaning

• As close as possible to instant Max-Acceleration (0 to 1000)
• As close as possible to instant Max-Deceleration (1000 to 0)
and
• Allow sometimes a quick "0 to 1000 to 0" within ~0.1 second

However, despite the many configuration tests, the best we could reach was ~0.3 second for 0 to 1000 (or 1000 to 0), without loss of power (i.e. the Acceleration / Deceleration seems to be too slow to accommodate such speed).

Which makes the whole trip [ 0 → 1000 → 0 ] within ~0.1 second an unattainable dream...

This is the configuration we set in an attempt to minimize the time it takes to go from 0 to full power, and reversely 1000 to 0.

*Tried many values to make the min to max accel as large as possible, and "32" seems to be the best...

Please suggest any hint that could improve the current configuration to reach a fast 0 → 1000 and 1000 → 0.

A max rpm of 32 and acccel/decel of 3200.0 should maque the pmw go fro 0 to max un 32/3200 = 10ms.

If acceleration is slower than this, it may be because the amps limiting is kicking in. Set the limit to max. Monitor the motor current in roborun to see if it comes close to the limit.

Theoretically.

Practically, the best results are obtained with

^MXRPM 1 32
^MAC 1 32000
^MDEC 1 32000

But having less than 70ms between 0 → 1000 and 1000 → 0 and the solenoid clearly doesn't have time to get to full power before the controller starts the descent from the 1000 → 0 order*.
The round trip is still away from 0.1"

!G 1 0 → order takes a few ms (1st 0 is because the solenoid may be activated)
~70ms wait~
!G 1 1000 → order takes a few ms
~70ms wait~
!G 1 0 → order takes a few ms
(takes about 0.3s)

*Note Orders are !G 1 1000 / !G 1 0

Also the apparent best setting ^MXRPM 1 32 is interesting to say the least.
The all mysterious and magical value "32" fits better, but setting 20 or 40 and the solenoid behaves less efficiently. Strange...

Question 1: In this regard, since the internal source code is not available, what values / "hacks" ... would allow the controller to act more like a switch zero / full power.

Then regarding the Amps.

The solenoid is rated DC 12V 5Ω (i.e. 2.4A max), thus setting the controller to 4A max should be enough (right?)
However, as you wrote it, setting the controller to 500 (50A) improves the performance @70ms (while actual current input is 5A)... However under ~70ms, same problem.

Question 2: The input is limited to 5A for security reasons - would you recommend to plug higher than that? Would that make sense? (I don't think so)

Amps consumed by the motor is consistent with the solenoid rating: ~2.5A when full power.
However, when tested in a loop (see the bottom of this page) under ~70ms, it seems indeed the controller cannot keep up with the speed, and, in such a ON/OFF loop, tends to be unable to load quickly enough to supply the 2.4A within, say, 50ms.




Edit Note: to reproduce a similar situation try to loop

while ( true ) {
!G 1 0
~wait X ms~
!G 1 1000 → order takes a few ms
~wait Y ms~
}

Have X and Y vary between 10~100ms, you'll see that below ~70ms, the controller has a hard time trying to produce enough power to reach 100%, while - according to the acceleration 32/32000 and the specs - that has to/should/must be possible...
[70ms is actually 70ms + time to send/run a command on the controller - which is more than 100ms total]

we should take the solenoid out of the equation to start. Current limitins, and remanent magnetism may affect how fast the solenoid actually activates/deactivates.

One way is with this simple script:

top:
print(getvalue(_P, 1),"\r") ' print the applied PWM at output
wait(0) ; will repeat exactly every 1ms internal loop
goto top

clear the log
Launch the script from the console. Disable the serial watchdog with ^rwd 0. Send !g 1 1000 and then send !g 1 0

copy and paste the console data into an excel sheet so that you can view/plot

This will show how fast the PWM turns on/off with not restrained by current limit