Think I have found a bug.

dc42

Please provide the whole of the GCode file you are printing. What firmware version are you using?

PaulHew

Morning David

Ender3 with Maestro
Board: Duet Maestro 1.0
Firmware: RepRapFirmware for Duet 2 Maestro 2.03 (2019-06-13b2)

Railcore with Duet
Board: Duet Ethernet 1.02 or later + DueX5
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.03 (2019-06-13b2)

Maestro File
CE3_Stabilizer.gcode

Railcore File
CFFFP_Stabilizer.gcode

Thanks David.

P.

Edit : Even in Cura it shows only 30 Layers in both Printer profiles.

droftarts

This usually happens when you have z lift enabled in the slicer, but at a different height than the layer height. It does usually just double the number of layers, though. I haven’t looked at the Gcode files.

Ian

PaulHew

Good call, but I do not use Z hop, just checked both profiles.

dc42

It's this line in the end GCode of the Maestro file:

G1 F3000 Z20 ; Move Z Axis up 20 mm to allow filament ooze freely

In the RailCore file you have this instead:

G1 E-1.0 Z+10.0 F1000.0 ; E : Nozzle Up/Bed Down 10mm and retract - (E to exclude from layer count)

The "; E" makes all the difference.

PaulHew

@dc42 Did not mean to alarm you.
Learnt something new today! I thought Layers were Layers.
Did not know that the end GCode section can change the way it displays or calculates layer count.

I found it in the slicer end GCode section.
I just copied it from some where for the Ender3 maybe from Phaedrux , and the same with the Railcore, from someone on the Railcore Discord channel.

I shall look at it with the GCode guide and see if I can learn something.

Paul.

chas2706

Hi
I don't mean to sound so negative but I will be surprised if you find the answer. Ive given up on it and just accept that the layer count and filament usage is just garbage.
All of my prints report a max total of 25 layers, whether there is actually 10 layers or 10000.
PanelDue is brain dead too. It measures time left and filament used in minutes and seconds and does not have a clue about the layer number.
See photos:

nhof

The reason for this problem in the first place is that the machine really is 'dumb'. Unless there is something telling it explicitly what the layer height, number of layers, etc. is then it's a guess at best.

In the example that David explained, RRF extracts the layer height of 0.2mm from the Cura g-code header. Unfortunately the number of layers isn't available in the header, so it looks for the last Z move of the file and assumes that the end position of the last Z move is the max Z height of the part. It's wrong in this case because it's a post-print Z move for clearance. Other things such as variable layer height can also easily destroy the estimate.

Unfortunately the print information in g-codes is usually in human-readable format and is missing key values so it's pretty hard to parse. Additionally slicer software devs will tend to change these up on a whim, breaking the parser. Quite a bit of effort has gone into the file parser but it's still imperfect.

An actual non-hackish solution to the problem would be for slicers to implement standardized g-codes (for a layer change, part change, etc.) and/or standardized machine-readable tags (xml etc.) in the g-code for all necessary layer/filament/object info. But getting anybody to agree on standards in the 3D printing world is like herding cats.

Hope this clears up why the problem exists. It's pretty clear to me that the real issue is lack of machine-readability / standardization on slicer's g-code output, rather than the firmware itself.

zapta

Looking at Cura code at https://github.com/Ultimaker/CuraEngine/blob/master/src/gcodeExport.cpp

It has things such as

*output_stream << ";LAYER:" << layer_nr << new_line;

*output_stream << ";LAYER_COUNT:" << layer_count << new_line;

prefix << ";PRINT.SIZE.MAX.X:" << INT2MM(total_bounding_box.max.x) << new_line;

Are layer marker and count as well as total print height included in the Cura output? If so, they can use to estimate the Z progress.

DocTrucker

@zapta I would imagine they want to avoid too much slicer specific gcode.

However, I think most slicers are able to output conditional gcode at the start, end, and before and after layer changes.

Perhaps we as duet users agree to put a header comment such as:

;USES LAYER IDENTIFIERS

...and on layer change:

;END OF LAYER 0

Where 0 increments by 1 for each layer number.

In the mean while identifying a build position by height, or running a simulation before the print should work around whatever issue the layer number was needed for.