-
|
So.. Had a really unusual problem recently. My machine wasn't printing anything, but would always do the purge lines perfectly. All of my problems started after a Klipper restart. Finally figured out the culprit... Somehow Klipper was in Absolute extrusion mode. As soon as I issued a single M83, everything works again. This is after several restarts of everything. Klipper, reverting changes, the whole Raspberry Pi... etc. This leads me to my question/concern. I can't seem to find ANYTHING in Klipper where you set the default extrusion mode... and this has me thinking - Should this maybe be a setting within the print_start macro? Or am I missing a setting that DOES exist somewhere? I see in the slicer where I can set relative or absolute, and the profile for my V0 I'm using has it as relative. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
In my experience this is something the slicer sets, and I don't really think it could be handled properly any other way, since it's so directly tied to how the slicer generates the g-code. Out of curiosity, which slicer were you using when you ran into this? |
Beta Was this translation helpful? Give feedback.
-
|
Superslicer. it's set to "use relative mode" - but I also have the setting for "Only custom start g-code" - because I don't want the temperature codes. I have a sneaking feeling this also makes it NOT send M83, even if it should. I'll make a test in a bit to see what it generates with/without the setting. |
Beta Was this translation helpful? Give feedback.
-
|
@jschuh finally got around to testing this in superslicer. For comparison, I right clicked the build plate and did "Add shape" - and made it 1 layer tall in Z, just for a smaller gcode file. I then sliced and exported the first file with the printers setting "only custom start g0code" checked, then unchecked the setting, resliced and re-exported. Here are the results of the first few lines of the file (minus the images) With Custom Start G-code checked: ; object:{"name":"Shape-Box","id":"Shape-Box id:0 copy 0","object_center":[60.000000,60.000000,0.000000],"boundingbox_center":[60.000000,60.000000,0.125000],"boundingbox_size":[12.000000,12.000000,0.250000]} M73 P0 R0 G1 Z0.2 F18000 With Custom Start G-code UN-checked: ; object:{"name":"Shape-Box","id":"Shape-Box id:0 copy 0","object_center":[60.000000,60.000000,0.000000],"boundingbox_center":[60.000000,60.000000,0.125000],"boundingbox_size":[12.000000,12.000000,0.250000]} M73 P0 R0 G1 Z0.2 F18000 You'll notice with the custom start Gcode checked, it doesn't set G21 ,G90, or M83... I would assume that the proper setting when using the custom g-code is to check the checkbox, as you aren't using a M109/M190 and the slicer will automatically add something, becuse it doesn't see those G-Codes, but there's some other "setup" G-Code that gets lost due to this.... The more I think about this, this seems to be a "unique" problem and might not be worth modifying in the macro. But, I also potentially see this affecting other users, and may be worth noting in the documentation as it could affect other users. The weird part for me, is I've had this happen only a few times for no seeming rhyme or reason. I also can't seem to find any variable, configuration, or anything that identifies what klipper's default mode is (I haven't gone through all the source yet either). Rebooting Klipper only seems to make this happen SOME times, not all the time, and I guess it depends on what the mode was last, but again, can't seem to find where the mode is being saved/cached anywhere in the klipper variable file/printer.cfg |
Beta Was this translation helpful? Give feedback.
-
|
Just re-read the gcode as well and its interesting (and why I think I did this in the first place...) The toolchange gcode contains re-setting the temperature. I think what I was finding in practice is this was creating an unnecessary few second pause at the end of the purge lines. I can do another export without my profile, but I think the problem is fundamentally the same, since my start g-code doesn't have any M190/M109 it's injecting some. |
Beta Was this translation helpful? Give feedback.
-
|
Like I mentioned in the earlier comment, the slicer really needs to set any indexing modes in its preamble, because that's per-print state, rather than persistent printer state. Ideally the slicer will warn you if you override things such that it could generate a file with an incomplete preamble (I'm aware of several places where Prusa Slicer has code to catch these sorts of errors) but at the end of the day the onus is really on the end-user if they're making more involved changes to the config. Regarding your specific issue, did the slicer config you were using have One other thing to note is that prusa3d/PrusaSlicer@09122fb (now in the beta) finally adds a config setting to disable those automatic temperature commands it inserts. So, at some point that should get pulled into SuperSlicer and properly address the core issue. |
Beta Was this translation helpful? Give feedback.
-
|
On the slicer doing the work, I agree 100%. I was only suggesting that it's somewhat unexpected that setting "Disable start G-code" would also not send the absolute/relative mode, units of measure, etc. and it might be worth a footnote in the documentation to help the next person. At least for me, the problem wasn't immediate or every time. My primary reason for the change was - "I'm implementing a custom start g-code, and I don't want the temperature auto-added" - but the scope of checking that in SuperSlicer is larger than at first glance. Yes, I did have single_extruder_multi_material set, as I was doing a multicolor print (also fake multi-extruder). I had been using SuperSlicer due to a few enhancements and it seemed to be the preferred slicer for Voron, but it hasn't been updated in some time now, so I'll take another look at PrusaSlicer. Curious to see if the mentioned PrusaSlicer beta also kills the startup G-code or if it just kills the temperature settings. |
Beta Was this translation helpful? Give feedback.
In my experience this is something the slicer sets, and I don't really think it could be handled properly any other way, since it's so directly tied to how the slicer generates the g-code. Out of curiosity, which slicer were you using when you ran into this?