STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard

[SputnikOC3d]

STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard - errors - print halts

Duet Mini + 5 | 1LC toolboard 1.1v | Voron 2.4 | Prusa Slicer 2.3.3/2.3/2.20 | SuperSlicer also

So ... Im getting an erron from the CAN Bus toolboard that I had initially and stupidly ignored as not the issue but I think Ive tracked it down - to it being related to my root issue here. What happens is the print slices and can start as a normal print would - but after the purge strip gcode I created in my slicers custom start.g [ see below ] - the slicer's - all of the above - append or pre-pend their own BS to the start and end, and I cant sort out how to A. make it stop or B. inject proper gcode into my start.g to make them play nice with the Toolboard and the needed gcode to resolve the mystery error and print halt.

The toolhead just sits at the end of the purge strip in a perma M116 condition at print height and temps ... and cooks filament and my bed surface until I hit EStop button [ PAUSE Print and all other commands at DWC fail to execute ]

My Start.g

;Start GCode DasVoron2.4 - as of 8-30-2021
;Print Area is X10 Y10 to X285 Y285
G21												; set units to millimeters
G90												; use absolute positioning
M83												; relative extrusion mode
M140 S[first_layer_bed_temperature]				; set bed H0 temp
T0												; set Tool 0 to proper tool to get this started
M568 P0 R175 S[first_layer_temperature_0] A1	; Sets Tool0 /Nozz/ 1st layer Temp / Standby Temps | Sets Tool0 to Standby
M561											; Disable ANY and ALL Mesh Bed Level Compensation
G28												; home X / Y / Z  w/out mesh bed level
G29 S1 P"/sys/heightmap.csv"					; Load and use latest heightmap for Mesh Bed Compensation | heightmap.csv is Default/latest 
G92 E0.0										; reset extruder distance position
G1 X5 Y5 Z20 F5000								; go to Steve's Dribble Zone and wait
M190 S[first_layer_bed_temperature]				; wait for bed temp
M116 H0 S12										; RRF3 - Waits for H0/Bed to get within 12*C | S5 Param | of Set Temp Above
M568 P0 S[first_layer_temperature_0] A2			; Sets Tool0  /Nozz/  | S - to 1st layer Temp | A-Sets Tool0 to Active /0-1-2/ 
M116 P0 H1										; Waits for Tool0 / H1 Heater 1  Nozz  to get to get to Print temps in M568 above
G1 Z[first_layer_height] F3000					; drop to 0.24 print height
G1 X5 Y5 F3000									; move to purge strip start position
G1 E10.0 F140									; puddle from Tilley Test
G1 Y60.0 E9.0 F1000.0							; intro line 1 from Tilley Test
G1 Y100.0 E12.5 F1000.0							; intro line 2 from Tilley Test
G92 E0.0										; reset extruder distance position

Slicer's generate this or similar variant. Of Note the G10 S215 followed by M116, which I believe is the offending Gcode in this scenario.

M107
G10 S215 ; set temperature
;TYPE:Custom
;Start GCode DasVoron2.4 - as of 8-30-2021
;Print Area is X10 Y10 to X285 Y285
G21												; set units to millimeters
G90												; use absolute positioning
M83												; relative extrusion mode
M140 S75				; set bed H0 temp
T0												; set Tool 0 to proper tool to get this started
M568 P0 R175 S215 A1	; Sets Tool0 /Nozz/ 1st layer Temp / Standby Temps | Sets Tool0 to Standby
M561											; Disable ANY and ALL Mesh Bed Level Compensation
G28												; home X / Y / Z  w/out mesh bed level
G29 S1 P"/sys/heightmap.csv"					; Load and use latest heightmap for Mesh Bed Compensation | heightmap.csv is Default/latest 
G92 E0.0										; reset extruder distance position
G1 X5 Y5 Z20 F5000								; go to Steve's Dribble Zone and wait
M190 S75				; wait for bed temp
M116 H0 S12										; RRF3 - Waits for H0/Bed to get within 12*C | S5 Param | of Set Temp Above
M568 P0 S215 A2			; Sets Tool0  /Nozz/  | S - to 1st layer Temp | A-Sets Tool0 to Active /0-1-2/ 
M116 P0 H1										; Waits for Tool0 / H1 Heater 1  Nozz  to get to get to Print temps in M568 above
G1 Z0.24 F3000					; drop to 0.24 print height
G1 X5 Y5 F3000									; move to purge strip start position
G1 E10.0 F140									; puddle from Tilley Test
G1 Y60.0 E9.0 F1000.0							; intro line 1 from Tilley Test
G1 Y100.0 E12.5 F1000.0							; intro line 2 from Tilley Test
G92 E0.0										; reset extruder distance position
G10 S215 ; set temperature
M116 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
M572 D0 S0.05

