I have noticed that the response time of the SKR is quite slow, often it says “busy processing” and my commands dont execute until several seconds after I make them. (lowrider2)
This is particularly problematic for STOP and EMERGENCY STOP commands, which are so delayed that it could cause damage. Is this SKR board too slow for this application? I have an SKR board in my 3D printer that stops when I command it to. Any thoughts?
We’re not using real time boards, so any 3d printer based control board will lag. They’ll continue running the commands they have loaded into memory.
2 Likes
As Barry indicates, there is a queue of commands. Your emergency stop command must make it to the front of the queue before it is processed. How long that takes depends on the g-code being processed. If you are making long straight cuts or moves, it can take a really long time. If you are cutting on a curve, it can happen almost immediately. This has nothing to do with your specific board.
There is a fix for emergency stop. You can enable the Emergency Command Processor in configuration_adv.h and reflash your firmware. When enabled, it watches out for a few specific g-codes and executes them immediately. You are looking for this section in configuration_adv.h:
/** * Emergency Command Parser * * Add a low-level parser to intercept certain commands as they * enter the serial receive buffer, so they cannot be blocked. * Currently handles M108, M112, M410, M876 * NOTE: Not yet implemented for all platforms. */ //#define EMERGENCY_PARSER
Note I’m not sure under what situations you would get a “busy processing” message. It may just saying the queue is full, or this may be a different issue.
@jeffeb3: Out of curiosity, is there a reason that the emergency command parser should not be enable by default in the V1 maintained firmware? Unlike a 3D printer, emergency stops are pretty common in the CNC world…or maybe that’s just me.
2 Likes
The only reason I can think of to leave it off is that I don’t have time to test it.
There aren’t many people who would take advantage of it. But certainly, at least for the skr, I can’t imagine it having serious impacts.
Not sure if this is your problem, but after watching this youtube video
In the Configuration_adv.h
In Marlin firmware, I changed these 2 values & seems to be working without any problems so far.
#define BLOCK_BUFFER_SIZE 64
#define BUFSIZE 32
1 Like
Are there any side effects with enabling this option?
I saw this thread and thought it would be nice to enable this setting on my 3D printer, its a pain having to wait several seconds for a print to cancel if its failed or what not.
The only downside I see is it may take a little longer to cancel a print since the buffer is bigger. I am currently using klipper, but may go back to Marlin again & will keep that setting in there.
I just made these changes and flashed my firmware. I’ll report back any differences after running some cuts. Thanks for the suggestion
I thought the whole point of that Emergency Command feature was to make stops faster? Does it not just bypass the buffer as per the code comments above.
That is assuming it issues one of these Gcode when cancelling .
M108, M112, M410, M876
My setup is related to the way octoprint does the cancel command with a 3d print & it is probably going thru the buffer. I would think the Emergency Command would be instantaneous. Here is what octoprint shows when I cancel a print.
Changing monitoring state from “Printing” to “Cancelling”
Recv: ok
Send: N9 M108*35
Recv: // Unknown command:“M108”
Recv: ok
Send: N10 M117 [ ] 0%*6
Recv: ok
Send: N11 M117 [ ] 0%*7
Recv: ok
Send: N12 M84*44
Recv: ok
Send: N13 M104 T0 S0*19
Recv: ok
Send: N14 M140 S0*80
Recv: ok
Send: N15 M106 S0*83
Recv: ok
Yes one would think that. My solution is that I have everything (router, lowrider, and vacuum) plugged into a power strip mounted to the corner of the table. The power strip has a switch on it so I can kill everything quickly.
Also, another thing I noticed about the emergency stop is that if you use it, it kills power to motors, so the router will drop, but also I cannot use any commands afterward…the touchscreen is locked. So i have to kill the power to reset it anyway.
the main problem with this is losing the coordinates of the work
@geodave , Looks like its not using a M108 so most likely just goes into Queue. O well , not much we can do about it.
@APD , that’s a feature I like with my Chinese CNC, can hit the reset or Estop , instant stop and it still saves the coordinates (assuming no lost steps) . The controller is pretty dumb but works OK. Only have 4 stepper outputs and I don’t think its smart enough to handle dual steppers for the same axis so not really suitable for a Lowrider/MPCNC.
Yes, this is annoying. Marlin currently doesn’t have any way of handling the e-stop (and GRBL isn’t in a much better boat). But, in general, the line of thought goes that, if it’s bad enough that you’re hitting the Big Red Button™, your job is ruined already, and you’re trying to prevent further loss.
3 Likes