Cura: Z-axis not moving up as it should in new Cura 3.6.0
Application Version
Cura 3.6.0
Platform
Windows 10
Printer
Anet A8
Steps to Reproduce
Print a 26 mm cylinder with threads in them
Actual Results
At about 15% the Z-axis on my printer still read 0.2 mm and it had printed many layers at the same height.
Expected results
A 15 mm cylinder with threads in the inside.
Additional Information
Printer was working fine for 4 month then I upgraded to latest Cura.
TomasNielsen
All 27 comments
Hi @TomasNielsen , I think someone else had a similar problem recently and, if my memory is right, the solution was to disable the accel and/or jerk control in the Cura profile. Hope this helps!
smartavionics
on 6 Dec 2018
HI @smartavionics !
Thanks for the suggestion, I tested it this morning. Disabled both accel & jerk. But after 72% it was still at 0.2 mm. So that did not help in this case.
TomasNielsen
on 7 Dec 2018
Looking at the gcode, I notice it's doing retractions with z-hop on layer change and it does this little up/down movement, try disabling the retract on layer change and see if that makes any difference.
smartavionics
on 7 Dec 2018
Tested that now. It ran to 100% completion at 0.2 mm. I will try to downgrade Cura.
TomasNielsen
on 9 Dec 2018
OK, but, really, if the machine can't cope with a little jiggle up and down then it's got a problem.
smartavionics
on 9 Dec 2018
No there is something wrong with the latest Cura 3.6. I'm now printing the same .STL with Cura 3.4.1 and it was at 1.6 mm and progressing fine when I left the garage. Cura 3.6 never came higher than 0.2 mm and printed everything on top of the previous layers.
TomasNielsen
on 9 Dec 2018
So please zip the gcode that works OK and the gcode that doesn't and attach to this issue so I can compare them. Thanks.
smartavionics
on 9 Dec 2018
Working3.4.1.zip
NotWorking3.6.0.zip
Sure! Here they are.
TomasNielsen
on 9 Dec 2018
Hmm, I have a wacky theory, please print this and see if it behaves better than before.
smartavionics
on 9 Dec 2018
Hi!
This worked super good! The print has a much smoother surface and the threads do not have blobs in them that make them hard to use.
So I would say you found the problem! (I'm eager to hear what you found)
And also 3.6.0 does something to my prints that 3.4.1 does not. Or could it be the disabled z-hops or jerk settings that made the print better?
TomasNielsen
on 9 Dec 2018
Great, that confirms the bug and it has to be one of the oddest bugs I've seen in a long time. The reason that the printer is not moving above 0.2mm is because the model file name is PluggM氓tt v1.stl. I know that sounds crazy but it's true. The problem occurs because Cura 3.6 inserts into the gcode comments that contain that name like this excerpt from you bad gcode file:
;LAYER:1
M140 S85
G1 F2100 E30.77954
M106 S127.5
;MESH:PluggM氓tt v1.stl
G0 F4500 X97.416 Y105.849 Z0.4
;TYPE:WALL-INNER
G1 F2100 E33.77954
G1 F3000 X97.284 Y106.229 E33.79559
I'm guessing that the firmware in your printer doesn't like the 氓 character and somehow that confuses the firmware sufficiently so that the next line in the gcode gets treated as a comment. In the example code above the next line contains the move to the layer above (Z0.4)! and so the move never happens and the nozzle stays at 0.2mm for the whole print.
So a simple workaround should be not to use model files that have file names containing anything but ascii characters.
Is this a bug in Cura or a bug in Marlin or both?
smartavionics
on 10 Dec 2018
HaHa! Yes, that's a little crazy. ;)
M氓tt means measure in Swedish. (I'm measuring the threads for a replacement plug for where you prime a water pump)
As a swede that has worked with programming for 20+ years I've seen a lot of weird stuff coming from our three extra characters 氓盲枚. Some of the big companies I've consulted for use Chinese characters and then it is not even funny any more. ;)
UTF-8 usually makes everyone happy.
Glad you found it, good job! I would blame Marlin for the bug but escape the characters in the comment just to save everyone from problems.
TomasNielsen
on 10 Dec 2018
Maybe Cura should not put UTF-8 characters into those comments. Anyway, please leave this issue open so that a Cura dev can read what is here and decide what action, if any, is required. Cheers!
smartavionics
on 10 Dec 2018
Maybe Cura should not put UTF-8 characters into those comments.
Should Cura filter the model name before sending it to CuraEngine, or should CuraEngine sanitize the input it gets?
fieldOfView
on 10 Dec 2018
I created a Marlin issue so they are aware of the problem:
smartavionics
on 10 Dec 2018
Hey. I also have such a problem. But I'm afraid the problem is not in the characters. Throw off the files, can someone help you figure it out. Printer RepRap. Cura 3.5.9 worked fine, 3.6 refuses to work.
F_sern8st.zip
F_sern8 prints perfectly. Korona printed on 0.2 mm.
EgorkaDC
on 12 Dec 2018
Please try the attached gcode and if it prints OK, then the problem is the same as above. Thanks.
smartavionics
on 12 Dec 2018
Yes, definitely. This is my problem and you solved it. Thank you very much. Could you write how to fix this problem through Repetier?
EgorkaDC
on 12 Dec 2018
Will it be possible to continue using Cura?
EgorkaDC
on 12 Dec 2018
Just don't use STL file names that contain UTF-8 encoded characters. In your file, it contained the name '肖懈褕泻邪..stl'. If you just use file names with ASCII characters then you can continue to use Cura 3.6.
smartavionics
on 12 Dec 2018
Thanks again for explaining. I hope this topic will help a lot.
EgorkaDC
on 12 Dec 2018
Maybe Cura should not put UTF-8 characters into those comments.
Should Cura filter the model name before sending it to CuraEngine, or should CuraEngine sanitize the input it gets?
That all depends on where it is easier to handle. I'd guess the python side (Cura). Since I was responsible for including these mesh comments into Cura, I'll look into fixing. Unfortunately, it will have to wait till after the holidays.
paukstelis
on 19 Dec 2018
Easier is not always better. For me it is also easier to fix it in Cura than in CuraEngine, but I am partial to thinking that CuraEngine should sanitize the input it gets. On the other hand, CuraEngine does not seem to do a lot of sanitizing by design, so perhaps Cura is the better place.
fieldOfView
on 19 Dec 2018
For me i got the same problem ... hope it works by renaming the files.... Thanks so long...
ediciuStsaF
on 9 Mar 2019
I agree that CuraEngine should sanatise its output such that the printers don't crash on it, if it happens for most printers. You could argue that g-code needs to be ASCII only and then CuraEngine is generating incorrect g-code.
Ghostkeeper
on 11 Mar 2019
It seems that Ultimaker's printers (at least UM2 and UM3) don't exhibit this problem. Maybe we've done a fix for this a while ago, or maybe it's something that broke in Marlin ever since we forked off.
Ghostkeeper
on 11 Mar 2019
We've merged a fix for this in master (of the engine), so it'll probably be in 4.1
See here: https://github.com/Ultimaker/CuraEngine/commit/404760252f958d19b3b24f7e0d27717fd0be5bb0
rburema
on 14 Mar 2019
Related issues
thopiekar
路
3Comments
probonopd
路
3Comments
DmitryBychkov
路
3Comments
mubarak111nsu
路
3Comments
jellewie
路
3Comments
Most helpful comment
Great, that confirms the bug and it has to be one of the oddest bugs I've seen in a long time. The reason that the printer is not moving above 0.2mm is because the model file name is PluggM氓tt v1.stl. I know that sounds crazy but it's true. The problem occurs because Cura 3.6 inserts into the gcode comments that contain that name like this excerpt from you bad gcode file:
;LAYER:1 M140 S85 G1 F2100 E30.77954 M106 S127.5 ;MESH:PluggM氓tt v1.stl G0 F4500 X97.416 Y105.849 Z0.4 ;TYPE:WALL-INNER G1 F2100 E33.77954 G1 F3000 X97.284 Y106.229 E33.79559I'm guessing that the firmware in your printer doesn't like the 氓 character and somehow that confuses the firmware sufficiently so that the next line in the gcode gets treated as a comment. In the example code above the next line contains the move to the layer above (Z0.4)! and so the move never happens and the nozzle stays at 0.2mm for the whole print.
So a simple workaround should be not to use model files that have file names containing anything but ascii characters.
Is this a bug in Cura or a bug in Marlin or both?