Wish I could both recreate and recall the CAN Bus related error I get in Console of DWC exacly but its like STD Disregarded err ... blah CAN something or other ... I believe it has an erro number maybe but Im not at the machine atm to make it try and repeat error.

Anyone have this issue with prusa or super slicer ? If I manually edit the gcode to remove those two lines:

Prusa SLicers - emit this jive:
G10 S215 ; set temperature
M116 ; wait for temperature to be reached

Super Slicer emits this:
G10 P0 S215 ; set temperature
M116 ; wait for temperature to be reached

The print executes as expected.

PS. On my 2 other Duet 2 wifis rrf3.3 - no toolboard - I do not have the issue, but then the slicer's arent appending these codes for those physical printers either.

Ive searched googled, read for 2 solid days now ... duet -rrf discord ... prusa slicers forums... i got nothing so here I am ... hat in hand.

[deckingman]

@sputnikoc3d If I understand you correctly, you use start.g to set the hot end and bed temperatures but then the slicer adds additional (and incorrect) commands. Is that the case?

For sure G10 S215 will likely screw things because it should have a "P" parameter to denote which tool it refers to. You can either fix that in the slicer, or better still, not have the slicer set any temperatures (this is what I do). You can do that in Slic3r Prusa edition under "filaments" and then set the extruder and bed temperatures all to zero. This will result in the slicer not putting any temperature commands in the file (at least it does on my old version of Prusa Slic3r). I can't help with Super Slicer but I would imagine the same thing would work.

Edit. This has nothing to do with the Slicer sending garbage to the tool board because the slicer has no way of knowing if you are using a tool board or not. The slicer just generates a gcode file. The firmware is what determines which physical heater gets heated when a G10 or M568 command is sent to it.

[SputnikOC3d]

@deckingman said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@sputnikoc3d If I understand you correctly, you use start.g to set the hot end and bed temperatures but then the slicer adds additional (and incorrect) commands. Is that the case?

For sure G10 S215 will likely screw things because it should have a "P" parameter to denote which tool it refers to. You can either fix that in the slicer, or better still, not have the slicer set any temperatures (this is what I do). You can do that in Slic3r Prusa edition under "filaments" and then set the extruder and bed temperatures all to zero. This will result in the slicer not putting any temperature commands in the file (at least it does on my old version of Prusa Slic3r). I can't help with Super Slicer but I would imagine the same thing would work.

Edit. This has nothing to do with the Slicer sending garbage to the tool board because the slicer has no way of knowing if you are using a tool board or not. The slicer just generates a gcode file. The firmware is what determines which physical heater gets heated when a G10 or M568 command is sent to it.

Yes sir - you understand the issue precisely.

Thats interesting the slicer will behave that way if you do not set bed and nozz temp settings in it - hadnt occurred to me to attempt that.

Seems odd to have to resort to that. Ive been trying to get the Prusa / Super Slicer folks to explain how to make Slicer STOP injecting it "stuff" into otherwise perfectly well functioning start.g - but alas - no help yet.

Odd tho' - Super Slicer does in fact emit the P0 - and yet it still sits and waits at M116 ?

Im using firmware retraction - and those settings are in the filamnet's config.g ... is that where youre setting the the materials 1st layer and subsequent layer temps and print bed temps ?

[fcwilt]

@sputnikoc3d

I'm using firmware 3.3.

I have used Cura 4.10.0 and PrusaSlicer 2.3.3.

Currently I use Simplify3D.

I don't let slicers control temps - I do that using the filament handling feature of DWC.

All of the above can be made to work using that approach.

Frederick

[deckingman]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

Odd tho' - Super Slicer does in fact emit the P0 - and yet it still sits and waits at M116 ?

M116 will wait for all temperatures to reach their set points. Both the bed and the hot end. So it might be that what you are seeing is that the machine is waiting for the bed temperature to settle, rather than the hot end.

Im using firmware retraction - and those settings are in the filamnet's config.g ... is that where youre setting the the materials 1st layer and subsequent layer temps and print bed temps ?

I set my firmware retraction parameters in config.g but they can be in any file that gets run before the print starts. .

I use a "pre-print" macro which is similar in concept to using start.g, to do everything I want to to do before starting a print. This includes homing the machine and purging and wiping the nozzle as well as setting the temperatures. So in my slicer start code, I simply call that macro. I don't use separate temperatures for first and subsequent layers - I use the same temperature throughout.

