ChangeAtZ: at which layer or height exactly ?

[Erik_Es 3]

In the ChangeAtZ plugin you enter the height at which you want the change to happen, either by height or by layer number.

For a test print (I'm new to Cura 3, have been using 14.7 for years now...) I set the plugin to start the fan at layer 8 (so no fan for the first 7 layers). However, the fan then starts AFTER printing 8 layers, so at the start of the 9th layer.

This seems wrong, unless perhaps the layer numbers are the same as in the gcode, where the first layer (layer 1 in my book) is actually called layer 0.

 

To avoid this numbering confusion, it is perhaps better to use height instead of layer number. But that is also a bit confusing. For instance, let's say I want to print a bottom of 1 mm thickness without fan, then start the fan the moment it starts printing the next layer above that, which would be at height 1,2 mm (using layer height 0.2 mm). Which value for height should I then enter in the plugin ?

 

And do I have to take into account that the first layer is thicker ? So if initial layer is 0.3 mm and layer height is 0.2 mm, should I enter 1,3 mm in the plugin if I want to start the fan immediately after printing a "1 mm" bottom (which is actually 1,1 mm because of the thicker first layer) ?

(I have found (with Cura 14.7) that you don't have to account for this extra thickness (unless using layer height < 0.1 mm), because the action set in the plugin will happen in the first layer that reaches the set height OR goes a bit PAST the set height. But I am curious to know if it works like that in Cura 3.6 as well.)

 

So to condense this in 3 simple questions:

 

- does the plugin change the value at the start or at the end of the set layer number or height ?

- in the plugin, is the first layer called layer 1 or layer 0 ?

- when using height instead of layer number, do I have to adjust the value for the extra thickness in the first layer ?

 

 

 

 

 

Edited January 31, 2019 by Erik_Es

[gr5 2,265]

So this is a "post processing" plugin which means it looks at the same gcode file you can see with any text editor.  In a cura output are comments that you can read.  Here is a sample at the start of the second layer.  Lines that start with semicolon look at first.  Go ahead, do that now.  Notice that it says "layer:1" but this is the second layer.  Much higher up it says "layer:0".  Notice the 3rd line from the bottom ends with "Z0.47".  0.47 is first layer (.27) plus second layer thickness (.2) which are defaults.  If you search only for the letter Z in a gcode file you will quickly find just the layer changes (unless zhop is turned on).

 

So the plugin is much dumber than a person  - it looks for key words below: "layer" or "z" and extracts the number after that.  I believe it will insert commands after the line with the Z in it.  So answers:

1) start

2) 0

3) Yes - note that it will be greater than or equal to the threshold you set

 

If ZHOP is turned on it *might* fool the plugin.  Or the plugin hopefully is smart enough to search only for the first Z after a LAYER comment.

 

It's confusing!  I know!  Sorry!  I didn't write it.  But gcode is really simple once you play with it a few times and the author of the plugin kind of assumes you know a little gcode I guess?  I don't know.  Bad excuse.  Anyway the author kept the code as simple as possible so they just fine "layer" or "Z" look at the number and then insert the desired gcode.  the M106 is fan, M140 is bed temp.  F is speed in mm/minute.  G0 and G1 are both move commands.  E is extruder position.

 

G1 F1200 X109.105 Y115.638 E48.83473
G0 F7500 X125.44 Y116.44
G0 X125.675 Y116.675
;TIME_ELAPSED:91.942808
;LAYER:1
M140 S60
M106 S85
G0 F11250 X125.675 Y116.675 Z0.47
;TYPE:WALL-INNER
G1 F1560 X107.325 Y116.675 E49.15114
G1 X107.325 Y98.325 E49.46755

 

[Erik_Es 3]

OK thanks gr5. I was expecting it to be like that. So I will use layer number (which is much easier in most cases) and keep in mind to subtract 1 from the layer shown in the layer view.

 

