A quick update:

Excuse me for taking so long to test things out, i have a lot of work to do at the moment so i have very little time for 3D-Printing.

My last few prints have been printed with the first extruder only, and so far the issue has not appeared again. I hope that helps a bit in diagnosing the issue, i will also try the new firmware next week when i have a little bit more time.

As a sidenote, thank you very much for the support so far, and for putting up with my slow testing

@dc42 Currently "Label Objects" turns either both on or both off.
It doesn't generate M486 if i set the flavor to klipper, so it seems this is on purpose.

If i manually remove the M486 labels everything works as intended.

Am i correct in assuming the slicer should only generate either comment-style labels OR M486 labels, not both?

In that case I'd like to report this to the SuperSlicer dev, but should i ask them to only generate M486, or to only generate comment-style lables... which are generally the preferred method in RRF?

When using SuperSlicer in "RepRapFirmware" flavor and enabling "Label Objects", both comment-format Object Labels and M486 object labels are generated:

; printing object 1x1 V Block.stl id:0 copy 2
M486 S2

This causes an extra set of empty objects to be generated in the object model.

I'm unsure, is this is intended behavior for the firmware, or should it handle this kind of of labeling?

Should i report this as a bug on the SuperSlicer Github?

The object list at the start of the gcode looks like this:

; object:{"name":"1x1 V Block","id":"1x1 V Block.stl id:0 copy 0","object_center":[131.250000,178.750000,0.000000],"boundingbox_center":[131.250000,178.750000,12.400000],"boundingbox_size":[41.500000,41.500000,24.799999]}
; object:{"name":"1x1 V Block","id":"1x1 V Block.stl id:0 copy 1","object_center":[131.250000,131.250000,0.000000],"boundingbox_center":[131.250000,131.250000,12.400000],"boundingbox_size":[41.500000,41.500000,24.799999]}
; object:{"name":"1x1 V Block","id":"1x1 V Block.stl id:0 copy 2","object_center":[178.750000,155.000001,0.000000],"boundingbox_center":[178.750000,155.000001,12.400000],"boundingbox_size":[41.500000,41.500000,24.799999]}
; Total objects to print: 3
M486 T3
; plater:{"center":[155.000000,155.000000,0.000000],"boundingbox_center":[155.000000,155.000000,12.400000],"boundingbox_size":[89.000000,89.000000,24.799999]}

In the object model i have three empty, but named objects as well as three unnamed object with associated gcode...

PS: Using SuperSlicer 2.4.58.5 and RepRap Firmware 3.4.2rc1

@jay_s_uk @dc42 Thank you for your replies.

I will try to run everything with a 5A fuse then. But it's good to know if it does turn out the fuse will blow i still have options.

Hi,

im planning a printer build using the Toolboard 1LC.

I will be using a high power hotend heater that could draw around 4.5A. The documentation page states that the heater output can handle 5A, but under "description of connections" it also states the board's input is fused at 5A. Since i'll also run the extruder motor as well as fans from the board, i'm expecting the total power draw might exceed 5A and blow the fuse.

However, the documentations also goes into detail about wiring in an external fuse for the board, so now i'm not so sure...

Is there a power input fuse directly on the toolboard, and if not, would it be safe to use a 7.5A external fuse?

Have you started to see this issue AFTER doing a firmware update?
I'm having the same connectivity issue, but i am fairly certain that it was caused by a firmware update to version 2.02. I've never seen a similar connectivity loss before, and after the update it now happens fairly often. Note though that i've also updated the PanelDue Firmware, so i guess it's not entirely impossible that is causing the issue instead.

I'll run the next few prints with the wifi module disabled, if your theory is right i'd assume that'll prevent the connection loss.

A quick update:

Excuse me for taking so long to test things out, i have a lot of work to do at the moment so i have very little time for 3D-Printing.

My last few prints have been printed with the first extruder only, and so far the issue has not appeared again. I hope that helps a bit in diagnosing the issue, i will also try the new firmware next week when i have a little bit more time.

As a sidenote, thank you very much for the support so far, and for putting up with my slow testing

If i understand correctly, you are trying to write a Gcode to move the second nozzle to the correct position?

You don't actually need to do that. Setting the right tool offset is enough, though you need to include a command to lift the printhead in the "tpre" macro (which you can access in the system editor) to prevent the idle printhead from colliding with the bed when it's deploying.

You also need to put the commands required to actually deploy or retract the nozzle in the "tpost" macros.

Excuse me please for taking a bit longer than expected to try this out.
I updated the firmware, but the issue persists. Not changing the printing temperature at all during the print hasn't fixed it either

I currently don't have access to my printer, i will check if that is the case tomorrow.

Meanwhile, since this seems to not be a common issue i was thinking about the conditions that might be different in my case specifically to cause this behavior. The empty layers seem to always be listed after the first layer is completed, so could the issue be caused by:
-Having the printing temperature reduced by a few degrees after completing the first layer while also
-Having the standby temperature set to the first layer's printing temperature (I manually set it before printing so that the tool doesn't cool down while homing)

I was thinking that might confuse the logic since for most users there would be no reason to have a standby temperature higher than the priting temperature...

Again, i will test for this too when i have access to my printer tomorrow.

https://pastebin.com/uUgfuXVR
This Gcode was generated with Z-Hop off, but still caused the empty layers issue.