Pause bug 1.0.4

The same pause bug that others have reported is still present in 1.0.4.

After executing a tool change (which works great at this point) the machine will resume operation but after a few seconds it will pause. It has to be manually resumed. Once resumed it will work as expected until the next tool change where the problem once again occurs. Happens at every tool change so far. Just wanted to keep this visable while hoping for a fix. Thanks for great software!

1 Like

Following up on this:

  1. What toolchange strategy are you using (manual, ignore, code?)

  2. If code, what are your pre and post blocks?

Thanks,
Kevin

I’m using code toolchange strategy. the code is modified from what Neil Ferreri has shared.

Before change code:

%wait

%X0=posx,Y0=posy,Z0=posz

%WCS=modal.wcs
%PLANE=modal.plane
%UNITS=modal.units
%DISTANCE=modal.distance
%FEEDRATE=modal.feedrate
%SPINDLE=modal.spindle
%COOLANT=modal.coolant

G21 ;metric
M5   ;Stop spindle
G90	;Absolute positioning

G53 G0 Z-10
G53 X171.5 Y-200

%wait

after change:

G53 X0 Y-10
G53 Z-58
G91
G38.2 z-45 F100
G0 z2
G38.2 z-5 F40	;"dial-it-in" probes
G4 P.25
G38.4 z10 F20
G4 P.25
G38.2 z-2 F10
G4 P.25
G38.4 z10 F5
G4 P.25
G90

%wait
; Update Z offset for new tool
G10 L20 Z[global.state.TOOL_REFERENCE]
%wait

G91
G0 Z5
G90
G53 Z-10
G53 X171.5 Y-200
%wait
; Pause the program for cleanup (e.G. remove touch plate, wires, etc)
M0 ;ATTACH BRUSH AND TURN ON VACUUM
;Go to work zero at a SAFE_HEIGHT for Z
G0 X0 Y0
; Restore modal state
[WCS] [PLANE] [UNITS] [DISTANCE] [FEEDRATE] [SPINDLE] [COOLANT]
1 Like

I also still see an error after a pause in the “after” code block of a tool change. It happens after resuming the gcode file commands. You must press resume to start up the file again. This is the same as I reported in another thread.

I am now using the “Manual” method and some of Neil’s macros for the Carbide3D Bitsetter. This works for me.

Post Code Block that causes errors. (Doesn’t really do anything, just for testing)

G53 G21 G0 Z-1
G53 G21 G0 X-817.5 Y-401.625
G53 G21 G0 X-414.5 Y-300
G4P0.1
M0

2 Likes

after doing some testing this morning I’ve found a work around. If i remove the final M0 from my post code i dont get the custom message but the machine will return to the tool change position and wait for a resume. This is working fine for me.

So i’ve modified my post code to below:

G53 X0 Y-10
G53 Z-58
G91
G38.2 z-45 F100
G0 z2
G38.2 z-5 F40	;"dial-it-in" probes
G4 P.25
G38.4 z10 F20
G4 P.25
G38.2 z-2 F10
G4 P.25
G38.4 z10 F5
G4 P.25
G90

%wait
; Update Z offset for new tool
G10 L20 Z[global.state.TOOL_REFERENCE]
%wait

G91
G0 Z5
G90
G53 Z-10
G53 X171.5 Y-200
%wait
; Restore modal state
[WCS] [PLANE] [UNITS] [DISTANCE] [FEEDRATE] [SPINDLE] [COOLANT]

We’ll have some tentative fixes aimed at this in the next build, but I can’t recreate your issue consistently enough on my end using either of your post-toolchange code to be 100%. I’ll get an error about 1 out of 15 “attempts” to get it to happen.

We did notice that in some situations the sender was resuming sending the program before the post hook was 100% complete and have made some changes to prevent that from happening. This is something that could result in an error from the controller that SLabuta experienced and the “second pause” - the sender would send data until “full” but then the feeder would also try to cram the final G4 in. The order of operations should be more consistent now - the sender won’t resume until after the final G4 we add on toolchange completion is handled. I haven’t been able to recreate error 24/extra pausing since these changes.

We’ll probably look at a better way of splicing code into a running program for toolchanges in a future build since we have a couple features on the way that/already existing that could also use it. If manual mode/removing the M0/these fixes work for you in the meantime, that’s great.

3 Likes

yes no complaints after removing that final M0. However I’m transitioning to a new machine ATM (Shapeoko HDM) so I’ll see if there are any problems here.

Thanks for continuing to dig into this. Just as an FYI, I am running gSender on a low-power (J4125 Celeron) Windows 11 Mini-PC. So if there are timing issues, I’ll probably see them.

Good News! gSender version 1.0.5 fixed the issue with the pause command for me!

The “Manual” tool change method still works when using Neil’s Macros and both the Manual and Code methods show the needed tool number now. Perfect!

Thanks!

2 Likes

That’s great news however after omitting that final M0 from my code i don’t know if I’ll bother adding it back. I’ll check the new functionality and see if any modifications are needed.