Inconsistent behavior
-
I've got some weird inconsistent behavior going on with my printer. It's almost like it's doing "stuff" on it's own accord at times.
I can run a job, and it finishes without any issues from i press print. And if i either press "print again" (or what ever the exact words are on the PanelDue) or if i pick the same gcode from either DWC or via PanelDue and try to run it, it derps out in when it should start the print itself. It runs the "custom" part of the gcode it moves up to the point where the skirt line should start only instead of starting the skirt when it gets to where it should start it just keeps on going towards home (home on the high end of XY) and stops there and then starts to extrude plastic in a totally senseless mannor while at the XY home.
Then if i press emergency stop, and start the exact same job again, it will complete everything without a hitch, UNLESS the secound problem comes:
I've started getting random layer shifts!? Every belt, pulley and connector has been checked, re-checked and tripple checked without finding anything wrong.This also happens randomly while doing the same jobs/gcodes. First of i thought i had my travel speeds/jerk to high and that's what triggered the layer shifts. But that's since been lowered and it still happens from time to time..
Machinewise it's a Duet 2 Wifi v1.03 running CoreXY and the newest beta FW releases as of 14 December 2021.
Snippet of a job gccode:
; generated by SuperSlicer 2.3.57 on 2021-12-13 at 17:32:37 UTC ; ; external perimeters extrusion width = 0.40mm ; perimeters extrusion width = 0.40mm ; infill extrusion width = 0.40mm ; solid infill extrusion width = 0.40mm ; top infill extrusion width = 0.40mm ; first layer extrusion width = 0.42mm ; object:{"name":"WAGO_221-412_mount-2x2","id":"WAGO_221-412_mount-2x2.stl id:0 copy 0","object_center":[175.000000,175.000000,0.000000],"boundingbox_center":[175.000000,175.000000,6.100000],"boundingbox_size":[60.799995,22.250000,12.200001]} ; Total objects to print: 1 M486 T1 ; plater:{"center":[175.000000,175.000000,0.000000],"boundingbox_center":[175.000000,175.000000,6.100000],"boundingbox_size":[60.799995,22.250000,12.200001]} ;TYPE:Custom ; custom gcode: start_gcode ; Start G-code: START ; Set mesh probing area var minPrintX = 142.107 var maxPrintX = 207.893 var minPrintY = 159.382 var maxPrintY = 190.618 ; Set temps & the initial extruder set global.bed_temp = 85 set global.chamber_temp = 0 set global.hotend_temp = 260 set global.initial_extruder = 0 M98 P"/sys/lib/print/print_start.g" ; run print start routine ; Start G-code: END ; custom gcode end: start_gcode ; custom gcode: start_filament_gcode ; Filament-specific start gcode M701 S"CPE" ; Load filament for the active tool M703 ; Load filament config.g fof the selected filament ; Filament specific start G-code: END ; custom gcode end: start_filament_gcode ;LAYER_CHANGE ;Z:0.2 ;HEIGHT:0.2 ; custom gcode: before_layer_gcode ; Before layer change G-code: START G92 E0.0 ; Zero the extruded length ; Layer number 0 ; Z-height was 0mm before layer change ; Before layer change G-code: END ; custom gcode end: before_layer_gcode G1 Z0.2 F6000 ; custom gcode: layer_gcode ; After layer change G-code: START ; Layer number 1 ; After layer change G-code: END ; custom gcode end: layer_gcode G10 ; retract G1 X156.06 Y161.473 G11 ; unretract ; custom gcode: feature_gcode ; Feature: 0.4mm Skirt ; custom gcode end: feature_gcode --->THE POINT WHERE IT SHITS THE BED<--- ;TYPE:Skirt ;WIDTH:0.44 G1 F1200 G1 X143.628 Y175.614 E0.55951 etc etc etc etc.My "print_start.g":
; print_start.g ; Called when starting a print ; Used to configure print parameters G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion M220 S100 ; reset speed multiplier M140 S{global.bed_temp} ; set bed temperature G10 P{global.initial_extruder} R{global.hotend_temp} S{global.hotend_temp} ; set active and standby temps for the initial tool M116 ; wait for bed and hotend to reach there temperatures G32 ; level the bed while everything is hot G29 S1 ; load & turn on bed height map M376 H5 ; set bed compensation taper to 5mm T{global.initial_extruder} ; select initial tool M98 P"/sys/lib/print/print_purge.g" ; extrude purge lineAnd "print_purge.g"
; print_purge.g ; Called when starting a print ; Used to purge the nozzle G0 X90 Y10 Z0.3 ; Move X90, Y10 & Z0.3 G92 E0.0 ; Zero the extruded length G0 Z0.3 ; Lift bed to nozzle -0.3mm G1 X10 E20 F400 ; Extrude 20mm of filament in a 80mm long line (extrude 0,25mm pr 1mm) G92 E0.0 ; Zero the extruded length G10 ; Retract G1 X15 F4000 ; Quickly wipe away from the filament lineAnyone got an idea? I'm starting to lean towards a bug in 3.4.0-b6 to be honest
-
Have you tested without the meta gcode commands?
Have you tested in fw 3.3?
-
@phaedrux
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
EDIT:
Here's how it behaves/misbehaves:
Shitting the bed:
https://youtu.be/kWw6dNmZlWUWorking as intented:
https://youtu.be/Uc8p8-T5CXkNote that the only thing i did after pressing "STOP" was to let the board boot back up, then select the exact same file and press print ( i skipped filming the, heating, homing, bed traming etc. in both clips obviously ).
-
@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 -
@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 lolYes just trying to narrow down where the problem may be. I think another 3.4 beta is in the works.
-
@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.
-
@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.
-
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 & zliftunload.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
-
@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.
-
@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
-
@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...
-
@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?
-
@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.
-
@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??
-
@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