Thought it would be good to get this clear, as it will be helpful as well to other people using this plugin and not getting why changes happen one layer later than expected.

 

BTW: I understand gcode reasonably well, but I try to avoid fiddling around in it myself. I'm quite wary of introducing errors that might cause damage to my printers...

 

If you would be so kind to check another topic I started, called "plugins not saved", that would be most helpful. Although I like 3.6 very much so far, it seems such a pity that these useful plugins can not be saved/loaded as part of the profile anymore. Hopefully this can be put right in Cura 4 ?

Edited January 31, 2019 by Erik_Es

[randyinla 14]

I, too, am trying to get ChangeAtZ (currently 5.1.1) to change speed at a specific layer for one layer.  Finding out that the gcode layer numbering is zero-based while the layer view in Cura is one-based was mind blowing!  I read through the github code and see it was originally TweakAtZ.  After so many updates, bug fixes, name change, supported Cura changes, no one thought to have the plugin automatically subtract 1 from each layer.  Thank you for the clarification gr5.

 

While looking through my saved gcode, the M220 commands are almost at the end of each layer.  Aren't the commands read from the file sequentially?  If so, wouldn't the speed change happen right at the end of the layer instead of the beginning?  Or does the gcode get read in layer by layer, analyzed by the machine, and then executed sequentially?

 

Here, you can see the ChangeAtZ M220 command, setting the speed to 20% just before the start of layer 22.  Each layer takes approximately 1-1/2 minutes to complete, so there are plenty of head movement commands before those M220s are found.

;ChangeAtZ V5.1.1: executed at Layer 21
M117 Printing... ch@L  21
M220 S20.000000
G0 F18000 X46.393 Y137.572
G0 X46.166 Y141.396
G0 X46.037 Y145.207
G0 X46.002 Y149.016
G0 X46.064 Y152.826
G0 X46.22 Y156.616
G0 X46.47 Y160.419
G0 X46.816 Y164.215
G0 X47.261 Y168.032
G0 X47.966 Y170.22
G0 X48.903 Y171.554
G0 X50.149 Y172.617
G0 X61.29 Y177.478
G0 X64.765 Y185.875
G0 X64.721 Y187.866
G0 X64.976 Y189.419
G0 X65.624 Y190.91
G0 X66.619 Y192.189
G0 X67.909 Y193.19
G0 X159.666 Y194.545
;TIME_ELAPSED:2658.809868
;LAYER:22

 

[gr5 2,265]

I'd love to see the line above what you showed.  I suspect it has a "Z" in it where it changes the layer height maybe?

 

Anyway, each line of gcode is executed and then it goes on to the next line.  So the 20% feedrate happens at that point where the M220 is.

Why is there no extruding going on after the speed change?  I don't know.

 

[randyinla 14]

Here are maybe 40 lines just before what I posted above, the line just before the ChangeAtZ comment has a "Z5.75":

 

M204 S500
M205 X25 Y25
G1 F900 X163.48 Y192.879 E132.41651
M204 S5000
M205 X30 Y30
G0 F18000 X69.127 Y193.557
G0 X67.224 Y192.722
G0 X66.07 Y191.563
G0 X65.26 Y190.196
G0 X62.585 Y179.072
G0 X55.077 Y173.949
G0 X52.41 Y173.548
G0 X50.858 Y173.019
G0 X49.491 Y172.124
G0 X48.392 Y170.917
G0 X47.632 Y169.481
G0 X46.816 Y164.215
G0 X46.47 Y160.419
G0 X46.22 Y156.616
G0 X46.064 Y152.826
G0 X46.002 Y149.016
G0 X46.037 Y145.207
G0 X46.141 Y142.121
G0 X45.09 Y135.08
G0 X44.847 Y135.322
M204 S500
M205 X25 Y25
;TYPE:SKIN
G1 F1800 X44.339 Y135.277 E132.43174
G1 X42.733 Y135.219 E132.47972
M204 S5000
M205 X30 Y30
G0 F18000 X42.483 Y135.469
G1 F2700 E126.97972
;MESH:NONMESH
G0 F600 X42.483 Y135.469 Z5.75

