2.9.10 - Spindle remains running on exit of linuxcnc if using MB2HAL RS485

[rodw-au]

This was unexpected for me but maybe others will disagree.
Controlling the spindle using Modbus RTU and mb2hal from a serial port.
If you issue a M3 S1000 (or any other speed) and then close Linuxcnc with the spindle still running, the spindle continues to rotate at that speed.

This seemed dangerous to me. I expected the spindle would stop rotating on a shutdown as that's a safety issue.

The solution was to unlinkp the Modbus control pin and setp it to an off state in shutdown.hal

This is not specific to mb2hal because when I controlled the spindle using a generic MODBUS RTU ethercat slave, the same thing happens.
I think LinuxCNC should globally disable the spindle on a shutdown without relying on shutdown.hal because the user may not notice this in his precommissioning tests.

[grandixximo]

You should connect your spindle and your drives, to a non modbus pin to motion.enable or motion.machine-is-on (can't remember exact pin name), Hal will drive it off on exit, and possibly you want something with a watchdog, that goes off when you are not connected to it anymore, this is the correct safety, you cannot rely on modbus or on shut down NGC commands, if the application crashes, the spindle should stop, if your computer power supply blows, the spindle should stop.

[rodw-au]

That actually won't work because the one Modbus register receives multiple commands including stop

I will need to experiment. I think the solution is to enable the estop terminals on the VFD and tie this to the estop circuit somehow and ensure the RS485 timeout watchdog is enabled in the VFD.

As you say, this is a safety issue and its not covered in our docs anywhere. I don't remember this being an issue on the last MODBUS spindle I set up. If it is documented, where should it go?

[grandixximo]

Modbus can't be the enable path, and this isn't specific to mb2hal. The VFD simply holds the last written control word forever; if LinuxCNC crashes, the USB dongle drops, or the app exits without shutdown.hal running, nothing ever writes a stop. shutdown.hal only covers the clean-exit case, so it's a nice-to-have, not safety.

The standard industrial split:

1. Fieldbus carries non-safety data only: speed reference, direction, status.
2. Run enable is hardwired. VFD estop/STO terminals go in the machine estop chain, independent of any comms.
3. VFD comm-loss watchdog as the intermediate layer. Nearly every VFD has a Modbus timeout parameter with a fault/coast action. Set it to a few hundred ms and a crash, exit, or unplugged cable stops polling and the VFD faults out. This alone covers your scenario.

For the single control-word register problem in your screenshot: don't send run via Modbus at all. Most VFDs let you split the sources, run command from terminals, frequency reference from RS485. Then a hardwired FWD/ENA terminal driven by motion.spindle-on (or machine-is-on) gates the run and Modbus only sets speed.

I agree this should be documented. Nothing about it exists in the mb2hal or mesa_modbus docs today. I'd put a short safety section in docs/src/drivers/mb2hal.adoc covering the three layers above, with a pointer from the mesa_modbus page.