Posts made by 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 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.

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?

I can now get the current layer, but it is reporting the wrong total layers since I am using variable layer height.
Found [total_layer_count] in prusaslicer placeholder but don't know what keyword RRF use to read total layers.

update: Looked through the source code and it seems that it is currently calculated instead of directly reading from the file.

@jay_s_uk
Thanks, will try that when I get home.

@phaedrux test.gcode

I haven't tried the E after ; thing yet, but everything used to work fine with the same start and end gcode.

@phaedrux The layer change portion looks like this

;LAYER_CHANGE
;Z:0.6
;HEIGHT:0.2
G1 Z0.600 F12000.000
G1 X-0.799 Y92.614
;TYPE:Perimeter
;WIDTH:0.45
G1 F1800.000

I am using RRF and DWC 3.3RC2 on my Duet 2 Wifi, but I think my problem is more related to slicer rather than the firmware.

I haven't been able to see the layer time or current printing layer for some time though the prints are fine (sliced with Prusaslicer). Have tried searching for related topic but all I found is putting E after ; in the gcode to exclude it from layer count.

I remember seeing posts on what RRF actually reads in the gcode to determine layer info but couldn't find it anymore (keyword probably too generic). Can someone tell me again what syntax is required so I can put it in the custom layer change g-code

@dc42 It's now working with 3.3RC1+1. Thank you.

@dc42 Thanks for the quick follow up.

@dc42 said in [3.3-rc1] Sensor issue with M308:

FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.3RC1 ELECTRONICS: Duet WiFi 1.0 or 1.01 FIRMWARE_DATE: 2021-05-01 09:58:08

I have upgraded my Duet 2 Wifi from 3.3-beta2 (or maybe another 3.3-beta) to 3.3-rc1.
Both my bed and hotend sensors are thermocouple and after the upgrade both seems to have failed to work.
I am getting "string too long" error when using this command the config my thermocouple: M308 S0 P"spi.cs3" Y"thermocouple-max31855"
I saw the bug-fix "Thermocouple sensors could not be configured because M308 didn't accept more than 20 characters in the sensor type name" in the changelog. I would like to know if it is really fixed or I have done something wrong with the command which works fine before?

These are my sensor config:
; Bed sensor and heater
M308 S0 P"spi.cs3" Y"thermocouple-max31855"
M950 H0 C"bedheat" T0
M140 H0
;M307 H0 R1.319 C80.7 D3.06 S1.00 V24.2
M307 H0 R1 B1

; Hotend sensor and heater
M308 S1 P"spi.cs2" Y"thermocouple-max31855"
M950 H1 C"e1heat" T1
M307 H1 R2.643 C168.0 D3.48 S1.00 V24.1

@theruleslawyer Some slicer allow you to set a minimum layer time so that it will slow down the print, there may also be an option to set a percentage of minimum printing speed on top of that since a very slow print may lead to the hotend staying too long at a spot.

@mike Just want to know what retraction speed are you using?

0_1553613727447_heightmap.csv
Delta height map

I am not good at maths, but remember this from the reprap wiki
https://reprap.org/wiki/Delta_geometry#Quantifying_the_effects_of_the_geometrical_stability:_TES_coefficient

In earlier 2.03beta versions, if you auto-calibrated a delta printer then the motor positions were slightly wrong afterwards until you homed the printer

That's probably why I have been having weird height map when no hardware on the printer has been changed.

I am very careful with the more obvious stuff, just not sure when it involves adding resistors/dioides or splitting the +ve -ve connections.

Thanks for the VFAN jumper 5v suggestion, that makes the wiring a bit cleaner

Just to report that I have connected my two 5v fans in parallel and +ve to on board 5v and -ve to Fan2-
Everything seems to working fine, tested with M106 P2 S255.

So worried that I was gonna fried the board, I killed the thermistor fuse not long after the board arrive so please bare with my paranoia.