Ending gcode is almost identical between Creality and Cura.
Only difference is on one line, as follows.
Cura uses:
M104 G91
Creality just uses:
G91
I don't see how an M104 hotend instruction should crash the printer.
If I could find a decent simulator, that'd be great.
EDIT: I've also tried removing the M104. But no success. I may have to write my own ending code, force head high, keep it there, etc.
Edited by BriceOnCnc3 hours ago, BriceOnCnc said:I have a Creality Ender 3 S1 Pro
Same. Are you using SD or something like Octoprint to get the Cura output to the printer?
Confirm you selected the printer as "Creality3d" then "Creality Ender-3 S1 Pro" when adding the printer.
13 minutes ago, BriceOnCnc said:Cura uses:
M104 G91
Seems... sparse. Should be more like
G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positioning
; retract filament to prevent snot
G1 E-10.0 F1200
G1 X0 Y{machine_depth} ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
That said, I did tweak mine a bit from stock. Let me add a new S1Pro for comparison.
Here is the 100% stock end gcode
G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positioning
G1 X0 Y{machine_depth} ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
Which version of Cura are you using?
Hi jaysenodell,
Using Cura 5.6.0. I only mentioned the G91 line because that was the only difference between both gcodes.
I hadn't created a new printer since a much earlier install, like 5.3. So guess that could be a problem. Ideally, I'd be able to debug the gcode as on my Tormach mill. Unfortunately, these little printers lack alot of those features.
I created a new printer, and now I get this ending gcode:
M140 S0
M107
G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positioning
G1 X0 Y220 ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
M82 ;absolute extrusion mode
M104 S0
I may try later using this gcode. Have to verify last head crash isn't throwing machine off calibration.
For the curious....
Here's what the ending gcode was for file which crashes.
M140 S0
M107
M104 G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positionning
G1 X0 Y0 ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
M82 ;absolute extrusion mode
M104 S0
File is attached in original post. Not much difference between this and new machine definition.
No, but there could be something in the printer definition.
do you use an intermediary like octoprint or is this printed via the ender firmware? I ask because I found that sometimes the Creality firmware is … unpredictable?
I was a bit surprised by the massive difference between gcode flavors. GRBL was just becoming easy and then this marlin comes along… there is a cheatsheet on the marlin site. Not bookmarked on my phone but a google for marlin gcode will get you there.
problem is that creality firmware doesn’t really stick to it 100%…
I'm only using SD cards. No networking. But firmware is now the latest 2.0.28. It has a few more features worth messing with.
I suspect the Cura issues will require me to do extensive testing. Unfortunately, I suspect it's going to be a similar situation as on the commercial CNC mills. The operator has to determine what combination of gcode is causing machine malfunctions. My dad was a machinist. And I'm a retired software developer.
I've seen the Marlin and Klipper gcode docs as well. Unfortunately, I think I'll have to stay with Creality for a bit longer. Until I can debug whatever is causing Cura to crash my S1 Pro. Without causing permanent calibration damage.
I'm on the same firmware (specificaly HWv24S1_301_SWV2.0.8.28F4_F401_FDM_LASER). I'm assuming you did the control panel update as well. I know there were tech notes on that being needed to resolve some issues.
I don't have crashes on sd card prints. I don't do them much any more. If you want, I'll run the gcode that crashes and see if it's the code or the hardware. I'm mid-nozzel swap to 1mm. What size are you using and I'll tune for that.
If you could try it, I'd appreciate it. I'm using .40 nozzle for now. The file is up top, CaliCube_Cura.gcode.
You're using exact firmware version as me.
Crashes on mine as well
Couple things I noticed. Something is going wrong in here:
G1 Z2.0 F3000 ;Move Z Axis up
G92 E0
G92 E0
G1 F3000 E-0.8
;LAYER_COUNT:100
;LAYER:0
M107
;MESH:xyzCalibration_cube.stl
Not sure what, but when executed from SD that effects a G28 XY action from the firmware.
Here's my Octoprint log for the sequence just before I killed power to the printer
Send: M117 99% L=-/-
Recv: ok
Send: M27
Recv: SD printing byte 354405/356832
Recv: ok
Recv: T:209.96 /210.00 B:60.02 /60.00 @:41 B@:26
Send: M27
Recv: SD printing byte 354816/356832
Recv: ok
Send: M27
Recv: SD printing byte 355255/356832
Recv: ok
Recv: echo: too long extrusion prevented
Those lines turn out to be:
M140 S0
M107
M104 G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
I don't think
M104 G91;
will ever end well on any printer!
I think that's the crash anyway.
That's what I've suspected before. The M104 G91 should be equivalent to disabling autotemp and enabling relative positioning.
Here's several possible solutions. What I'm going to test when I get a chance...
Or do what they should have done in the first place...
M104 S0
G91
Machinists typically don't mix M and G codes on the same line. Not best practice. Also if you suspect a bug regarding an M code, you force values you want. And see what happens. The S0 should disable the temps.
Edited by BriceOnCncYou can't mix them. The M104 should have a temp setting (SX) or nothing. The correct lines should be
M104 S0
G91
I think there is something wrong with the Cura settings in your end code though. From your original statement about end code that I didn't really digest at that time...
4 hours ago, BriceOnCnc said:Ending gcode is almost identical between Creality and Cura.
Only difference is on one line, as follows.
Cura uses:
M104 G91
Creality just uses:
G91
I don't see how an M104 hotend instruction should crash the printer.
If I could find a decent simulator, that'd be great.
So I think that spurous M104 is in there in the printer config. I'd remove it and I think you'd be good.
Edited by jaysenodellProbably a good testing idea. It looks like what they are doing is a relative move. To prevent stringing prior to a big move away from the part.
If you're doing that, it makes no sense to try and adjust temps until end of gcode anyway.
I'm going to give that a try. Worst case is I rewrite the code to go right to absolute moves. And force the print head all the way up out of the way. On CNC mills, you're removing metal. So you typically end with a gcode that just turns off spindle while moving the cutter up to max Z.
I know I can patch my ending gcode. Glad to know that someone else is also experiencing this mysterious bug.
However, just to be safe - my future Cura tests will be with HOLLOW CUBES....lol.
This bug causes a REALLY NASTY HEAD CRASH!!!
2 hours ago, jaysenodell said:The M104 should have a temp setting (SX) or nothing
Well intentioned, but not technically true. Here's the Marlin official documentation for M104:
But there is no way in hell that the line "M104 G91" is valid. Marlin deliberately avoid using "G" or "M" as parameters deliberately to make sure such lines are invalid. The problem here is that Creality does whatever the hell Creality wants, meaning there's several commands it either ignores completely or does its own way, and maybe that whoever's adding the Creality profiles to Cura isn't completely thorough by the looks of it, I had to set the print head size and gantry height on my printer manually (as well as adding my own custom g-code, but that's my preference, not something "wrong" with it).
3 hours ago, jaysenodell said:Couple things I noticed. Something is going wrong in here:
G1 Z2.0 F3000 ;Move Z Axis up G92 E0 G92 E0 G1 F3000 E-0.8 ;LAYER_COUNT:100 ;LAYER:0 M107 ;MESH:xyzCalibration_cube.stlNot sure what, but when executed from SD that effects a G28 XY action from the firmware.
If it doesn't trust the position of all axes (either it hasn't homed them or the motors have disengaged since the last time it did), the move command (where it moves the Z axis up, which should be a G0 by convention anyway) will make it home any untrusted axes (not that I'm sure that's what's going on here).
3 hours ago, BriceOnCnc said:Probably a good testing idea. It looks like what they are doing is a relative move. To prevent stringing prior to a big move away from the part.
that section is the "end code" of your pretiner config. you need to edit the printer setting and fix it. you have an M104 added to the first line of the ending code. That will fix your problem.
29 minutes ago, Slashee_the_Cow said:Well intentioned, but not technically true. Here's the Marlin official documentation for M104:
Yeah yeah yeah. You are right. I was overly simplifying becuase I was looking at the specific section which was turning of the hotend (S0). Thank you.
31 minutes ago, Slashee_the_Cow said:The problem here is that Creality does whatever the hell Creality wants, meaning there's several commands it either ignores completely or does its own way, and maybe that whoever's adding the Creality profiles to Cura isn't completely thorough by the looks of it, I had to set the print head size and gantry height on my printer manually (as well as adding my own custom g-code, but that's my preference, not something "wrong" with it).
In this case I'm damn near certina this whole thing is typos in startup and ending code.
33 minutes ago, Slashee_the_Cow said:If it doesn't trust the position of all axes (either it hasn't homed them or the motors have disengaged since the last time it did), the move command (where it moves the Z axis up, which should be a G0 by convention anyway) will make it home any untrusted axes (not that I'm sure that's what's going on here).
I had to head out with the boss lady before I could dive into the extra home, but there's something off there too. The axes home drop a prime line, then go nuts with another XY home. Then it starts to print the cube no issues. There are a lot of repeated" commands (G92 E0) but I can't seem to see anything that really does this. manual execution line by line seems to work OK.
Just ran the first several layers through octo... ran perfectly with no homing on after then the full G28. So that may be an issue with the firmware and this particular gcode.
1 hour ago, jaysenodell said:In this case I'm damn near certina this whole thing is typos in startup and ending code.
*/me sighs*
Fine, I'll actually look at the start and end gcode. And as I often do, criticise it at almost every step.
Startup Code:
;FLAVOR:Marlin ;TIME:783 ;Filament used: 1.09387m ;Layer height: 0.2 ;MINX:100.194 ;MINY:100.087 ;MINZ:0.2 ;MAXX:119.863 ;MAXY:119.806 ;MAXZ:20 ;TARGET_MACHINE.NAME:Unknown ; SLASHEE: This means it's probably for a completely custom profile, not one based on anything, but even then it should have a name ;Generated with Cura_SteamEngine 5.6.0 M140 S60 M105 ; SLASHEE: Report temperature: This does absolutely nothing when you're running a print from an SD card or through OctoPrint or anything and even if you're running it line by line it doesn't do anything useful M190 S60 ; SLASHEE: This completely obviates the M140 (set target temperature) because immediately afterwards you're telling it to wait for target temperature M104 S210 M105 M109 S210 ; SLASHEE: YOU JUST DID THE SAME THING AS YOU DID ABOVE EXCEPT THIS TIME FOR THE HOT END?!?!?!!?!?!?!!?!?!?!?!?? M82 ;absolute extrusion mode ; SLASHEE: Usually on by default, but doesn't hurt to set it G28 ;Home M420 S1 Z10 ; Load mesh, recommended for S1 Pro ; SLASHEE: My E3V3SE automatically turns bed levelling on after homing (which turns it off). This doesn't actually load a particular mesh (just the last one used), just turns on bed levelling and setting it so that by the time it gets to 10mm high it's no longer applying adjustments from bed levelling. ; SLASHEE: I actually run a G29 (level bed) here because taking a bit more time to make sure it's up to date doesn't hurt, but I won't blame you for not doing it G92 E0 ;Reset Extruder G1 Z2.0 F3000 ;Move Z Axis up ; SLASHEE: If your printer can actually move the Z axis at 50mm/s, that's pretty damn impressive - and convention says you should use G1 for extrusion moves (which this isn't) and G0 for travel moves G1 X10.1 Y20 Z0.28 F5000.0 ;Move to start position ; SLASHEE: See line immediately above G1 X10.1 Y200.0 Z0.28 F1500.0 E15 ;Draw the first line G1 X10.4 Y200.0 Z0.28 F5000.0 ;Move to side a little ; SLASHEE: See line three above G1 X10.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line G92 E0 ;Reset Extruder ; SLASHEE: This one is actually reasonable G1 Z2.0 F3000 ;Move Z Axis up ; SLASHEE: I hope I've made my point by now G92 E0 ; SLASHEE: You haven't extruded anything since the last time you reset it! G92 E0 ; SLASHEE: YOU JUST DID THIS THING WHICH DIDN'T DO ANYTHING!!!! G1 F3000 E-0.8 ; SLASHEE: 50mm/s is generally faster than I'd retract anything, personally
End code:
G1 F3000 E1093.07289 ; SLASHEE: Retraction of 0.8mm, perfectly reasonable for something like PLA M140 S0 ; SLASHEE: So we're telling the bed to cool down, seems alright so far M107 ; SLASHEE: Turn the fan off, again perfectly reasonable M104 G91 ;Relative positioning ; SLASHEE: Well this is a problem. M104 is "set target hot end temperature" and has nothing to do with G91, so it should probably be on a different line - this is probably your problem, and you shouldn't need to change the bed temperature again G1 E-2 F2700 ;Retract a bit ; SLASHEE: You just retracted a few lines ago! Also since the G91 hasn't worked this is going to try and retract the filament OVER A FRIGGIN METRE! G1 E-2 Z0.2 F2400 ;Retract and raise Z ; SLASHEE: Well at least it's not going to retract any more. But it is going to send the head straight down into the bed from wherever it just finished printing G1 X5 Y5 F3000 ;Wipe out ; SLASHEE: I never understood this part but it seems to be in the standard sort of code. But if the head is to the right of or behind the print, this will send it on a collision course. Also please see previous rant about travel moves being G0 G1 Z10 ;Raise Z more ; SLASHEE: Correction: Raise Z _TO_ 10. We're still in absolute positioning. See comment one line above about rant G90 ;Absolute positionning ; SLASHEE: There's a typo in the comment. And thanks to the earlier stuffup, we're still already in absolute positioning G1 X0 Y0 ;Present print ; SLASHEE: If your printer is a bed slinger, and depending on which way your printer slings the bed, this could put the print at the /back/ of the machine, not the front. To put the bed at the front of the machine you move the print head to the back, generally M106 S0 ;Turn-off fan ; SLASHEE: Pointless. You already did the M107 earlier M104 S0 ;Turn-off hotend ; SLASHEE: Pointed! It's still hot M140 S0 ;Turn-off bed ; SLASHEE: Pointless! It's literally the second line of the end gcode again M84 X Y E ;Disable all steppers but Z ; SLASHEE: If your printer has an ABL sensor you can probably disengage the Z motor, but unless you try and move it up or down manually without unlocking it or turning off the printer first, you're gonna have problems M82 ;absolute extrusion mode ; SLASHEE: We're not extruding anything after this, but whatever M104 S0 ; SLASHEE: This is the THIRD TIME you've done this. Fourth if you count the line with the G91. Do you think the printer is going to decide to warm itself up again because it's a cold night? ;End of Gcode
So I'll agree with @jaysenodell: there's about a 100% chance it's happening because you're not actually putting the printer in relative positioning mode in the end gcode.
Edited by Slashee_the_CowHi all,
Slashee: I believe the start/end code originated from an older version of Cura. And I agree, some of the gcode is odd. I have experience as a CNC machinist. The S1 Pro is my first 3d printer. Had no reason to manually inspect the gcode. First crash I've encountered.
The good news is when I used an updated machine profile, no more crashes. So I can start using Cura now.
Now for the bad news regarding the code that crashes. Read carefully, alot of detail here.
The culprit seems to be the "M104 M91" line that exists in the ending gcode. The calibration cube finishes, then the head goes FULL RAPID into the cube. And crashes hard. As though someone told it to do a G0. I don't believe G0 or G1 should even be executed at this point.
First time I encountered this, I decided to update firmware on the S1 Pro. I had no reason to update firmware prior to this. The firmware update didn't help. I'm currently using version 2.0.8.28 firmware (latest). The firmware is for the STM32 F4 chip. I stopped using Cura, went back to using Creality Slicer. Trying Cura occasionally when it had upgrades.
Machinists typically don't mix M and G codes on the same line. It's permitted, just considered bad practice. I suspect this was some kind of typo. Anyway, being a retired C++ developer, I suspect the software probably encounters the "M104". Then generates a bug due to either the lack of parameters, or being followed on same line with that "G91". I don't know how the firmware is processing the M104, but I would hope that one without parameters would default to an "M104 S0" or something.
In my personal opinion, this is a safety related bug. For example, if this had occurred on my Tormach CNC milling machine. It would probably be considered that. On those machines, it'd probably destroy the tool, part, fixture, and could even cause someone harm. I'm confident Tormach would update their PathPilot software to fix it, because they are a reputable company.
However, it's a 3d printer. I'll try explaining this to the Creality firmware guys. Maybe they'll address it as a safety bug. I just don't know.
Thanks to jaysenodell for being able to reproduce this bug as well.
EDIT: Had a typo where the M104 S0 is.
Edited by BriceOnCnc5 hours ago, BriceOnCnc said:Machinists typically don't mix M and G codes on the same line. It's permitted, just considered bad practice. I suspect this was some kind of typo. Anyway, being a retired C++ developer, I suspect the software probably encounters the "M104". Then generates a bug due to either the lack of parameters, or being followed on same line with that "G91". I don't know how the firmware is processing the M104, but I would hope that one without parameters would default to an "M104 S0" or something.
In Marlin it's not that you don't mix M and G codes on the same line, you can't. Each line can only contain one instruction and it deliberately avoids using G or M as parameters for any of them for this exact reason.
It's not a firmware problem. The problem is the g-code. M104 and G91 must be on separate lines. It's not executing the G91 (relative positioning) which means it's still in absolute positioning which means instead of moving up slightly it's moving straight down.
According to the Marlin reference an M104 without any valid parameters will disable auto-temperature mode. Since most printers don't use that anyway, it's essentially a no-op.
I don't believe it's a safety bug either, at least not with the printer, just GIGO. It's just a dumb machine following a limited set of simple instructions. If the instructions it gets are wrong, you can't really blame it for doing the wrong thing.
Edited by Slashee_the_CowSlashee,
Appreciate the info. Sounds like the Marlin community doesn't tolerate "sloppy" gcode. I'd rather see people learn more disciplined gcode techniques before they touch big iron machines.
No longer an issue worth worrying about.
Consider it closed/resolved. 😀
ArunC posted a topic in UltiMaker 3D printers,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
ArunC posted a topic in UltiMaker Cura,
Recommended Posts
Alain_D 4
Did you choose the right printer ?
May be something to do with the end of gcode...
Link to post
Share on other sites