Wrong layer count shown - PRUSA i3 MK3S MMU2S

wabbitguy

LCD displays shows the current layer at 3 for the start of the print at the first layer.

http://www.wabbitwanch.net/sgphotos/Layer_Count.jpg

Repetier Server 0.94
PRUSA i3 MK3S MMU2S
Printing a single colour with the PRUSA multi-material mode.
Raspberry Pi3

http//www.wabbitwanch.net/sgphotos/MxTie3S_0.2mm_PET_MK3SMMU2S_3h4m.gcode

Repetier

Can happen depending on start gcode. For the server every extrusion on a different height then before is a new layer. We do not know the slicer layer counting and have own numbering. And prusa has always this purge line in front so that can already cause layer count to increase for a single move.

wabbitguy

I watched the start and that's exactly what it's doing. When it starts the purge, layer count is at 1. When it finished the purge line, the layer count was at 3.

Upon further checking, the purge line starts the purge at .40, then goes to .30 and finally ends the purge at .20 layer height. So that's where the server is picking up the three layers from.

Makes the "printing X/500 layer" LCD display pointless because it's not accurate.

Maybe a checkbox in a future version that asks if the printer does a prime line and subtracts "x" layers at the onset...:-)

Repetier

A checkbox makes no sense. You would need to ask for every upload since it might also have no purge layer or one only at printing height.
Layer count is still useful to feel progress. There are also other cases with variable layer height that makes it impossible to see Z from layer count. But for that you also have Z position available.

wabbitguy

I'm just reporting a bug. If it can't be fixed for whatever reason, just call it a bug that can't be fixed and leave it at that.

But make a note in the documentation that it's a "feel" feature only on some printers.

Rinaldo

YES, I also noticed this bug, I hope it gets fixed. Thanks.

Repetier

It is not a bug! It is just another definition of layer. Other slicers have even negative layers for raft. So they differ all but we need a consistent system in server that works for all gcodes. Server definition of a layer is a new height where extrusion occurs. We anaylse the real motion and reduce these to layers. PrusaSlicer does not count height changes in start code so we can differ here since we analyse the file as it is. It matches the preview in 2d preview with it's layer preview.

Pulp

Since the offset in layers is always the same - my Prusa starts the actual print at 2/n and ends it at n+1/n - would it be possible to add an offset-value to the printer-setttings? starting at -1 layer for every print would be an easy and effective solution for the Prusa problem?
Thanks for considering!

Repetier

That would be a hack. What if you then change the slicer or if the purge line has same hight as first print layer (I think it is the purge line with it's fixed z height that causes the extra layer)? And for vase mode it would also be differently. Plus preview in server also uses these layers so internally all is concise. I think the problem will be more or less fixed when the internal slicer is working.

Hansheld

warmup: actually i have the same issue with cura/X1. it always starts with layer 3.
could it be handled in cura somehow?

thx
Hans

Repetier

Rule in server is that every z height where new extrusion starts gets an own layer starting with 1. Some slicers even start with negative layer number if they have a raft. Then raft layers are not counted. So they tend to do what they like with internal logic, but our logic must depend on gcode alone to be compatible with all existing and upcomig slicers and changes.

So check where you have extra extrusions and make them happen on Z of first layer height and numbering will be identical.

wabbitguy

Would it be possible to add an "@layer_Reset" command (like in the dialog feature) where we could add a line to the end of the "start gcode" in our slicers to reset the current layer counter in RS to 0?

PRUSA does the prime in the -Y axis, so rather than trying to ignore any -X or -Y region layer counts, just a simple "@" command to RS to reset after the prime is completed might not require a massive amount of programming to accommodate.

Merely a suggestion.

Mel

Repetier

Maybe I could add an extra variable that sets offset. Then client knowing it would add offset to total layers and current layer. But it will be a big confusion when suddenly the number of layers changes while other clients show old value. Alone on our side we have 4 clients that would need to know that and still use internal layer count. On the other side if someone uses the server command he should be aware of this and accept that layer count may change at any time. On the other side in preview you would still need to use the original layer numbering from server - here we can not use faked numbers.

So my big question - why and where do you need the original numbers? I mean during print you see more layers and know when it is finished and in editor you still need the server numbering so no gain possible there.

wabbitguy

Repetier said:

So my big question - why and where do you need the original numbers? I mean during print you see more layers and know when it is finished and in editor you still need the server numbering so no gain possible there.

My short answer, simplification. My explanation, I'm using PRUSA Slicer with my printers (not all PRUSA printers) and I set filament changes in the prints, or pause points. In Slicer preview I see both the Z height and the LAYER that change/pause occurs at.

It's a light year easier for me to remember layers 29 and 38 than it is to remember 4.68 and 6.12 - Z heights. PRUSA's Slicer 2.3.1 shows the first layer of the print in the 3D view mode with layer 1 @ 0.2mm because the Slicer ignores the prime lines. RS shows layer 3. Close, no cigar...:-)

When showing the layer count on the PRUSA LCD that Repetier Server shows I have to remember to do math to make it fit what I see in PRUSA Slicer.

I'd find it much simpler if the two apps agreed. Hence merely the suggestion to allow an @command to set the layer count to match the Slicer preview mode.

Mel

Repetier

I see prusa has
;LAYER_CHANGE
as comment for layer changes. I think I will add in one of the next releases (not next, we are in finishing stage already) to use slicer comments when available to mark layer changes und use our system as fallback. That should also work fine on vase mode and for other slicers that have different rules.

wabbitguy

I just wandered through the GCODE generated from PRUSA's slicer and wow, I've never seen that many comments in GCODE before. Maybe they are doing it to make debugging easier for themselves.

I think you found an excellent approach to the layer issue. Looking forward to the future releases and thanks for having the patience to listen to us.. o:)