[SputnikOC3d]

@deckingman

Bed is at temp before I run the voron's Quad Gantry Leveling - so its not waiting for that.

I suspect its waiting for a Tool it doesnt recognize.

[SputnikOC3d]

@fcwilt - im interested to learn more about how your doing this - care expand ?

Just manually setting temps in the DWC va drop downs and tool selections ?

[PaulHew]

This is the first 120 lines of my code from SuperSlicer, latest version.
I run a Mini 5 and a 1LC and I have no G10 commands in my gcode, searched the whole file.

 generated by PrusaSlicer 2.3.0+linux-x64-GTK3 on 2021-03-31 at 09:02:52 UTC

; 

; external perimeters extrusion width = 0.30mm
; perimeters extrusion width = 0.30mm
; infill extrusion width = 0.45mm
; solid infill extrusion width = 0.45mm
; top infill extrusion width = 0.22mm
; support material extrusion width = 0.40mm
; first layer extrusion width = 0.40mm

M107
;TYPE:Custom
; Multi-temp start code - 5 September 2020
; Raise bed temp to profile requested bed temp
M140 S105 ; Raise bed temp to profile requested bed temp
M104 S150 T0 ; Raise hot-end temp to 150C for G32 auto-calibration
M190 S105 ; Wait for bed temp to rise
M109 S150 T0 ; Wait for hot-end temp to rise to 150C
G29 S2
G28 ; home all axes
G28 Z 
;G32 ; Autocalibrate bed
G32 ; Autocalibrate bed a second time
G28 Z ; Home Z after bed leveling
;
G1 Z20 F600 ; Move bed down 20
M104 S245 T0 ; Raise hot-end temp to profile requested hot-end layer 1 temp
G29 S1 P"heightmap.csv"
M109 S245 T0 ; Wait for hot-end temp to rise to profile requested hot-end layer 1 temp
;
G1 X0.0 Y0.0 Z1.0 F2000.0 ; prepare to prime
G92 E0 ; reset extrusion distance
G1 Z0.2 F600
G1 X60.0 E9.0  F1000.0 ; priming
G1 X125.0 E12.5  F1000.0 ; priming
G1 Z0.5 F600
G92 E0 ; reset extrusion distance
;
;G29 S1 P"heightmap.csv"
; end of start code

G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
;Filament gcode
;G29 S1 P"100.csv"
;LAYER_CHANGE
;Z:0.24
;HEIGHT:0.24
;BEFORE_LAYER_CHANGE
;0.24


G1 Z0.240 F18000.000
;AFTER_LAYER_CHANGE
;0.24
G1 E-0.80000 F2700.000
G1 X250.189 Y252.360 F18000.000
G1 E0.80000 F2400.000
M204 S2000
;TYPE:Perimeter
;WIDTH:0.4
G1 F1500.000
G1 X267.698 Y252.360 E0.59058
G1 X267.698 Y269.869 E0.59058
G1 X250.189 Y269.869 E0.59058
G1 X250.189 Y252.420 E0.58855
M204 S3000
G1 X249.841 Y252.011 F18000.000
M204 S2000
G1 F1500.000
G1 X268.047 Y252.011 E0.61409
G1 X268.047 Y270.217 E0.61409
G1 X249.841 Y270.217 E0.61409
G1 X249.841 Y252.071 E0.61206
M204 S3000
G1 X249.492 Y251.663 F18000.000
M204 S2000
G1 F1500.000
G1 X268.395 Y251.663 E0.63760
G1 X268.395 Y270.566 E0.63760
G1 X249.492 Y270.566 E0.63760
G1 X249.492 Y251.723 E0.63557
M204 S3000
G1 X249.144 Y251.314 F18000.000
M204 S2000
;TYPE:External perimeter
G1 F1500.000
G1 X268.744 Y251.314 E0.66110
G1 X268.744 Y270.914 E0.66110
G1 X249.144 Y270.914 E0.66110
G1 X249.144 Y251.374 E0.65908
M204 S3000
G1 X249.530 Y251.418 F18000.000
;WIPE_START
G1 F14400.000
G1 X253.411 Y251.361 E-0.76000
;WIPE_END
G1 E-0.04000 F2700.000
G1 X267.594 Y253.173 F18000.000
G1 E0.80000 F2400.000
M204 S2000
;TYPE:Solid infill
;WIDTH:0.401719
G1 F1500.000
G1 X267.043 Y252.621 E0.02643
G1 X266.547 Y252.621 E0.01679
G1 X267.437 Y253.511 E0.04265
G1 X267.437 Y254.006 E0.01679
G1 X266.052 Y252.621 E0.06639
G1 X265.557 Y252.621 E0.01679
G1 X267.437 Y254.502 E0.09014
G1 X267.437 Y254.997 E0.01679
G1 X265.061 Y252.621 E0.11388
G1 X264.566 Y252.621 E0.01679
G1 X267.437 Y255.492 E0.13762
G1 X267.437 Y255.987 E0.01679
G1 X264.071 Y252.621 E0.16136
G1 X263.576 Y252.621 E0.01679

