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.
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 .
-
@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
-
@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
-
@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
-
@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.
-
Thank you sir. I will see about trying to update flash the 1LC in the am.
Ive been pouring over github issues on superslicer to try and track this down - its a common issue. To protect me from myself - prusa / super slicer has built in code generation that if it doesnt see M190 / M104 in a start.g routine - its going to produce a sequence of heater starts and M116 waits to make sure "safety" happens.
SuperMerrill indicates in a issue on git that theres an option to supress auto generated gcode, but i cant locate it anywhere in the application.
Another hack is to add a phantom useless M104 / M190 set of commands and that actually does work [ i tested ] SuperSlicer does not append the offending G10 P0 S215 and M116.
fun times - switching over to M568 has done my head in on this new voron for the last 3 days tracking this down to cause and solution.
-
@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:
To protect me from myself - prusa / super slicer has built in code generation that if it doesnt see M190 / M104
; PrusaSlicer (RepRapflavor - no temps) generates the following code ;M107 ; fan off (should be M106 S0) ;M98 P"print_begin.g" ; invokes my code ;G21 ; set units to millimeters ;G90 ; absolute XYZ moves ;M83 ; relative E moves
This is what Prusa 2.3.3 generates for me. Nothing there that causes any problems.
Frederick
-
https://github.com/prusa3d/PrusaSlicer/issues/6726
theres 25 other posted issue across superslicer git issue forum and prusa slicer ive read nearly 1000 posts in threads on the issue.
Both slicers will add G10 / M116 or G10 P0 [ prusa slicer ] / M116 [ sslicer ]
Here the dev of superslicer indicates you can turn the autogenerated gcode behavior off - but I cant seem to sort out how
-
@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:
https://github.com/prusa3d/PrusaSlicer/issues/6726
theres 25 other posted issue across superslicer git issue forum and prusa slicer ive read nearly 1000 posts in threads on the issue.
Both slicers will add G10 / M116 or G10 P0 [ prusa slicer ] / M116 [ sslicer ]
Here the dev of superslicer indicates you can turn the autogenerated gcode behavior off - but I cant seem to sort out how
Here is the start code from my install of Prusa 2.3.3.
This is with extruder/bed temps set to some typical values:
M107 M190 S60 ; set bed temperature and wait for it to be reached G10 S200 ; set temperature M98 P"print_begin.g" G10 S200 ; 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```
This is with extruder/bed temps set to zero:
M107 M98 P"print_begin.g" G21 ; set units to millimeters G90 ; use absolute coordinates M82 ; use absolute distances for extrusion G92 E0
As you can clearly see you only get the G10/M116 commands when extruder/bed temps are set.
Perhaps this behavior is only true for version 2.3.3 - but that is the version I have.
Frederick
-
with temps set in slicer 2.3.3
M73 P0 R65 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 S65 ; 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 S65 ; 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 M83 ; use relative distances for extrusion M572 D0 S0.06 G1 F2400.000 G1 X139.381 Y130.088 E0.04073 G1 X140.090 Y129.928 E0.02459 G1 X140.820 Y129.869 E0.02478 G1 X159.131 Y129.869 E0.61939 G1 X160.056 Y129.953 E0.03144 G1 X160.957 Y130.202 E0.03163 G1 X161.800 Y130.608 E0.03163 G1 X162.551 Y131.154 E0.03144
without temps set / using custom start.g code from before
M73 P0 R65 M107 ;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 S0 ; set bed H0 temp T0 ; set Tool 0 to proper tool to get this started M568 P0 R175 S0 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 S0 ; 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 S0 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 G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion M572 D0 S0.06 ;LAYER_CHANGE ;Z:0.24 ;HEIGHT:0.24 M73 P0 R64 G1 Z0.240 F12000.000 G10 ; retract G1 X138.275 Y130.564 G11 ; unretract ;TYPE:Skirt ;WIDTH:0.42 G1 F2400.000 G1 X139.381 Y130.088 E0.04073 G1 X140.090 Y129.928 E0.02459 G1 X140.820 Y129.869 E0.02478 G1 X159.131 Y129.869 E0.61939 G1 X160.056 Y129.953 E0.03144 G1 X160.957 Y130.202 E0.03163 G1 X161.800 Y130.608 E0.03163 G1 X162.551 Y131.154 E0.03144
with zero temps set in filaments / using a print start macro in slicer's custom start.g section
*** of note - it now generate E0.xxxx filament extrusion values. First time I tried it did not - odd; generated by PrusaSlicer 2.3.3+win64 on 2021-09-04 at 18:18:14 UTC ; ; external perimeters extrusion width = 0.45mm ; perimeters extrusion width = 0.45mm ; infill extrusion width = 0.45mm ; solid infill extrusion width = 0.45mm ; top infill extrusion width = 0.40mm ; first layer extrusion width = 0.42mm M73 P0 R64 M107 ;TYPE:Custom M98 P"Print_Start.g" G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion M703 ; Use / Engage Firmware retraction | Make sure this filament is in Duet w / filament / config..g ;M572 D0 S0.05 ; This should be in filaments / config..g ;LAYER_CHANGE ;Z:0.24 ;HEIGHT:0.24 G10 ; retract G1 Z0.240 F12000.000 G1 X138.275 Y130.564 G11 ; unretract ;TYPE:Skirt ;WIDTH:0.42 G1 F2400.000 G1 X139.381 Y130.088 E0.04162 G1 X140.090 Y129.928 E0.02512 G1 X140.820 Y129.869 E0.02532 G1 X159.131 Y129.869 E0.63285 G1 X160.056 Y129.953 E0.03212 G1 X160.957 Y130.202 E0.03231
So three slices - different approaches .... still odd behaviors
-
-
RepRap ... for these examples. reprap / sprinter exhibits same issues tho.
got the error again too
Warning Discarded std reply src=121 RID=4094 exp 206""
Separate issue:
Error: in file macro line 1 M221 Parameter 'D' too high
filament config.g error
M221 S0.94 D121.0 ; set extrusion multiplierSeems I do not address the E0 toolboard extruder via the 121 prefix. ; super noob
-
@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:
RepRap ... for these examples. reprap / sprinter exhibits same issues tho.
Odd.
got the error again too
Warning Discarded std reply src=121 RID=4094 exp 206""
Error: in file macro line 1 M221 Parameter 'D' too high
Well that should be an easy error to find and fix.
How about exporting from Prusa the config bundle with printers and post it here. I will import it into my Prusa install and see if I can find what you are doing that I am not doing which is causing the differences we are seeing.
Frederick
-
well as much as I appreciate that ... I think Id be wasting your time brother.
Im heading towards your macro methodology. I think long term it will serve me better. Prusa Slicer keeps driving more and more prusa centric interface and stuff into their fork, and Superslicer dev[s] seem agnostic to reprap and lean towards klipper. Being slicer agnostic and having more control over my well being seems prudent. Leaving the slicer to just handle basic slicing and pathing etc and besides Ive been looking closely recently at iDeaMaker. Super Slicer seems pretty nice and familiar as well. The devil I DO know sort of thing.
It seems a small price to pay to merely have to stuff a pair of M codes into the start.g if I still use that - but I think the /macro/Print_Start.g approach is where its at. Id rather spend time ironing out the details of getting that working and porting my filament profiles into that ... Seems like its working that way ... by passing my old way in start.g and using a macro to set all my environment and safeguards myself.
-
@fcwilt my last code example above that uses the M98 P"Print_Start.g" - seems to have worked and generated some proper gcode.
I just need to get a good Print_Start.g macro written
that said - Im trying to get my head round my filaments config.g. So far here's what I think I need to have in each one.
M221 - extrusion multiplier
M207 - retraction / de retraction / speeds and distances
M568 - nozzle print and standby temps
M140 - bed temps
M572 - Pressure Advanceuncertain items
Input shaping settings ? have no idea how that works yetGlobal Var's - not sure what needs to be set and where else they will be used.
-
@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:
@fcwilt my last code example above that uses the M98 P"Print_Start.g" - seems to have worked and generated some proper gcode.
I just need to get a good Print_Start.g macro written
that said - Im trying to get my head round my filaments config.g. So far here's what I think I need to have in each one.
M221 - extrusion multiplier
M207 - retraction / de retraction / speeds and distances
M568 - nozzle print and standby temps
M140 - bed temps
M572 - Pressure Advanceuncertain items
Input shaping settings ? have no idea how that works yetGlobal Var's - not sure what needs to be set and where else they will be used.
Well I think I posted most of my print_begin.g file - didn't I?
And the global variables are something that can be used or not. Nothing special about them. In my case it just allowed me to change certain priming/retract settings as needed by different filaments, in the filament config.g file and later use them in the print_begin.g file.
Frederick
-
@fcwilt - yes I have your macro saved and Im going thru it ... stealing what I understand and incorporating that and finessing my stuff in there - fingers crossed
thanks for all the help.
-
@fcwilt just went all in on 3.4.0 beta 3 - lol fingeres crossed ..
-
@sputnikoc3d said in STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard:
@fcwilt just went all in on 3.4.0 beta 3 - lol fingeres crossed ..
You are braver then I - I wait until the release version is out .
Frederick
-
@fcwilt - heres a solution for Super Slicer ...
https://github.com/supermerill/SuperSlicer/issues/425#issuecomment-913036749
found the setting [ if it were a snake it have bit me ]