Resume from pause doesn't respect previous feederate.

Zakm0n

So, I'm running a custom pause and resume macro, but when I resume from pause, the feedrate is out of control. My file's feedrate is 75, but on resume, my XY movements seem to be at rapids speed. Gcode is as follows:

Pause.g:
G60 S1
G54 (I work in G55)
G0 Z100 (machine limit)
G55

Resume.g
G0 R1 Z5
G1 R1 Z0 F75
G55 (just in case)

fcwilt

@zakm0n said in Resume from pause doesn't respect previous feederate.:

So, I'm running a custom pause and resume macro, but when I resume from pause, the feedrate is out of control. My file's feedrate is 75, but on resume, my XY movements seem to be at rapids speed. Gcode is as follows:

Pause.g:
G60 S1
G54 (I work in G55)
G0 Z100 (machine limit)
G55

Resume.g
G0 R1 Z5
G1 R1 Z0 F75
G55 (just in case)

Add F parameters to the G1 commands to set whatever speed you would like. F4500 would correspond to 75 mm/s.

Frederick

Zakm0n

@fcwilt

The only G1 in this sequence has F75 for 75mm/min (I'm fine tuning feed rate with the speed slider.) That should carry over to the program g-code on resume.

fcwilt

@zakm0n said in Resume from pause doesn't respect previous feederate.:

@fcwilt

The only G1 in this sequence has F75 for 75mm/min (I'm fine tuning feed rate with the speed slider.) That should carry over to the program g-code on resume.

The code in a print file usually has many, many F parameters setting the speed.

It's likely that any speed you set is going to be quickly overridden by those changes.

Frederick

Zakm0n

@fcwilt This is a CNC mill, so there is one F called early in the cut. Regardless, the speed this thing is moving is downright dangerous. Even if the next line had a F parameter called, the remainder of the cut move after unpausing could cause catastrophic damage. Like I said, at no point should there be anything other than F75 through a pause and unpause, but yet, I'm seeing close to F6000.

fcwilt

@zakm0n said in Resume from pause doesn't respect previous feederate.:

@fcwilt This is a CNC mill, so there is one F called early in the cut. Regardless, the speed this thing is moving is downright dangerous. Even if the next line had a F parameter called, the remainder of the cut move after unpausing could cause catastrophic damage. Like I said, at no point should there be anything other than F75 through a pause and unpause, but yet, I'm seeing close to F6000.

Sorry - I keep forgetting the CNC section is here in this forum.

Can you use M203 or M220 to limit the speed?

Frederick

Zakm0n

@fcwilt M203 is my rapids speed. When I use G0 to call a move at max speed, that's the speed it runs at. M202 is not implemented in the firmware. G1 and G0 are modal, meaning you only have to have one line with G0/G1 and then every following line can have just coordinates to go to, just like the F parameter. In the 3d printer world, modal is called sticky I believe. So either my problem is that the lines after resume are treated as a G0, because they don't have a G command at the start of the line, or the F parameter is lost and the max is used. Either way, the firmware shouldn't behave this way, especially since the G1 R1 Z0 F75 should have both the G1 and the F75 held over as modal/sticky

fcwilt

@zakm0n

Got it.

To see if the behavior is related to G0 could you, as a test, code pause and resume with only G1, using the F parameter to obtain G0 speed?

And that M202 was a typo - it should have been M220.

T3P3Tony

@zakm0n there was an issue with this in SBC mode in previous 3.4 betas that was fixed in the latest beta, if you are running SBC mode and an earlier beta of 3.4 please can you upgrade to 3.4b5 and see if the problem is fixed

Zakm0n

@t3p3tony Sorry, forgot to mention I'm on a duet 2 wifi.
@fcwilt I'll do that and report back

dc42

@zakm0n the move back to the original location from the place you moved the tool to in pause.g will be at a default speed; but when it resumes the job, it should go at the original speed it was using when the job was paused. Is that not happening?

Zakm0n

@dc42 No, it's not. It's resuming at top speed in the cut. Here is a snippet of the code I'm running.

G55
M8
M3 S6000
G00 Z20
G00 X13.0734 Y315.6128
G00 Z-5.08
G01 Z-7.62 F125
X13.0607 Y312.7553
X13.8151 Y312.8518 Z-7.6327
X14.5161 Y313.1464 Z-7.6454
X15.1155 Y313.6138 Z-7.6606
X15.5702 Y314.2234 Z-7.6733
X15.8496 Y314.9295 Z-7.686
X15.9309 Y315.6864 Z-7.6987
X15.8115 Y316.4357 Z-7.7114
X15.4965 Y317.1292 Z-7.7267
X15.0114 Y317.7134 Z-7.7394
X14.3891 Y318.1502 Z-7.7521
X13.6728 Y318.4068 Z-7.7648
X12.9159 Y318.4652 Z-7.78
X12.1691 Y318.323 Z-7.7927
X11.4859 Y317.9877 Z-7.8054
X10.9144 Y317.4848 Z-7.8181
X10.4978 Y316.8498 Z-7.8308
X10.2641 Y316.1259 Z-7.8461
X10.2286 Y315.3664 Z-7.8588
X10.3937 Y314.6247 Z-7.8715
X10.7493 Y313.9516 Z-7.8842
X11.27 Y313.3979 Z-7.8969
X11.9177 Y313.0017 Z-7.9121
X12.6467 Y312.7883 Z-7.9248
X13.0607 Y312.7553 Z-7.9375

chrishamm

@zakm0n Does a final G1 R1 at the end of the file fix it?

Zakm0n

@chrishamm like at the end of resume? To be clear, this is not the entire file, just the first couple lines.

dc42

@zakm0n remove the G60 S1 command from pause.g. I think that command is causing the issue.

Zakm0n

@dc42 spot on. It does exactly what I expect with that removed.