Posts made by WarriorMe

@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.

@dc42 I can confirm that the G1 Z... commands are caused by Z-Hop.
I'm assuming this is a bug in Prusa's code that causes a hop both when going from Z=0 to the first layer height and then again when going to the actual print starting position.
I will try to see later today if a print without Z-hop also causes the weird web-interface behavior.

I have also taken pictures of the web interface showing the empty layers:

Layers 2-50 are practically empty, after that everything works normally.

Edit: Printing with Z-hop disabled still causes the empty layers, even though there is only one Z-command at every layer change now.

Are you using an ATX power supply, or other PSU than can be turned on and off?
If you are, i'd suggest putting a mechanical relay in series with the SSR, and connecting it's control signal to the duet's Power input. That way the duet can relatively reliably turn off the heater together with the power supply, should the SSR fail in a closed state. Or, alternatively, you could use a thermal fuse on the heated bed.

I'm no professional electrician, but i believe you should also connect any metallic frame parts near the heated bed to the earth pin of that power plug, in case something damages the heatbed or wiring insulation.

I was assuming that it is being generated because Z-hop is enabled. I was wondering about the unusual number of Z-commands at layer change too, it seems that the current implementation of Prusa Slic3r generates both a Z-hop and the actual layer change every time.
I'm not sure if that's causing the issue though, because those bunched up Z-moves are present all througout the file, but the Web Control page shows empty layers only at the start of the print, after completing the first real layer. The problem also appeared after updating the Duet Firmware, while still using the same version of Slic3r as before.

I'll try to run some code without the Z-hop next time and see if that fixes the issue. I'll also take a screenshot of the Web control page

https://pastebin.com/VEKjWGjk

^ Example Gcode.
note: the issue also comes up with the previous version of Slic3r

My Duet Wifi reports about 40 empty layers at the start of each print (0 layer time, 0 extrusion) in the web-interface. After that the layer counting works as intended, but of course the empty layers throw off the layer count as well as print time estimate.

My End-Gcode has a Z-move, but i have already added the ;E comment to it.

The issue only appears since updating to version 1.21 of the firmware and web-interface. Layer counting worked fine on version 1.19.

Thank you in advance for any replies

Thank you, that really worked

In the web interface, both object height and layer count are displayed wrong.
I am sure that this is because my end-Gcode includes a command to lower the build plate. The solution suggested in another thread, to change the command from a G1 to a G0, did not make a difference to this.
So: Is there a way to lower the buildplate without confusing the firmware about the size of the object?

Thank you in advance for any replies

@knabo:

Do you have more than one power supply? Or are you running your Duet Wifi off USB?

Otherwise I would think shutting off the AT power supply would shut down the entire system.

Please correct me if this is wrong.

ATX power supplies are the ones used in computers, and to keep wifi and ethernet etc. running they have a 5v rail that is on as long as the main switch on the power supply itself is on. You don't usually notice because this standby rail doesn't need the power supply fan to spin, so it will look like it is completely off, but you will notice that the ethernet LEDs stay on (at least with most PCs)…

The Duet Wifi is capable of switching off an ATX power supply … If i understood correctly doing so disables the stepper drivers and heater control...

So, my question is, with no power to those components, does the duet still need significant cooling or is it fine to switch the electronics fan off with the power supply?

(I'm going to mount the board in a large enclosure, with the bottom of the board facing upwards and a 60mm fan blowing down onto it, which is the fan i would like to switch off in standby to make the printer silent)

Thank you in advance for any answers