Is it safe to just move the M220 command to happen directly after the ";LAYER:21" line and then the reset of M220 S-1.000000 just before the next ";LAYER:22" line?

 

(funny how there's not a "gcode" code language option when inserting code)

Edited April 30, 2020 by randyinla

[randyinla 14]

I moved all of the M220s to start the line after ;LAYER:xx and reset the speed on the line before the next ;LAYER:xx

;LAYER:21
M220 S20.000000
.
. movement n stuff
.
M220 S-1.000000
;LAYER:22

 

The M220 S20.000000 worked perfectly!  I'm so happy about that.

 

But the reset of "M220 S-1.000000" didn't do anything.  The display still shows the speed as 20%.  When I look up the M220 command, resetting back to 100% is "M220 S100", not "M220 S-1.000000".  I'll update the reset for the next round of printing.

Edited April 30, 2020 by randyinla

[randyinla 14]

To reset the speed back to 100%, "M220 S100" works.  Strange the ChangeAtZ plugin uses "M220 S-1.000000" when it (seemingly) does nothing on the machine.

[gr5 2,265]

That looks like a bug.  Negative 1 doesn't have a meaning in the feedrate multiplier.

 

Anyway, it looks like you answered your own questions.  Note that the M220 was inserted right after the line with the Z5.75.  It's that 5.75 that determines where to insert the new gcodes.

 

So if you tell it to pause at 5.75 or 5.74 (or other smaller values), the first time it sees a "Z" value > than what you entered in the post-processing-script - that's where it inserts the new gcodes.

[randyinla 14]

This plugin started life as TweakAtZ and though it has a new name, it's still ChangeAtZ, so it makes sense that it would scour the code looking for commands that include Zx.xx and insert there.  However, perhaps Ultimaker didn't insert the ;LAYER:xx comments in the gcode back when the plugin was first created?  Perhaps the plugin needs to change its code scouring methods?  I setup the plugin to go off of layer numbers, not height in mm, but I understand what you are saying.  Perhaps the plugin still calculates the mm height off of the layer number and then looks for the Zx.xx, but it's still inserting the command in the wrong layer regardless.  In the screenshot, I really need it to be layer 22, but have to set it to layer 21 because regardless how the plugin looks for the right place to insert itself, it ends up being placed in the next layer in the code.  I open the saved gcode in a text editor and manually move things around and get rid of all the M117 display commands (don't need the display to tell me it changed something and require me to hit the button to dismiss).

 

I assume the ";LAYER:xx" comments in the gcode designate the beginning of each layer.  If so, then that "Z5.75" line was about 22 lines from the end of a layer that contains 2,379 lines, putting the ChangeAtZ command at the end of the layer as well.  Could it be Ultimaker inserts the Z5.75 line to change the z axis for the NEXT layer and the next 21 lines or so are head movements to go to the start of the next layer?  Point being that not only is the 1-based indexing of the gui compared to the 0-based indexing in the gcode putting the ChangeAtZ command 1 layer too late, but if it looks for the z line in that layer, (which in my case is happening at the end of a layer), then that makes the ChangeAtZ command pretty much 2 layers late for everything, not just my speed changes (unless it uses different methods for insert other types of changes.  I have only tried the speed changes).

 

By manually editing the code so the ChangeAtZ command happens at the very next line after ;LAYER:21 and the reset speed command at the line just before ;LAYER:22, the speed changes happen precisely where I expected them to be when the print is actually printing.

 

