OK, I am Using Debian Linux and USB connection to SM A350T - so not a common setup.
If I try to “Stop” the CNC mid-job using Luban’s “Stop” button, the CNC runs for another 8 minutes then stops. Not great!
When the CNC apparently did not stop I tried the “Home” button on the LCD controller. This caused a catastrophic toolhead path, my SM2 tried to execute a “Home” without lifting the toolhead. See video here.
Similar behaviour also occurs when using the 3D toolhead. AND if I try to adjust anything on the LCD controller, the SM loses it’s temperature settings and randomly veers off course. I dare not try it with the laser!
Snapmaker support said… yes that happens, user interference - don’t do it!
Heads-up this is a bug and apparently will not be fixed.
Snapmaker will not continue “another 8min”. It will finish all commands it recieves until it gets the stop message. First in- first out. This is how the serial connection works. If you want to hard stop the job, use the emergency stop Addon or just interrupt the power. When snapmaker is off, lift the Z Axis (in the middle!) by Hand above your job. Then you can turn it on and Home again.
This is no “Bug". It is the documented behaviour. Check out the how tos and the serial connection explanation. Snapmaker has still few open bugs, but for me, this is none of them.
Sorry, you are wrong. Using the stop button in Luban is instant when using the 3D toolhead. It should be instant when using the CNC. Also, when the SM executed the Home command on the LCD, it performed the action out of sequence, homing the toolhead axis before lifting it. This behaviour is destructive.
Just a confirmation that if you have properly installed the emergency stop button, it really is an emergency stop that reacts immediately. Using stop from the touch screen interface may take a few more seconds, I’ve never seen it take anything over 3-5 seconds.
It depends in the previous command. When it is “Run this line for 30cm.”, it will lasts longer than on smaller lines. This is my observation. Same in prints. If you print big stuff, changing speed will last longer than on small parts. I thought that the previous commands get in a Queue and handled one by one. And you just add the Stop command after others.
I have an emergency stop button, that works great thanks. However it is Luban’s on-screen “Stop” in the Job Status area. This does not respond consistently between toolheads. It does take 8 minutes to stop the SM2 CNC, but stops the 3d toolhead within seconds.
BTW, none of the modules seemed overly hot and this behavior is consistent. It seems the only way to avoid it is through user - procedure. Don’t touch the LCD controller once a job has started and don’t expect Luban to stop the SM in a timely manner.
Hey sorry for the confusion there are two conversations going on here. Although similar in nature, my problem covers a broader issue. I probably should have started a new thread.
I would agree with @Wyphorn: Emergency stop button and Luban or Touchscreen Stop work differently, and this causes differences in the behaviour:
The emergency stop button is monitored separately from the print job by its own piece of software. As soon as it is hit, the shutdown procedure kicks in and the machine goes dark.
The Stop from Luban or Touchscreen interrupts the sending of GCode commands to the controller, and instead sends the GCode for the stop procedure, i.e. switch toolheads off and move them away from the workpiece.
However, the general concept is that the touchscreen controller feeds GCode bit by bit to the Marlin controller, which in turn processes the GCode. There is a bit of caching/pre-sending happening to allow the Marlin controller to work efficiently, i.e. when the stop procedure is initiated, the Marlin controller still has a few commands in its queue to process. Usually these are short moves, and the total execution time is sub-second, making it look like stop happens instantly. If however, like Wyphorn said, there is a single GCode command in the queue with, e.g., a long, slow move that takes 10 seconds, then the stop will only happen after 10 seconds.
So the working hypothesis would be that the GCode commands you send in your 8-minutes-problem-video contain one or a very few GCode commands that take 8 minutes of processing time and are still in the process queue of the Marlin controller before the Stop-Gcode is processed.
Long story short: If you want to play it safe and have an immediate stop option, either use the Snapmaker Stop button, the self-made stop button by Ronin, or a simple mains-side switch that cuts mains power, like a power socket strip with a switch, or use the power switch of the power supply.
Once again, thanks to xchrisd, Hauke, and Wyphorn for your feedback and suggestions. You guys are legend for your knowledge and commitment. Thanks also for moderating the new thread. I’m not too worried now I understand the problem, but it does require knowledge and discipline on the user’s part. I couldn’t find much about this problem when I searched before, so I’m happy to see it in search results now. Please note, this is not a rant at Snapmaker who were thorough and helpful during last week’s diagnosis.
