RRF 3.4.0beta7 resume bug when using arcs

EducatingSavvas

Hi - I think I've noticed a bug with RRF 3.4beta7 - after resuming from a pause the job doesn't commence. To make this complicated I am testing an external trigger which I am using as a door enclosure interlock for a CNC machine. Pausing using the web interface and the external trigger seem to cause the same response while resuming. The status of the machine goes from resuming to processing but there is no movement. This isn't an issue with RRF3.3.

The door external trigger is defined as such in the config.g file:

M950 J5 C"e0stop"		; use e0stop for input j5
M581 T5 P5 S0 R0		; T5 trigger active-to-inactive edge at anytime

Condition2.g looks like this:

while sensors.gpIn[5].value=0
	M291 S2 R"Enclosure Door Open" P"Close the door and press OK to continue."

Trigger5.g looks like this:

if state.status == "processing" & sensors.gpIn[5].value=0
	M25				; Pause

My start.g file looks like this:

M98 P"Condition2.g"	; call condition2.g to check enclosure door pin

My pause.g file looks like this:

G91				; relative positioning
G1 Z5 F500			; slowly move z axis to safe location clearing material
G90				; absolute positioning
M5				; turn off spindle PWM & spindle enable
G53 G1 F1000 Z129		; move z axis to safe z

And resume.g file like this:

M98 P"condition2.g"	; Call Condition2 to check enclosure door pin.
M3 R1			; Turn on Spindle Enable
G4 S1			; Dwell to give time for spindle to reach speed.

EducatingSavvas

Just double checked this again with 3.4 Beta 7+7, this time without the enclosure door code. I also removed the daemon.g file which controlled some LED's but the resume after a pause between jobs is still very long - almost unresponsive. With RRF3.3 I sometimes get long resume waiting time (up to 10 seconds) after a pause mid job. I'm not sure if this is because my post processor uses gcode Arcs.

I'm not sure if @dc42 is aware of this issue?

jay_s_uk

@educatingsavvas have you added a small segment setting to your config?
Try M669 T1 S1. That splits the moves up into small segments and should allow you to pause more quickly

EducatingSavvas

@jay_s_uk said in RRF 3.4.0beta7 resume bug:

M669

Hi Jay - I have it m669 in the config file already, as such:

M669 K0 S1 T3

The pause occurs pretty instantly but resuming takes a long while with RRF3.3 and even longer with RRF3.4beta7+7

jay_s_uk

@educatingsavvas ah, my bad then. I can't say I've had any issues resuming with the last 3.4 betas I've used but I'm not really doing anything complicated

EducatingSavvas

@jay_s_uk I'll try adjusting my post processor to not use Arcs and see if that is the issue - I seem to remember that was an issue with older firmware versions. I have slimmed everything down for the current CNC controller, so not sure what is going on.

This is a video of the resume dwell using RRF3.3 https://youtu.be/V2cP_cfPh40 - it is much longer with RRF3.4beta to the point that I normally cancel the job.

EducatingSavvas

@jay_s_uk I can confirm the use of arcs in the gcode seems to be the problem. I removed any lines referring to arc moves from the post processor and the long resume time has stopped with RRF3.4. But this now means the Gcode files are really large.

jay_s_uk

@educatingsavvas one for @dc42 to take a look at

dc42

@educatingsavvas thanks for pinning this down further. This was already on my list to investigate and resolve before we release 3.4.0rc1.

EducatingSavvas

@dc42 Please let me know if you want me to test anything.

dc42

@educatingsavvas I confirm this issue and I am working on a fix.

dc42

@educatingsavvas which Duet do you need a firmware build for?

EducatingSavvas

@dc42 Morning, I'm using a Duet 2 Wifi.