But yes, in any case, I now have the speed changes where I want them and have a better understanding of M220 commands and where to place them so they work as I think they should.  Makes me want to write a plugin just for this use case just for me 🙂  "ChangeSpeedForLayer".  Ultimately, it'd be awesome to run the layer head movement animation on the Preview page and pause it right were I want a change, then be able to grab the line of gcode that movement happens at and insert there.  Unless the gcode is generated when clicking the "Save to File" button, which means it wouldn't be available to the Cura gui yet.  Would be a good feature for Cura to add.  Pause the layer preview playback, right click on the head in the layer view and select, "Insert speed change" and/or "Insert fan speed change" for tricky bridging passes.  Much better than trying to make it conform to the master settings list.  Doing it this way, Cura could then take into consideration speed changes and calculate a proper time for the print.  Having the post processing plugin add speed changes makes the estimated time useless.  My print is estimated at 6hrs 33min, but actual print time is closer to 7+ hrs.

Edited May 2, 2020 by randyinla

[Erik_Es 3]

Nice to see this topic is not just bothering me but at least one other person... 🙂

Once you figure out how to use the plug-in, it's not a real problem. But the approach is very counter-intuitive, so I guess most people who use this plug-in never notice the changes occur one layer later than they should, and in most cases that doesn't really matter much for the print that comes out in the end. But in some cases it does...

@randyinla: I don't think you can blame Ultimaker for any errors or unclarities in this plug-in, because (if I understand correctly) these plug-ins were/are built and shared by users, not the company.

However, a much bigger problem is the fact that in the newer versions of Cura there is no way to save a print profile that holds the settings for the plug-ins you use. Instead, the plug-ins are now completely separated from the profiles, which means that if you need a plug-in for a certain print which you want to print again and again later (as I often do for my shop). that  each time I want to print that thing I need to activate the plug-in and set the settings, which I apparently need to write down in a little black book now because there is no way of saving them. Such a pity. One of the reasons I still keep using 14.07 for a lot of prints. Very silly that that is necessary. So easy to fix...

 

And to make matters worse: if you use a plug-in for a print, and then go on with another print, you might find that sadly the old plug-in still kicks in and ruins your print, because once you set one it will stay active until you switch it off yourself. Recipe for disaster...

 

[Erik_Es 3]

14.07 has none of these problems. All the newer versions (Cura 2 and up) do. 

Also: setting up multiple prints (by using Multiply Object) worked like a charm in 14.07 and has been COMPLETELY f***ed up since then. Placement and print order are a mess. I have to manually make objects switch places to get the right printing order. WHY ????

 

[randyinla 14]

Quote

@randyinla: I don't think you can blame Ultimaker for any errors or unclarities in this plug-in, because (if I understand correctly) these plug-ins were/are built and shared by users, not the company.

Oh, I wasn't blaming Ultimaker at all!😲  I think the plugin developer, developing specifically for Ultimaker-created gcode, should be more on top of where it inserts changes into Ultimaker gcode.  I simply suggested/wondered if the ";LAYER:xx" comments (generated by Cura) were not initially inserted by Ultimaker/Cura way back when the TweakAtZ (now called ChangeAtZ) plugin was first created and that if so, now there seems to be a better marker to search the gcode for layer changes.  I do have some rather old gcode on my U2 memory card.  Maybe 6 years old.  I can take a look at those to see if they have ;LAYER:xx comments or not.

 

I hadn't thought about the extensions not being saved before.  I've only used them for this print.  Makes sense to include them in a profile of some sort.

Edited May 2, 2020 by randyinla

[Erik_Es 3]

Yes, it did make a lot of sense. No clue why they dropped that.

I've tried all versions for the last 7 years, and I still find that 14.07 is like the VW Beetle of Cura's. OK it might not be as fancy as the latest one. That has 300+ parameters you can control, which is very nice on one hand, but good luck testing them all properly to see what works and what doesn't for each type of print...
14.07 has no airconditiong, no GPS, no ABS, etc etc but at least everything WORKS, ALWAYS, exactly how you want it to, which I can't say for any Cura after that one. Progress is not always just improvement, it seems.

