Bad gcode produced when interpreting {code1, code2} in M140, M109, M190 #17501
Comments
bellzw
added
Status: Triage
|
Is there a reason to include an "extruder number" in the bed heatup?
Maybe try removing 'initial_extruder_nr' And see if just |
|
@photodude That's a reasonable question, and is probably the answer! The reason for initial_extruder_nr was, because, as far as I knew, Cura picks up the bed temperature from the build plate temperature parameter in the profile of the material assigned to whatever tool chain is currently selected. Now that I look at the github version of fdmprinter.def.json, I see that this is NOT settable per extruder, and that Cura resolves the issue of different bed temps because different materials specify different temps by using the maximum of all extruders. This does not resolve the issue with the M109 T{initial_extruder_nr} S{material_print_temperature_layer_0, initial_extruder_nr}. material_print_temperature_layer_0 IS supposed to be settable per extruder, so that should have worked. Anyway, I removed the initial_extruder_nr in all 3 places, and that results in which is correct. Arrows are mine. So it seems that the issue is related to S{code1, code2}, when code2 is a replacement pattern. The M109s with S{code, 0} and S{code, 1} worked correctly. Fixing the M140 and M190 substitutions, but leaving the last M109 as |
GregValiant
added
Status: Needs Info
|
Can this be a simple syntax error? You are explicitly calling out T{initial_extruder_nr} and then adding the S parameter with the extruder number added a second time. Why bother? It's already stated that this is for the initial extruder. It would seem that this should be sufficient: Separating the two replacement patterns and explicitly calling for the comma might also work: I don't see a Cura bug here and this does appear to be firmware specific. What firmware flavor are you running? |
|
@GregValiant Thank you for the suggestions, but I don't think they quite worked; details are immediately below. In addition, I found a different but possibly related problem with replacement patterns; look for the Bolded "However" below. Firmware is Marlin 1.something Shaqfoo fork. It doesn't like to see parentheses in the gcode. It doesn't crash, but it causes the heater for the extruder to shut off, so it seems to interpret S(200, 0) as S0. This code worked in versions up to 5.5, so something changed in 5.6. I'm merely a user, and don't know what's actually in the code. I've never been able to find documentation of the syntax of replacement patterns, other than a few examples at https://github.com/Ghostkeeper/SettingsGuide/blob/master/resources/articles/machine_settings/machine_start_gcode.md. There are comments about what happens if a per extruder setting does not references an extruder, and they guided me to include the initial_extruder_nr in the M109. M109 T{initial_extruder_nr} S{material_print_temperature_layer_0, initial_extruder_nr} should NOT be a syntax error because, per fdmprinter.def.json, material_print_temperature_layer_0 IS settable per extruder. The M140 was a syntax error, and I've corrected that in my 5.6.0 and 5.1.0 installations. I did try separating the two patterns per your suggestion and got M109 T0 S180, 0 . I don't think the , 0 will fly. I also tried S{{material_print_temperature_layer_0}, {initial_extruder_nr}}, but that resulted in Cura not correctly interpreting all replacement patterns, so I'm guessing that nesting braces is not permitted and not expected. However, I tried your suggestion to omit initial_extruder_nr from the M109 and got the correct gcode. Being hopeful, I moved the model from T0 to T1 to make sure of things, but, much to my surprise, I got Apparently, Cura thinks initial_extruder_nr is 0, despite putting T1 correctly at the top of the code. T references above the M109 use constants; the only lines in the startup code containing initial_extruder_nr are the two incorrect lines above, This error also occurs when I use the BIBO definition distributed with Cura 5.6.0. When I use the startup code with Cura 5.1.0, the generated code is correct, both with the distribution BIBO definition and my definition. Again, I come to the conclusion that there is a bug related to replacement patterns. Would it help if I post 3mf files for some of these cases? |
github-actions
bot
removed
the
Status: Needs Info
|
Looking back I found one of my old posts. "initial_extruder_nr" gets replaced but always with a "0" rather than the number of the initial extruder. I'll mark this as a duplicate report. It appears that it's on the list of things to fix but it hasn't been repaired yet. |
|
Ok. The bad incorrect replacement of initial_extruder_nr is something I discovered only yesterday. The error regarding that M109 is a separate item.On Dec 8, 2023 4:27 PM, GregValiant ***@***.***> wrote:
Looking back I found one of my old posts.
Take a look at #15673 , #16715 (for a BIBO) and #11985 .
On Sept 18 @MariMakes added a ticket to the backlog CURA-11053. It would appear that this still hasn't been addressed.
"initial_extruder_nr" gets replaced but always with a "0" rather than the number of the initial extruder.
I'll mark this as a duplicate report. It appears that it's on the list of things to fix but it hasn't been repaired yet.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
I'll remove the duplicate tag. I think it's time to get a professional involved. @fieldOfView the OP would like to get something like this to work in the startup gcode to return the proper Initial Temp for the Initial Extruder. |
|
The exact replacements that we BIBO owners would like to have working are I appreciate @GregValiant's help with this issue. |
|
Hey all, Sorry, it took us a while to get back to you 😞 I have to be honest, that this discussion on Gcode formula level is outside my field of expertise. When I'm reading these comments, it seems to either introduce new bugs or is not resolved. I'll bring it up to the team to see what they can do to improve it. |
|
Hi, Thanks for the bug report. We recently changed some of the behavior regarding start/end extruder/machine gcodes (#16962). With this change formula's are now accepted with in the curly brackets. With this change apparently an oversight was made regarding the optional extruder argument. It was assumed that only patterns like Should be relatively easy to fix by changing this regex to accept any expression after the comma. |
MariMakes
added
Status: On Backlog
|
Thanks for the update, @casperlamboo. One comment on the M140: I was wrong to expect M140 S{material_bed_temperature, initial_extruder_nr} to work. According to fdmprinter.def.json (my BIBO inherits from this definition), material_bed_temperature is NOT settable per extruder. None of the bed_temperature parameters are settable per extruder, and this makes sense because printers don’t (as far as I know!) have more than one bed. So, M140 should always be M140 S{material_bed_temperature}, or the like; I’ve corrected my startup code accordingly as the BIBO only has one bed. As I understand fdmprinter.def.json, resolution of different materials on different extruders having different bed temperatures is by using the maximum of the bed temperatures: "resolve": "max(extruderValues('material_bed_temperature'))". There are 2 issues:
Recently, I’ve found that issue 1, above, appears may be related to Skirt/Brim Extruder and occurs in 5.6.0 and 5.5.0. When a print is entirely on E2, and brim is the selected adhesion, these combinations of Build Plate Adhesion Extruder, Skirt/Brim Extruder result in incorrect substitutions: (Not overridden, not overridden) and (E2, Not overridden). The combinations (E2, E2) and (Not overridden, E2) result in correct substitutions. It appears that 5.5.0 and 5.6.0 take Skirt/Brim Extruder to be the one to start printing, but there seems to be a disconnect between the initial T1 inserted into the gcode, and the extruder Cura thinks the printing should start with. Issue 1, above, happens in 5.1.0 in an understandable way if the build plate adhesion extruder is different from the skirt/brim extruder. Is there a philosophical difference in the way Skirt/Brim Extruder is treated in 5.5.0 and 5.6.0? In 5.1.0, there is no Not overridden option, Cura interprets Skirt/Brim Extruder to be the extruder that will print the brim, and so it starts with that extruder. 5.1.0 does this when the adhesion extruder is E2 and Skirt/Brim Extruder is E1; Skirt/Brim Extruder seems to override Build Plate Adhesion Extruder, printing starts with T0 doing the brim, and then switches to T1 to do the model. The actual initial extruder matches the substitution in 5.1.0. I have attached a pdf with examples of good and bad behavior. |
|
Quick update from our side 👋 We released a special Alpha to help with the slicing crashes, but since it's a Work In Progress build it contains the fix that has been proposed. You can download the build yourself here and see if it fixes your problem: #18080 Can you let us know if the problem you described in your wonderful PDF is solved or if you would like us to take another look? |
|
The issue of M109 T0 S(200, 0) appearing seems to be fixed; I see M109 T1 S200.0 where I should. However, the issue of initial_extruder_nr being wrong at the end of the startup code remains. This is what I see when slicing for BIBO2 dual (as distributed with Cura), all extruders are set to Not overridden with the model assigned to E2, no supports, no prime tower, Normal 25% infill profile, my materials Sunlu White PLA and Green Silk PLA assigned to E1 and E2, respectively: Gcode above starts printing with E1 and never selects E2. It appears that Cura thinks it's supposed to use E1 for something, despite there not being any mention of E1, except that there is material assigned to the extruder. When I change only the Skirt/Brim Extruder to E2, I get: If I disable E1, I get: The option to set Skirt/Brim extruder disappears, as expected, and now the substitution for initial_extruder_nr is correct. Apparently, if E1 is enabled and not, as far as I can tell mentioned in any setting, a model entirely on E2 will cause an incorrect substitution of initial_extruder_nr. I searched for "extruder" in the settings window and enabled every setting that I though referenced an extruder, but did not see anything when slicing to indicate that E1 was referenced. Let me know if you want me to try other combinations of settings and extruder to which the model is assigned. |
For the `skirt_brim_extruder_nr` setting it is possible for the setting to be -1; this means that we have no preference for extruder. This allowed us to implement the "multi-material brim". When we were requesting the initial extruder, and this value was set to -1 we were default to the 0-th extruder. However, this was incorrect in the situation where the first extruder is not used. Fixes #17501
|
@bellzw, thank your response. The second issue you mention is caused by a feature we implement called multi-material brim (Ultimaker/CuraEngine#1613). To enable multi-material brim the skirt-brim extruder is set to extruder_nr -1 (this is now the default value for this setting). However, there was an oversight made when implementing the feature that, if the extruder_nr was set to -1 the initial extruder nr defaulted to 0, even when the first extruder is not used. Made a partial fix in 8af3de2. Implementation will not solve every case, we cannot always correctly determine the initial extruder in the frontend without slicing the model. Read commit message for more info. However, for the specific case stated in this issue the fix will work. |
Cura Version
5.6.0
Operating System
Windows 10
Printer
BIBO 2
Reproduction steps
I have created my own definition for this printer and it has been working for me since before 5.0. Below is the startup code copied from the Machine Settings; it correctly reflects what's in the json file:
; Start of BIBO starutp code
M140 S{material_bed_temperature, initial_extruder_nr}
M104 T0 S{material_standby_temperature, 0}
M104 T1 S{material_standby_temperature, 1}
G21 ;metric values
G90 ;absolute positioning
M107 ;start with the fan off
T0
G92 E0
G28
G1 Y0 F1200 E0
T1
G92 E0 ;set extruder 2 position to 0
M109 T0 S{material_standby_temperature, 0} ; now wait for E1 to reach temperature
M109 T1 S{material_standby_temperature,1} ; now wait for E2 to reach temperature
M109 T{initial_extruder_nr} S{material_print_temperature_layer_0, initial_extruder_nr} ; now set the correct extruder to the correct initial temperature
T{initial_extruder_nr}
M190 S{material_bed_temperature, initial_extruder_nr}
M117 BIBO Printing...
Actual results
This is the gcode generated by 5.6.0 (installed on 2 Dec 2023):
; Start of BIBO starutp code
M140 S(60, 0) <------
M104 T0 S175.0
M104 T1 S175
G21 ;metric values
G90 ;absolute positioning
M107 ;start with the fan off
T0
G92 E0
G28
G1 Y0 F1200 E0
T1
G92 E0 ;set extruder 2 position to 0
M109 T0 S175.0 ; now wait for E1 to reach temperature
M109 T1 S175 ; now wait for E2 to reach temperature
M109 T0 S(200.0, 0) ; now set the correct extruder to the correct initial temperature <--------
T0
M190 S(60, 0) <------
M117 BIBO Printing...
I have marked the bad code with <------ on the right.
Expected results
; Start of BIBO starutp code
M140 S60 <------
M104 T0 S175.0
M104 T1 S175
G21 ;metric values
G90 ;absolute positioning
M107 ;start with the fan off
T0
G92 E0
G28
G1 Y0 F1200 E0
T1
G92 E0 ;set extruder 2 position to 0
M109 T0 S175.0 ; now wait for E1 to reach temperature
M109 T1 S175 ; now wait for E2 to reach temperature
M109 T0 S200.0 ; now set the correct extruder to the correct initial temperature <-------
T0
M190 S60 <-------
M117 BIBO Printing...
Add your .zip and screenshots here ⬇️
bibo2_dual_improved.def.zip
These are the printer and extruder definitions that have worked in 5.0 and earlier versions.
The text was updated successfully, but these errors were encountered: