Is there a way to stop a mouvement ?

[Strophe27]

Hi ambrop72,

Something like M112 would be very usefull.

• I need an emergency stop for security reasons (but maybe it's better to to it with arduino's physical reset...)
• and really need to stop a movement, or find a workaround...

First, thanks 10^100 times for your great work here ! so nice movements and smooth stepper management... and this unique ability to choose what kind of axis per steppers and choose their endstops (it's why I choosed your firmware, and the reliability and softness is the surprise !)... I'm a very happy user

The context :

• I'm creating 4 camera rigs with pan/tilt/slider/follow focus/follow zoom (so called X Y Z A B in APrinter) for a theater show, and I will release my expandable work in open-hardware, and I will distribute the hex and json file made by your super web-based configurator (for 1 ramps 1.4 per rig).
• For the show's needs, the 4 rigs are driven from a WiP Max/Msp Patch within Ableton Live (to synchronise mouvements and light with the soundtrack).
• To finetune and record the positions, I use a gamepad with 2 joysticks. This is where I need to stop mouvements :
  • I would like to have 5 min (or 10+) speeds to move an axis, proportionally to the joystick state : start a very long move each time a new speed is reached, and stop when joystick is released. (It was the way I did when I used ConfigurableFirmata before APrinter, but it's a very scratch v1 stepper management, and V2 with AccelStepper is not released yet)
  • Maybe find a workaround... For the moment I send several little movements, and increase/decrease F on joystick move, but it's very hard to tune the delay between each micro movements, hard to not receive "Error:receive buffer overrun", and maybe because buffer, it's little too long to start, there is too much latency.

Maybe there is a M or G code I didn't find... But I tried all GCode given on RepRap Wiki to know better APrinter (and Gcode also because I'm very new in CNC and 3DP world).

Do you think is possible to add a 'ghost' M or G code with a Stop X Y Z A B somewhere in your code ? But first, is it possible for your firmware to manage incoming code while a movement is in progress ? If all 2 are yes, can you inlight me where is the best place to put what kind of instructions (I'm a professional copy/paster and test/hacker untill is work...) ?

Sorry for this long issue, you can quickly reply yes/no and I will do with that. My needs is just for comfort in creating, not for the hard job wich is working so good (very soft movements + video = :1st_place_medal: )

Thanks for all

[ambrop72]

Hi, Thanks for using my software. However there is currently no way to stop a movement, but I can possibly implement that.

• The software will currently always execute the planned motions. I could add a feature that will recalculate the plan in order to stop as soon as possible (i.e. decelerate as quickly as possible).
• The command processing is currently such that if you send a command but the planning buffer is full, command processing will be blocked until enough motion is executed that the new command from the same channel can be processed. This is unfortunate if the next command would be "stop motion". The workaround would be to send the stop command on a different channel (e.g. you're running a program from SD card and you send stop on the serial port, or you have two serial ports one for the program and one for control).

I can implement these things myself (I imagine it's not easy to understand those parts of my code), I've actually been planning that for some time. But you need to let me know if using two command processing channels will work for you or if we also need a feature to send a high-priority command on the same channel as the motion commands.

About your receive-buffer-overrun error, it is because you're sending too many commands at once and overflowing the receive buffer. A reliable way to avoid this is to keep track of the outstanding number of bytes send but not ok-ed, and never send a command if that would make the outstanding number of bytes more than the serial RX buffer size. (or a simpler approach: never send a command before the previous command is OKd).