Very weird about the later versions is that although most of these 300+ settings are hidden by default, they are still doing stuff behind the curtains that can really f**k things up. For instance, it took me ages to figure out that there is a "infill before walls" checkbox (in the hidden parameters for infill) that is set to ON by default. Digging out that parameter and unchecking that box DRASTICALLY improves the print quality for most prints that use infill >0 and <100 (so that's about 90% of prints...). If you haven't yet, try it out. No more infill visible through the shell. Gone as if by magic. A silly parameter, AND set to the wrong default, AND extremely well hidden in the Forest Of Parameters...

[randyinla 14]

I, too, usually uncheck the infill before walls checkbox on most prints.

[Erik_Es 3]

And so you should, well done. 🙂 👍 But how many people are using the latest Cura, unaware of this hidden parameter (in my book "hidden" should mean "de-activated"...) and wondering why they keep seeing those awful infill lines on the outside of their prints, I wonder...

[Erik_Es 3]

By the way, you said "most prints". Does this mean you actually found a proper use for printing infill before walls ? I haven't...

 

[randyinla 14]

Supposedly, printing infill before outer walls creates stronger walls, though the infill shows through the outer wall.  If I'm more concerned with strength over looks, like with a bracket or some other utility part that needs to be strong, I'll opt for infill before outer walls.

[Erik_Es 3]

Yes, now you mention it, I heard that argument or a similar one before. I guess that by printing infill before walls, with plenty of overlap, the ends of the infill walls will sort of get entwined between the wall layers. I can see how that might improve the connection of the infill to the walls, as with normal "walls before infill" the infill only gets squashed against the inside of the wall, not crossing it - although you can get a similar effect by using a high value for infill overlap, which then actually has the same effect with a much less detrimental effect to the surface quality.

So maybe the builders of Cura assume that most users need strength above quality, which I don't think is the case. One way or the other, the fact that this parameter has so much effect on print quality while being hidden from view by default seems like a big mistake to me.

[Erik_Es 3]

Thought about it a bit longer. The more the end bits of the infill lines get entwined between the wall layers (improving wall to infill connection), the more the wall lines will actually be interrupted by hitting these overlap bits, which then decreases the strength of the wall itself. I guess.

I would like to see some proper strength tests to see which is better. If anybody reads this and has done such tests, please leave a message. Or else I will do it myself - SOME day, because I have a million other things I want to test as well, and only so much time in one day...

[Erik_Es 3]

To finish on a happy note: I LOVE the option in the latest Cura's to use a bit of negative horizontal expansion on the initial layer to prevent even the slightest traces of elephant's foot. VERY happy with that !

 

[randyinla 14]

I create most things I print in Solidworks and add a little chamfer to the build plate edges for that very reason.  Will have to play with horizontal expansion on the first layer now.

[Erik_Es 3]

I used to do that too. Using that negative horizontal expansion means you don't have to bother with that anymore for most prints, so it saves a lot of time.

 

[Erik_Es 3]

I use a value of -0.2 to -0.3, depending on how close I'm printing the initial layer. For a "tight" initial layer (so the actual nozzle to plate distance being slightly less then the initial layer height set in Cura) use -0.3 or even -0.4 (with a 0.4 nozzle), for a "looser"initial layer -0.2 appears to be enough.

 

[gr5 2,265]

LAYER OFF BY ONE

 

So you have to understand a tiny bit about programming - most programming starts loops and arrays with zero (not 1).  So the GUI might count the bottom layer as "layer 1" but most software thinks of the bottom layer as "layer 0".

 

I believe the plugin is "zero" based meaning it starts at layer 0.  This is mostly a guess.  I have never tried the plugin and I have not looked at the code.

 

The error might actually be in the GUI and not the plugin (the gui might refer to the bottom layer as layer 1 might that might be considered a bug).