Layer count - variable height

[Phaedrux]

Yes that's a known issue when the slicer doesn't indicate the total number of layers and the layer height varies such as with variable layer height, or combined infill layers, or support layers having a different height than print layers.

Perhaps @chrishamm can indicate what if anything could be manually added to the print file to work around it.

[PetrKroupa]

@phaedrux - I thought it was like that. I believe that I can force the slicer to add a layer counter, the total height and quite possibly the total number of layers. What matters is what the added line / code should look like.

Thanks.

[chrishamm]

@petrkroupa AFAIK no slicer reports the total number of layers yet so RRF/DSF try to compute the number of total layers from the average layer height and total object height (last Z position). To make things worse, PrusaSlicer reports a layer change when it switches to support so DWC tends to show more layers than previously computed. Once we have standard G-code comments that contain the total number of layers, it should be straight-foward to populate the job.file.numLayers variable correctly.

[oliof]

Kiri:moto reports the current layer number and the total number if layers via variables you can use in custom per layer and end gcode settings. In my testing I had to add both to get layer reporting in

[PetrKroupa]

@chrishamm - In prusaslicer we can use "total_layer_count". Prusa Knowledge. But if it firmware not look for it, it's useless.

IMHO Each height value at which it is printed is another layer. It doesn't matter if it's a support or something else. It's a matter of opinion.

[chrishamm]

@petrkroupa Thanks, I wasn't aware of that one. I'll discuss with @dc42 if we can add support for a new comment like

;NUM_LAYERS:[total_layer_count]

anytime soon.

Is anyone else aware of other default total layer comments for other slicers like Cura or Slic3r?

[PetrKroupa]

@chrishamm - In theory, most slicers can add the number of actual layer. And the last one (the biggest number), at the end of gcode is the total number. But that would no longer be such an elegant solution. Just a quick idea....

[dc42]

@petrkroupa is the number of layers and current layer number useful for anything, especially when variable layer height is used? Wouldn't current height and total object height be more useful?

[PetrKroupa]

@dc42 - Good question. And I agree. Overall, showing only the current and target height is an elegant solution. At least for me. Someone else may have a different opinion. It would be ideal to have a choice. Somewhere in "machine specific" some switch? I believe that would solve this problem forever. It is simply strange to see at the end of the print that the number of the current layer is greater than the total number of layers.

[pfn]

@dc42 The removal is somewhat of a bummer, I use numLayers to determine when to modify PA values in my calibration script, e.g.:

Now, instead, I have to pass in total layer count on every layer change, not blocked, just less elegant.

var begin = 0.030
var end = 0.060
var increment = 0.003
var layer_count = 0

if !exists(job.file.numLayers)
  if !exists(param.L)
    abort "Missing layer count"
  set var.layer_count = param.L

var step_count = {floor((var.end - var.begin) / var.increment)}
var layer_step_size = {floor(var.layer_count / var.step_count)}
if mod(job.layer, var.layer_step_size) == 0
  var steps = job.layer / var.layer_step_size
  var pa_value = {var.steps * var.increment + var.begin}
  echo "Pressure advance set to " ^ {var.pa_value} ^ " at layer=" ^ {job.layer} ^ " for " ^ {var.layer_step_size} ^ " layers"
  M572 D0 S{var.pa_value}

It's called like so in my layer change custom gcode settings:

M98 P"k/pressure-advance-calibration.g" L[total_layer_count]