Read total layers from gcode

[Jackal]

I believe RRF currently uses object height, first layer height and layer height to calculate total number of layers. However it is not incorrect for variable layer height prints.

Some slicers (at least in PrusaSlicer and Cura but not Kisslicer) can output total number of layers in the gcode file, will it be possible for RRF to parse that similar to reading other info from file?

[SIam]

@jackalin RFF 3.3 + the firmware reads only the Layers from the G-Code and does not calculate it anymore

[Jackal]

@siam Are you sure? I am printing a file with 295 layers but DWC is showing total of 140 layers. I am using RRF 3.3RC2.

First layer height 0.2 and total height is 27.980, which sounds like it calculated total layers from that.

[SIam]

@jackal yes see this post : https://forum.duet3d.com/post/231157

[Jackal]

@siam I believe what it means is that the current layer number is read from the file, but it does not say the 'total number of layers' is read from the file.

If I haven't read from the wrong branch of code, here is what's in RFF for reading number of layers

unsigned int GCodeFileInfo::GetNumLayers() const noexcept
{
	if (layerHeight <= 0.0) { return 0; }
	const float nl = (firstLayerHeight > 0.0)
						? (objectHeight - firstLayerHeight)/layerHeight + 1
							: objectHeight/layerHeight;
	return (unsigned int)lrintf(max<float>(nl, 0.0));
}

[SIam]

@jackal OK in this case the total layers will be calculated i was thinking that this will read from the file too because of the calculating problems what would be makes more sense

[AfroHorse]

I've just done the same investigation and come to the same conclusion looking at DWC and how it grabs the info from the RRF printmonitor.

DWC uses the height of the object to calculate total layers at https://github.com/Duet3D/DuetWebControl/blob/1121469e780d213df0cda6e85fbf1bb2000a8c33/src/store/machine/modelItems.js#L435. After some scanning around, it doesn't look like RRF passes back numLayers hence always dropping into this approximation logic. Please correct me if I am wrong on this.

Given it is dropping into that approximation, the specific issue is that height is not calculated correctly where there is a none print move. This is especially prevalent when you have ending GCode to move the extruder out of the way of the printed part. The logic to calculate the height is done in the printmonitor code at https://github.com/Duet3D/RepRapFirmware/blob/123d4362a04a709103971dd10b94e916b8790ef8/src/PrintMonitor.cpp#L145.

Must admit that having the height parsing logic look forward for subsequent extrusions would likely cause parsing to slow down considerably. Given this, I wonder if implementing the parsing of numLayers to pull it out of the GCode header with a specific format is the best way to go.