Inconsistent behavior

Exerqtor

@exerqtor
And this is the my "print_end.g". The only thing that gets ran when the print finishes:

; print_end.g
; Called when ending a print
; used to configure printer does after a print ends, gets canceled or stopped
;
G91											; relative positioning
M83											; extruder relative positioning
G1 E-5.00 F1000										; retract 5mm of filament
G1 Z1.00 X20.0 Y20.0 F20000								; short quick move to disengage from print
G1 Z10.00 F20000									; move Z-Axis 10mm away from part
G90											; absolute positioning
G1 X340 Y340 F9000									; move gantry close to home
M140 S0											; turn off heatedbed
T-1											; deselect all tools and set them on standby
G10 P0 R0 S0										; Set active and standby temps for T0 to 0 degC
M107											; turn off the print cooling fan
M84											; disable steppers

Phaedrux

@exerqtor said in Inconsistent behavior:

No i haven't, do you see something fishy in my meta gcode commands? Or are you asking just to rule it out as a posibility??
Nope haven't tested in 3.3 either. Was hoping for 3.4 stable to get released before christmast lol

Yes just trying to narrow down where the problem may be. I think another 3.4 beta is in the works.

Exerqtor

@phaedrux Tried with 3.4.0-b7 now in hope that something had changed there. But the issue has followed over to beta 7 as well..

But we can agree that it's a bug in the FW and not some weirdness with my gcodes/meta commands right? I mean if it had been something wrong on my end it shouldn't have worked after a reboot right?

What I think is so strange is that it happens somewhere in the job that no custom gcode or anything is supoosed to be injected.

gloomyandy

@exerqtor Do you have macros to handle filament change? Might be worth posting those if you do (as you have M701 and M703 commands in your gcode).

The video looks to me as if somehow your X,Y moves are in relative mode rather than absolute at the start of the print. You could try editing the gcode file and inserting G90 just after the M703 and check to see if that fixes the problem? If it does then you/we need to work out why/how it is in relative mode at that point.

Exerqtor

@gloomyandy

Unless RRF inserts G91 somewhere on it's own it shouldn't be the case.

My filament macros don't do anything atm since i haven't gotten to the point where i've done any filament specific tuning yet.

But here:
load.g:

; filaments/PETG/load.g
; called when M701 S"PETG" is sent

M118 P0 S"PETG filament loaded"
M118 P2 S"PETG filament loaded"

config.g:

; filaments/PETG/config.g
; called when M703 is sent and PETG is loaded
; Message
M118 P0 S"PETG config applied"   ; Send message to DWC
M118 P2 S"PETG config applied"   ; Send message to PanelDue
; Pressure Advance
;M572 D0:1 S0.0	
;M118 P0 S"Pressure Advance disabled"
;M118 P2 S"Pressure Advance disabled"
;M572 D0:1 S0.4
;M118 P0 S"Pressure Advance set to 0.4 seconds"   ; Send message to DWC
;M118 P2 S"Pressure Advance set to 0.4 seconds"   ; Send message to PanelDue
; Travel & acceleration
;M204 P800 T3000                      ; Set printing and travel accelerations (mm/s²) 
;Cancel Ringing (Ghosting)
M593 P"none" F50                          ; Cancel ringing at 50Hz
;Retraction & Zlift
;M207 S3.000 R0.000 F2400 T1500 Z0.100 ; Set firmware retraction length, extra un-retract lenght, retract speed, unretract speed & zlift (var 3600)
;M207 S1.000 R0.000 F2400 T1500 Z0.100 ; Set firmware retraction length, extra un-retract lenght, retract speed, unretract speed & zlift

unload.g:

; filaments/PETG/unload.g
; called when M702 S"PETG" is sent

M572 D0 S0.0 ; Disable Pressure Advance
M118 P0 S"Pressure Advance disabled"
M118 P2 S"Pressure Advance disabled"

M118 P0 S"PETG filament unloaded"
M118 P2 S"PETG filament unloaded"

As you can se it don't do nothing other than spam with messages atm

gloomyandy

@exerqtor I still think it is worth adding the G90 to see if that fixes the problem. That way we then know that operating in relative mode is the problem rather than something else.

Exerqtor

@gloomyandy But I do have G90 allready, it's in print_start.g, and as you can see from print_purge.g it is running in absolute and not relative. If it was in relative it would have tried to do the purge line on top of the nozzle probe instead of moving to the front where it does the purge line.

And print_purge.g don't contain any G91 either. But sure i can put G90 at the end of print_purge.g just to be on the safe side. Just can't see how it should help anything given where / how the printer shits the bed

gloomyandy

@exerqtor Don't put the G90 at the end of print_purge.g. It may be that the macro calls are saving and restoring the relative/abs mode or that something else is screwing it up. By putting it as close as possible to where we think it may be wrong we can be more sure that something else is not screwing with it (like the filament change code for instance).

But your call, that's just what I'd do...

Exerqtor

@gloomyandy Yeah I get your drift, i forgot that the "custom filament gcode"came after print_purge.g. But it's still weird that it works if i reset the machine, my reasoning is that it should be broken every time if the issue was that G90 came to "early" if you get my train of thought?

gloomyandy

@exerqtor I really don't know, it may be that the second time the filament change macro is run it knows what filament is installed and that makes it do something different. There is also stuff like the toolchange handling that may be slightly different the second time around (your end code deselects all of the tools). I'm just trying to find a way into understanding what the problem may be and identifying it as a problem with absolute/relative mode would at least move things forward a bit. Should be easy to test if you just create a very minimal test print file.

rjenkinsgb

@exerqtor
Do you have an M207 retraction setup line in your config?

On my new machine, I saw some very strange effects to start with and I believe they were linked to the slicer being already configured for firmware retraction, while in the newly generated config file I use in the new build, I did not have an M207 set up.

I can't be 100% sure that was it, but all the strange positioning stuff (Z axis in my case) vanished after some config tweaks that included adding the M207 line.

Also, what happens if you move the axes around manually after a print has completed - do the positions show correctly on the panledue & DWC??

Exerqtor

@gloomyandy said in Inconsistent behavior:

@exerqtor I really don't know, it may be that the second time the filament change macro is run it knows what filament is installed and that makes it do something different. There is also stuff like the toolchange handling that may be slightly different the second time around (your end code deselects all of the tools). I'm just trying to find a way into understanding what the problem may be and identifying it as a problem with absolute/relative mode would at least move things forward a bit. Should be easy to test if you just create a very minimal test print file.

Slow reply with christmas and all what that brings. But I threw a G90 at the verry end of the custom filament gcode in SuperSlicer and it actually seems like it's working now. Still can't see any logical reason for why this should be needes though

Inconsistent behavior

Robert J.