Cura: print speed get reset to 10% if changeATZ and 2 items are gonna be print

[bucefalo2]

Hello , if i choose to print 2 little items "ONE AT THE TIME " (special modes )
and i've active a post processing plugin like :
"CHANGEATZ ... change speed after one layer "

once printer ends the first item it'll start the second item but speed goes at 10% and it becomes extremely slow, so i need to enter printer settings and manually increase speed tune control !

Application version
Ultimaker cura 4.6

Platform
Windows 10

Printer
Ender 3

Reproduction steps

1. print 2 items " one at the time " (special modes)
2. use plugin : " changeATZ " change speed at layer number ...

Screenshot(s)
http://www.simiweb.net/ender3.jpg

Actual results
first item is printed correctly and speed will change as i set it up ! when second item begin to be printed speed will go at 10% extremely slow

Expected results
(What should happen after the above steps have been followed.)

Project file
(For slicing bugs, provide a project which clearly shows the bug, by going to File->Save. For big files you may need to use WeTransfer or similar file sharing sites.)

Log file
(See https://github.com/Ultimaker/Cura#logging-issues to find the log file to upload, or copy a relevant snippet from it.)

Additional information
(Extra information relevant to the issue.)

[Ghostkeeper]

The ChangeAtZ post-processing script inserts the M220 command, such as M220 S106. It inserts it only once, when the height first goes above your desired change height (layer 14). It doesn't currently reset when you go back to layer 0 for the second object. I'd consider that a bug.

However I'm not seeing your bug. It just inserts the M220 at layer 14 and doesn't do anything to slow down the first layer of the second object. I just get an M220 once and that's it. The speeds are unaffected at layer 0. Do you have a project file (File -> Save...) that reproduces the problem?

[bucefalo2]

hello

sorry for the late reply !

it actually happens with any stl i tried so far !

so when it starts second item it'll print extremely slow maybe i can show u a little video of the issue ? or you just prefer stl?

Il 20/07/2020 14:16 Ghostkeeper <[email protected]> ha scritto:




The ChangeAtZ post-processing script inserts the M220 command, such as M220 S106. It inserts it only once, when the height first goes above your desired change height (layer 14). It doesn't currently reset when you go back to layer 0 for the second object. I'd consider that a bug.

However I'm not seeing your bug. It just inserts the M220 at layer 14 and doesn't do anything to slow down the first layer of the second object. I just get an M220 once and that's it. The speeds are unaffected at layer 0. Do you have a project file (File -> Save...) that reproduces the problem?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/8075#issuecomment-660990744 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFKI3CIVFXY6IEQHKOQ2CTR4QYTBANCNFSM4O52MIPA .

[Ghostkeeper]

I would still prefer a project file. You can load up a simple cube in the scene if that reproduces the problem. I believe you that it happens, so "video evidence" is not really necessary :wink: and probably won't show me anything new.

What I really need to know is whether it's Cura doing something wrong or the firmware, and if it's Cura, what is going wrong. So with that project file I can reproduce your g-code and see if there is anything in that g-code that would make it slow down. If I can find the mistake in the g-code, I can use the project file to trace down where that mistake comes from. If there's not, I'm blaming the firmware.

You could also look for yourself through that g-code if you can find a mistake that Cura made. You'll find a ;LAYER:0 where it starts with the second object. The F parameter determines the speed in mm/min. Typically that's in the range of 600 to 3000 or so for the first layer (10 to 50mm/s). You'd also have to take into account the preceding M220 commands that can alter the speed.

[bucefalo2]

hi sorry for slow reply,

i'm gonna do that sort of print now ( 2 items ... ) and send you Gcode

thank you :-)

p.s.i tried to send little video but email comes back ...
so i just sent gcode , thank you

[Ghostkeeper]

If you want to attach something to your post, you'll have to go to your issue page online and submit it there. Attachments to e-mail replies don't get shared on Github, so I can't see that g-code. You'll also have to put it in a .zip to get it submitted on Github.

I asked for the project file though, not the g-code. You can save a project file by using File -> Save... The result is a .3mf file with extra information about the settings that you were using to slice.

[bucefalo2]

sorry i didn't know that ! , here it is the 3MF file
CE3_Car Led Clip Final_NEW.zip

[JohannesVanTongelen]

Having the same issue, during the multiple hour prints, what gcode can i use to set printspeed back to 50mm/sec?

[JohannesVanTongelen]

Here is the file in case you want to look at the code.

[Ghostkeeper]

When I slice your project I get the following change by the Change At Z script:

;LAYER:9
;[CAZD:
M220 S106 T1
;:CAZD]

This only happens for the first object, so I'd expect that the rest of the print as well as the complete other object would print at 106% speed. So indeed it doesn't reset to 100% for the second print, which was already established earlier. That's a bug. We had discussed it and don't want to give that bug priority over other issues. But it's not really your problem.

When it starts with the next object, it prints this g-code:

;LAYER_COUNT:113
;LAYER:0

M117 Layer 113 of 113 CE3_Car Led Clip  Final_NEW
G0 F4500 X144.911 Y62.148 Z0.2                ; Travel move at F4500
;TYPE:SKIRT
G1 F1500 E867.10422                           ; Unretraction at F1500
G1 F2400 X145.345 Y61.336 E867.13485          ; Start printing a skirt at F2400.
G1 X145.848 Y60.565 E867.16546
G1 X146.417 Y59.841 E867.19609
G1 X147.045 Y59.169 E867.22668

So it should be printing at F2400 (which is 40mm/s), but adjusted with that M220 to 42.4mm/s. Could the firmware be at fault here? The g-code looks fine to me. Cura isn't generating particularly slow movements.

@JohannesVanTongelen you seem to have forgotten to upload the file.

[JohannesVanTongelen]

TP1002_Bovenste Schaal BuitenKant.zip

Ghostkeeper, file now uploaded, (was not aware that .gcodes needed to be zipped).
If you need more info let me know.

Used
changeAtZ layer 2: to 50% from 50mm/ss when printing the speed got to arround —> 25mm/ss
After that de speeds reduced to 3,75 mm/ss when I reached layer 6.

Using Duet board on Modix printer. 60cm X 60cm Y and 66 cm Z
Cura version 4.6.1

[Ghostkeeper]

Did you edit that g-code? It starts at layer 19.

Can I see a project file instead of the g-code? You can create a project file by going to File -> Save... The project file contains your scene and all of the settings and post-processing scripts used for your print.

[JohannesVanTongelen]

Did you edit that g-code? It starts at layer 19.

Can I see a project file instead of the g-code? You can create a project file by going to File -> Save... The project file contains your scene and all of the settings and post-processing scripts used for your print.

Here you go.
TP1001_ProjectSettings.zip

[Ghostkeeper]

Looks like the "Target Layer Only" setting is not working correctly any more. You've stacked 3 Change At Z scripts together that each halve the print speed, so indeed the printer would then end up at 12.5% print speed. However the scripts are said to apply to the target layer only, but that feature doesn't seem to work correctly.

Thanks for the bug report. I'll see what my colleagues think of the priority.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[Ghostkeeper]

This got snowed under a little bit. Our meeting notes say that we would investigate this issue for two hours but it didn't say who would be doing that...

[Ghostkeeper]

This is fixed for 4.8: https://github.com/Ultimaker/Cura/commit/69b855f298d0e1ede5dcdf15d6a345298e8185ff