Everything I do is done from the slicer, right or wrong, but it works.
My only thought, could it be these settings? Under Printer Settings - General. GCode flavour.

Its a thought, that is all....
P.

[SputnikOC3d]

@paulhew Thanks for that Paul.

Yeah man its baffling. If tried it with Reprap flavor only and the reprap sprinter option as well.

I believe there is a setting in some old profile config text file buried in the bowels of the slicer installs - somewhere - causing this.

Ive checked - unchecked most every setting in all facets of the blasted software and re sliced and manually checked the g code. its maddening.

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt - im interested to learn more about how your doing this - care expand ?

Just manually setting temps in the DWC va drop downs and tool selections ?

When you create a Filament entry in the DWC it creates three files for each Filament: load.g, unload.g, config.g.

Here are the essentials of what I currently put in the config.g file for each Filament entered:

M221 S100 D0                         ; set extrusion multiplier
G10 S190 R0                          ; set extruder temps
M140 S60 R0                          ; set bed temps

set global.print_beg_prime   =  10 ;
set global.print_beg_retract = 0.5 ;
set global.print_end_retract = 0.5 ;

I make whatever settings are needed in the slicer so no temperature control code is generated.

I also enter into the slicer in the appropriate locations for user code M98 P"print_begin.g" and M98 P"print_end.g". Nothing else is entered.

In the print_begin.g file, near the start, I have this:

; select tool and configure based on filament selected

T0	; select tool 0 so extruder commands below will work
M703	; configure selected filament (sets bed/extruder temps, extrusion multiplier)

---

The M703 is the key as it executes the config.g file for the currently selected Filament.

So in the config.g file for each Filament you can put whatever you want or need. You can see I have three global variables used to control extruder priming/retraction.

[SputnikOC3d]

@fcwilt - perfect ...

I just switched over to firmware retraction so I am having to set this all up for each of my filaments now anyhow - so this added a few new dimensions for me to go with.

Now the missing bits are ... I need to sort out where in the slicer flavor of the week to :

"I make whatever settings are needed in the slicer so no temperature control code is generated."

Thanks for the tasty breadcrumbs for a solution.

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt - perfect ...

I just switched over to firmware retraction so I am having to set this all up for each of my filaments now anyhow - so this added a few new dimensions for me to go with.

Now the missing bits are ... I need to sort out where in the slicer flavor of the week to :

"I make whatever settings are needed in the slicer so no temperature control code is generated."

Thanks for the tasty breadcrumbs for a solution.

Well every slicer may require something different.

In Cura 4.10.0 and Prusa 2.3.3 setting the various temp settings to 0 stops the code being generated.

In Simplify3D just don't create any temp controllers.

Those are the only ones I know about.

Frederick

[SputnikOC3d]

@fcwilt - awesome .... super slicer and prusa slicer 2.3.3 here. Just re read @deckingman post above too and he described how to do as such.

I will give this a try and see if it sorts my drama.

TY fellas

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt - awesome .... super slicer and prusa slicer 2.3.3 here. Just re read @deckingman post above too and he described how to do as such.

I will give this a try and see if it sorts my drama.

TY fellas

Feel free to get back to me if you need more info.

Frederick

[SputnikOC3d]

@fcwilt - more questions. Ive seemed to have opened a can of worms onto meeeself ...

Whats the purpose of this ? set global.print_end_retract = 0.5 ;

Now i need to try and sortcreating and passing needed var's around - havent fiddled with that much coding in decades ... like Allaires ColdFusion decade LOL

Is the advantage of your print begin macros to remove the slicers quirks from the equation and have the vast majority of all things dealt with via your script and duet/rrf3 ?

This approach will require a complete rethinking of how I start and end my printing routines/jobs, which is fine, and due to this current issue with added junk code - I see the clear benefits. However; is there more to gain ?

Sounds like I just need to convert the code I have embedded in my slicer's custom code / start.g section into a revised macro housed in my own fw file structure and remove slicer / super slicer / ideamaker / s3d et al ... from that domain.

