Did anyone try a DIY Emergency Stop Button. I am not saying the emergency stop button hooked to AC power suppy.
I have a switch wired inline with the power cord that I use. Itās a standard computer power cord if you donāt want to ruin the original.
You could easily do the same thing with an actual āstop buttonā switch.
Cheap and easy to find on amazon or ebay.
-S
Same, I have my SM plugged into a wifi outlet (actually zigbee because iot security is a joke). Gives me a physical stop button, but I can also control it using the PSU control plugin in octoprint.
Note: if you turn off the power in the middle of a print, youāll probably need to level again. The only time I used the power in the middle of a print, the machine seemed to set Z0 to the height it was at when I turned off the power.
Iāve used this switch (" Router Table On/off Switch with Removable Safety Key") on a few devices - a portaband bounded to a SWAG table, a surge protector for a Taig mill and accompanying lights/DROs/etc, an old 7" Ammco shaper. Itās a great way to add a stop button without cutting up any cables.
I think the OP was asking about a software emergency-stop, however - one that stops the print but does not power off the printer.
ā¦and that may be why! Is this correct? I have hit the power button a few times when the print goes south, because it takes too long to do it through the touch screen (e.g. on Z offset screen, ESC back to the print-status screen, hit STOP, then hit YES IāM SURE DEMMIT, then wait for the controller to consider your request over coffee). Would explain why Iāve been having to tweak the Z offset manually so often.
If true, this really needs to be in the docs, as the Z offset is decribed as (and should behave like) a saved setting, not current-state.
Exactly, I just want this stop button on the touch screen to be a physical button and which works immediately and not ask for confirmation, especially in CNC mode. The snapmakerās official emergency stop button seems to do that but the delivery time is too long and costs about 100 dollars including shipping and customs to Switzerland.
As the firmware is opensource now, I think someone with correct competence and some spare time will definitely come up with a DIY solution.
AFAIU, the touchscreen source still isnāt released, so weāre stuck with using gcode to send commands to the device (if itās from e.g. octopi).
The problem with using gcodes to do an emergency stop is probably what @edf is touching on when itās āconsidering your request over coffeeā. It appears (maybe only w/ SM, I donāt have any other 3d printers) that the problem is that you have to wait for the last command to be finished before the printer will respond to a new code. So if e.g. you have some long ājam the head into the bedā code running, the machine wonāt process the next command you send it until it finishes the whole move (and if you did something like 100mm move, that can be a while).
This is why I just have my āoh sh*tā button thatās a physical button, I write software every day, thereās no way in hell Iām sticking with a software only solution when I start using the CNC machine.
I went quickly through the controller firmware on github. It appears that they are mostly using gcode to execute an emergency stop. To instantaneous execution of emergency stop gcode EMERGENCY_PARSER needs to be enabled. I guess they did the same for the emergency stop button. My test with M112 gcode for emergency stop from serial port with Luban was stopping the linear move but not exactly instantly and also needed a complete restart to get the machine working again.
Anyway I still did not see anywhere what and how snapmakerās emergency stop button exactly work.
The source code for the estop is quite small
It will be interesting to hear how the new emergency stop works in actual practice.
Hopefully everything will stop nearly instantaneously. If it doesnāt I would still want a physical switch that cuts power where I can access it easily.
-S
I thought itās this one.
That is what the controller does when it receives the stop command from the estop module. If someone wanted to build their own estop button (and integrate it into the SM ecosystem) it will need to based on the source code for the estop module
In tale it is, but not yet in practice. SM isnāt contemporaneously releasing source when they release new binaries.
Thatās one way to do it, and not the best. Itās the way Marlin does it, because that software originated on machines where CPU I/O directly controls all the peripherals.
On the SM machines, it would be far better to put an E-stop packet onto the CAN bus that talks to all the modules directly and bypasses whatever the controller is doing. The controller should listen for the same packet, of course.
2 Likes
So we have to wait until someone reverse engineer the estop module.
That explains why they are so slow in incorporating all feature requests from users. Itās very counterproductive for open-source software if the community can not contribute in real-time.
I hope itās arduino based or at least compatible. I will be happy to try making my own module which is not limited to just e stop.
It has been a while, but i did a bit of digging through the FW in the past (FW 1.8-1.9). As someone mentioned, I think the parser for the Emergency stop is through the CANbus, but of course, to activate the parser, you need to send the correct message to the correct address. I recall each type of module has a unique identifier, in which the controller checks upon boot up.
Canbus frames have a function ID and parameters. They are not like TCP/IP frames most people are familiar with with to and from addresses, there are no addresses in CAN, only frame IDs, which identify the function like Z Probe triggered, and associated parameters like probe On and Off.
The boot protocol starts with the controller putting on the bus a frame asking for all available functions. Each module responds with what functions it serves. The e-stop button would need to respond with the appropriate function ID. Then later, when the button is pushed, again put the appropriate frame on the bus.
The easiest way to understand the flow is to watch the startup log, which shows each response come in. Alternatively, use a CAN sniffer.
A CAN transceiver like this (https://www.amazon.com/gp/product/B00YO2GZ0O/) will allow control from an arduino or any mcu.
You would probably want to ask support to purchase an extra enclosure cable, as that is the 4 pin cable that you could cut up and use to get plugged in to one of the ports. Alternatively the toolhead/linear module cable type also has access to the CAN bus, and additionally has the step driver pins brought out.
1 Like
Thatās very insightful. Thanks Brent!
Iām also intrigued by these DIY module projects - I donāt find myself having a lot of time lately but Iāll help where I can. Iāve done a fair amount of AVR and Arduino development, Iād like to see a library get developed for the MCP2515 that would allow simple control of Snapmaker functions. Thatās something Iād love to help work towards.
I would imagine that library would handle all of the Init and communication functions that drive the CAN comms in the Snapmaker, and then development for a estop button would be greatly simplified. That would help some of my other projects that are ongoing as well.
For example, wrapping all of these constants in a library would make it much easier to create a new module:
1 Like
I donāt disagree with this, because having a full map of the machine is useful for any number of reasons. But e-stop is special. The ID should be global and always active, regardless of whether it registers itself at boot time. What you donāt want is code anywhere that checks whether e-stop is enabled and ignores a stop command if it hadnāt been explicitly activated.
Itās also the case that the controller itself should be able to issue e-stop, as well as any other module that cares to. Overloading the spindle motor, for example, would be a reasonable condition to stop the machine for.
Yea, agreed. Iām focusing on implementing a DIY version of the protocol already built into the controller firmware. perhaps you could start a GitHub issue and try to convince the developers to change the protocol so that itās more robust.
You may already have, I know I saw a similar comment from you somewhere else and it may have been on GitHub already.
Letās hope that it becomes more of a fail safe than what it is currently where it is treated just like a limit switch.