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

[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

[fcwilt]

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

@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.

Did you remember that you needed to have in your print start code the M703?

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.

I didn't post all of my code that I run start print start - see below.

I do some "sanity checks" to insure things are correct - such as filament selected and needed commands in the filament config file.

Then you can see where I use the global variables. Using them is strictly optional.

; 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)

; check for selected filament

if move.extruders[0].filament = ""
  M291 R"No Filament Selected" P"Cannot Continue" S2 T0
  abort

; check bed heater active temp setting

if heat.heaters[0].active = 0 
  M291 R"Bed Heater Active Temp = 0" P"Cannot Continue" S2 T0
  abort

; check extruder heater active temp setting

if heat.heaters[1].active = 0 
  M291 R"Extruder Heater Active Temp = 0" P"Cannot Continue" S2 T0
  abort

; check if homed - allows homing (OK button) or canceling (CLOSE button)

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  M291 R"Printer has not been homed" P"Home and Continue?" S3 T0
  G28

; setup to print

M291 R"Preparing to print" P"Please wait..." T0

M106 P2 S255                    ; lights on
M106 P3 S255                    ; lights on
M106 P4 S255                    ; lights on

G90                             ; absolute moves
G1 Z100     F1200               ; position for cleaning
G1 X0 Y-145 F6000               ; position for cleaning

M291 R"Heating Extruder & Bed" P"Please wait..." T0

M116                            ; wait for temps to reach set points

M291 R"Priming Extruder" P"Please wait..." T0

M83                                 ; insure extruder relative mode
G92 E0                              ; reset the extruder logical position
G1 E{global.g_print_beg_prime} F120 ; prime the extruder
M400                                ; wait for extruding to finish
G92 E0                              ; reset the extruder logical position

M98 P"beep_alert_1.g"               ; beep paneldue

M291 R"Clean Nozzle and Bed" P"Click OK to begin printing" S3 T0

G1 E{-global.g_print_beg_retract} F120 ; retract to control oosing
M400                                   ; wait for extruding to finish
G92 E0                                 ; reset the extruder logical position

M98 P"mesh_load.g"                     ; load height map as needed

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 .

Whatever approach you use the information needs to be somewhere.

I wanted to be able to use different slicers with a minimum of information duplicated in each slicer, such as temp settings.

I have been using this approach since the v3 firmware came out and have expanded it as things like variables became available.

I have four printers, all different. I simply use an FTP client to download all of the filament files from the "master" printer and upload them to the remaining printers.

I have found no reason (yet) to not use this approach.

But everyone is different - you need to use whatever approach suits you best.

Frederick

[SputnikOC3d]

@fcwilt - awesome.

Ok so it is manageable. This further info posted from your start print macro is helpful. The conditional code - solves several concerns - wasnt thinking of that flexibility being availed in rrf3.x but its there now.

Yes T0 and M703 are the 1st two lines in my start macro, but Im sure it was my lack of passing temps for nozz and bed thru variables to the slicer somehow that cause it to emit junk gcode.

I did find a hack for the superslicer G10/M116 issue - and that is - it and prusa slicer will not emit "safeguard" gcode into the mix if you stuff a M104 / M190 at the front of your custom start.g in the slicer.

I switched over to M568 ... and neither slicer jived with that; hence it stuffed a G10 P0 S215 and a M116 - to safeguard me from myself.

2 am now ... lots to ponder and fix. off to bed for a short bit then back at it fresh in the a.m.

thanks again for all your help.