[dc42]

@sputnikoc3d if you were getting CAN error messages then those are most likely to be caused either by running different firmware versions on the main board and tool board, or because you don't have a G4 delay command in config.g to give the tool board time to start up before the first command in config.g that refers to the tool board. So check both firmware versions using M115 and M115 B# where # is the CAN address of the tool board, and check that you have a G4 S2 command near the start of config.g.

[SputnikOC3d]

@dc42 said in [ snipped out ]

Yes sir will do ... I only seem to recall getting these errors when I had this G10/M116 issue.

More to follow

Had G4 S1 !!! changed to 4 seconds as advised. TY

1LC - rrf3.3 beta 2+2
Duet 3 mini - rrf 3.3

Duet TOOL1LC firmware version 3.3beta2+2 (2021-04-16 13:48:06)

FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet 3 Mini5plus Ethernet FIRMWARE_DATE: 2021-06-15 21:46:20

[SputnikOC3d]

@fcwilt - my first stab at this- isnt going so well ...

I did a slice after creating a Print Start Macro - essentially putting my custom start.g routine into it. Did similar with a Print End.g - just used my custom End script to lift nozz and move head to a safe location for print removal.

Went thru an existing PLA filament config.g and updated it ti be more robust based up on this thread. Was just setting retraction and pressure advance before.

M221 S0.94 D121.0					; set extrusion multiplier
M207 S0.4 F2100 T1500 Z0			; FW retraction settngs | distance .4 | Speed - F | deRetract Speed - T
G10 P0 S215 R175                    ; set extruder temps
;M568 P0 R175 S215 A1				; Sets Tool0 / S-Nozz 1st layer Temp / R-Standby Temps | A1-Sets Tool0 to Standby Temp
M140 S65 R0                         ; set bed temps
M572 D0 S0.05						; Pressure Advance Settings S = distance .05 is median

Wasnt sure if there was a reason to set Nozz temps via G10 vs. M68 like I was in the start.g previously.

I did not set any var's ... not sure how yet.

Ran a slice and ... no appended junk G10/M116 combos - but no print to look at either. All gcode for the extruder is E0.00000's - entire print. So obvi Im doing something significantly errant.

Also - it just dawned on me .. for this approach to work successfully - I MUST have the proper filament selected via the DWC Load filament interface.

Starting to question my sanity of embarking on this approach ... with 3 different printers and 3 duet boards - one with different sized nozzles / brass and hardened steel / nozzle X and different hotends and bed type - I can see this getting unmanageable in a jiffy. If printer A with the hard steel nozz i usually use for PC and CF happens to be printing PLA - it needs to run about 10C hotter than the brass nozz printer next to it which may be occupied with a current job/plate full of parts that will take 8 hrs.

Not to digress too far off the prior issue at hand ... Im not sure I want to make THAT many Filament config.g combos ... [ lets address this sidebar another time ] I do need to get this new duet 3 Voron 2.4 printing reliably for now - deciding the best way to organize a plethora of print heads nozzles and gfilaments can come later after It actually works ... one way or another .

[fcwilt]

@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:

@fcwilt - more questions. Ive seemed to have opened a can of worms onto meeeself ...

Whats the purpose of this ? set global.print_end_retract = 0.5 ;

Now i need to try and sortcreating and passing needed var's around - havent fiddled with that much coding in decades ... like Allaires ColdFusion decade LOL

The purpose of using the global variables is there is other code I didn't post that use them to control extruder priming and retraction. Different filament types sometimes benefit from different values.

Is the advantage of your print begin macros to remove the slicers quirks from the equation and have the vast majority of all things dealt with via your script and duet/rrf3 ?

The goal was to allow using different slicers with the minimum amount of code in the slicer.

Generally I can slice a model in Cura, Prusa, Simplify3D or most recently ideaMaker and print it with different filament types just by selecting the desired filament type in the DWC.

Frederick

[engikeneer]

@sputnikoc3d looks like your toolboard firmware is still a beta, so might be that mismatch causing your issue like DC42 suggested...?

For the different temps for different machines, it might be a headache now, but it means your steel nozzle printer temps will always be right etc. You should also be able to send the same gcode to different printers. You just need to name the filaments the same on the different printers. You then just say which filament to call in the slicer (can't remember what the gcode is...)

Also, if you're still struggling with the slicer spitting out temp commands you dont want, you can use a python post-processing script to remove them or comment those lines out (thats what I do to help handle multi tool bits for mine). PrusaSlicer has a feature to run this when it slices a file

Finally M568 is the way to go over G10. G10 is being deprecated