ChangeAtZ: at which layer or height exactly ?

[Erik_Es 3]

I'll run a few tests to sort things out. It IS a very useful plug-in...

 

 

Edited May 4, 2020 by Erik_Es

[randyinla 14]

I'm a sr. software engineer.  I've already created my own post processing extension over the weekend (calling it SpeedChangeByLayer) that changes print speed or fan speed per layer, not by z-axis movements.  Started with the ChangeAtZ script, removed everything except print/fan speeds, then yanked out everything dealing with trying to find/calculate the z-axis movements and restructured the code & storage structure.  Instead, it now looks for the ;LAYER:xx comments, inserting the start of the change just after the proper layer (subtracting 1 from the Cura gui layer number, which ChangeAtZ does not do) and the reset just before the next ;LAYER:xx comment.  Currently, my code is messy as hell but works perfectly for a single layer.  Can insert multiple instances of it to affect multiple layers.  Also, the percentage change for print speed is always is a percentage of the original speed, not of the instance before it.  ie.If 1st change = 50% & 2nd change = 20%, the 2nd is 20% of the original speed, not 20% of 50%.  Not sure if I'll submit it or not.  I want to change the fan speed to work as a percentage instead of having the user enter the PWM number from 0-255 and also need to tweak the fan speed routines so it can work across a span of layers.  "Start speed change at layer 10 for a total of 5 layers".  Currently, that only works with the print speed.  Since the print speed change is a %, like changing the speed from the machine's panel during printing, I can always reset it back to 100% at the end of the layer(s).  With the fan speed, it can be different on each layer as in, "ramp up to 50% speed over 10 layers" in Cura.  So I have to first scan the entire layer for a fan change, M106 or M107, store it, then reset the fan to that speed at the end of the layer.  It's like moving the existing fan speed to the end of the layer, getting it out of the way so you can override the layer with your setting from the extension. (Keep wanting to call them plugins, but technically, they are extensions working under the post processing script)

Edited May 4, 2020 by randyinla

[randyinla 14]

1 hour ago, gr5 said:

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).

 

 

I wouldn't say the gui has a defect.  End users want to see the first  of something labeled as "1" not "0".  The code has to start at 0 due to the way Arrays are 0-based in the programming language.  The defect is that the plugin must subtract 1 from the number entered so it can insert the change into the correct layer in the code.  It's a common thing that has to be done on almost every interface to anything.

Edited May 4, 2020 by randyinla

[BigAlGeorge 1]

I wonder if Im barking up the wrong tree.

Doing a Cura temperature tower from its extensions where you have to enter various temps by using changeatz post processing.

What Ive been doing is assuming that a sliced view progress control on right is moving by layers so working on each area of the tower layers were appromately 44 each for this particular temp tower and each point of temp change.

 

There seems no switch for height with this control or am I doing it all wrong, but getting the right result?

[GregValiant 1,251]

For the Temp tower, if you are off by one layer, it will continue all the way up.  It isn't cumulative.  If you enter 44, 88, 132, etc. and the temperature actually changes at 43, 87, 131 it's no big deal.

 

It becomes a deal for me when using PauseAtHeight and changing colors when the main model ends and the text begins.  That sort of situation requires that the layer number is exact.  I always double check the Gcode to make sure I got it right.  It only takes a few seconds to have Cura open the folder and for me to double-click on the file and then search for (in my case) M0.  It's cheap insurance.  I would be happier if it was more intuitive, but base 0 is what we have in gcode layer numbering in every slicer except Simplify3D.

 

ChangeAtZ and PauseAtHeight have (or had - I don't know if they've been fixed or not) the same issue when trying to do things "by Height".  Z-Hops and adaptive layers fooled them.  Both work a lot better when "by Layer" is used.

 

You can't be "doing it wrong" if you are getting the "right results".  Sister Mary Elephant isn't likely to show up and ask for your proofs.