New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start code does not represent actual start code #13943
Comments
Thanks for the report. If there is no mention of temperatures in the StartUp Gcode then Cura adds temperature lines before the StartUp is inserted. It is a safety to prevent cold extrusions. You need to make an adjustment to your StartUp Gcode. ; I'll remove the "Bug" label as what you have there is what was provided by Creality (or a contributor). It would work fine if you didn't have ABL. With ABL it does need to be tweaked. |
wouldn't it make more sense to add this code in printer start code dialog rather than just silently adding "pre-start code we though you are forgetting, but we won't ask if it is really what you want" 😃 |
Most people don't know enough about Gcode to make their own changes. They would just dismiss the dialog. Plus, the dialog would come up a lot and be really annoying. Better to just learn the software (and gcode). Competence is the best solution. |
I meant adding heating commands to manage printers -> machine settings -> start G-code dialog and for example indicate error if it lacks temperature commands. |
If you will install an Ender 3 Pro you will see that the StartUp gcode is written that way. |
The "historical" reason why it is done like it is now is that the heatup sequence is added by CuraEngine (the actual slicer that does the work), and CuraEngine can also be used without the Cura frontend. I think it would be a good idea to have the Cura dialog detect the absence of a heatup sequence and add a note that a heatup sequence will be added. Then again, that dialog is very cramped to begin with, so I think the gcode snippets should be moved somewhere else (a tabof their own?) |
Separate tabs for StartUp Gcode and Ending Gcode could work. When switching to the "StartUp Gcode" tab a check could be run to see if heating commands are in there. If there are none then a popup could inform the user that heating lines will be added prior to the StartUp. With the expanding use of ABL systems it could be helpful. Adding two more tabs might make it a bit more cluttered on a multi-extruder printer though. |
I get the cold extrusion protection. You should be looking for M104/M140 and M109/M190. That does not explain the spurious M82. Why does Cura add this?
before the custom start code. That looks dangerous. You should have that after custom code or M83 if the relative option is check in printer settings. If I use M83 in custom code and don't set it back, does Cura realise? A bit of investigation (not knowing the software), I find https://github.com/Ultimaker/CuraEngine/blob/cc03a5711c1a28e91cd48c1ffef19dba852b4ca1/src/gcodeExport.cpp#L1018 might be the cause. It seems to say "ensure absolute extrusion mode" when entering start gcode, but then only sets relative if it is selected. Maybe it should set absolute on entering (which can be reset) and then ensures either relative/absolute as you won't know what mode the custom start gcode left it in. This particular element is nothing to do with printer profiles - but coding in CuraEngine. |
M83 ;last line of starting gcode That line is always inserted when in relative mode regardless of what came before. |
Not with Cura 5.2.2. Steps to reproduce (Note this is from Cura 5.2.2, but the root cause is CuraEngine): Set your custom gcode:
Slice and check generated gcode:
Note the M82 before custom gcode, the M83 relative extrusion within the cusom gcode and no M82 after custom gcode. Extrusion mode is left as relative but E values generated indicate absolute. |
But as a user, I would expect some signal that something may appear before my start gcode and that CuraEngine not assume I have not chosen a local extrusion/coordinate movement for my start gcode purposes. Would seem reasonable to G90 before custom start code and then either M82/M83 based on what extrusion mode it requires after so you're not dependent on an assumption. Or even better, not put any "pre-start" statements before the "start" statements - making my custom "start" code be at the "start", instead of "not quite the start". Then add code after if required (like G90, M82 if relative extrusion and M140&M190 to ensure print-start temps. |
I kind of agree with both of your views. in current state this management is just a mess. you have some validations, some assumptions that are silently injected at the very beginning which can be then dismissed by user error or otherwise, but in some cases you can't make printer do what you want because there are some undocumented protections going on. regarding absolute/relative movements and extrusions, that should be part of actual g code and not rely on assumption it is not changed, but otherwise software should not interfere if user f**ks around he should be able to find out. |
I just sliced this with 5.2.2. Someone from the Cura team will take a look. |
Having two M83 when Cura generates relative extrusion isn't really a problem. Cura wants relative extrusion and asked for it when it was set by custom gcode. For example, there's plenty of redundant The real problem is if my custom gcode leaves the machine in relative extrusion and CuraEngine does not reset it back to absolute gcode, but then proceeds to export gcode statements using absolute extrusion E values (because relative extrusion has not been requested). What should be expected is that after custom gcode, CuraEngine adds either M82/M83 to ensure the extrusion mode is as expected by the rest of the gcode. So it should say:
|
Application Version
5.2.1
Platform
Linux ubuntu
Printer
Creality ender 3 v2 neo
Reproduction steps
go to manage printers -> machine settings
there is printer start g-code section
slice the model and view the exported Gcode- more code is added to beginning of the file before start code
basically my issue is that after printer does auto bed leveling the nozzle touches the bed as last step of
G29
command. since cura have injected gcode before my start code to heat the bed and the nozzle to the printing temperatures and it causes oozing and a booger of filament is wiped in the center of build plate as last step of ABL routine before priming the nozzle.to prevent this, code that is injected by cura like:
and other lines should be part of actual start code so the user could modify order of execution and fine tune behavior.
Actual results
printer start Gcode
Gcode generated by cura
Expected results
I would expect that start code is the actual start code of the printer and nothing is added to it before.
Checklist of files to include
Additional information & file uploads
otherwise my solution is either to try to clean the booger of the plate while printer does nozzle priming line or I have to modify start code to cancel out preheating right after it has been heated, do the ABL routine and turn back on nozzle heating which adds significant delay to print time.
The text was updated successfully, but these errors were encountered: