STUMPED : Slicer sending Garbage Start.g GCode to 1LC toolboard
-
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.
-
@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 ?
-
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.
-
@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.
-
@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.
-
@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.
-
@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
-
@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
-
@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
-
@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.
-
@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.
-
@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 followHad G4 S1 !!! changed to 4 seconds as advised. TY
1LC - rrf3.3 beta 2+2
Duet 3 mini - rrf 3.3Duet 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
-
@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