Topics created by ComedianTF2

@droftarts thanks, have added a feature request:

https://github.com/Duet3D/RepRapFirmware/issues/1103

ComedianTF2 created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Assigning multiple heaters heaters for a single bed using M140 P0 H0:1 #1103

Thanks, I've the macro workaround works for now, but a more integrated solution would be great. I've added a feature request on the github for the paneldue integration.

@ComedianTF2 glad you have resolved it.

@dc42 Thanks for that.

Good to know that the choice selection for the M291 T0 S4 does not need to be indented, that makes a large difference and with that I should be able to get everything in a single file

@ComedianTF2 thanks for pointing this out. I have fixed it.

@T3P3Tony Thanks, I had assumed so but was a good one to check. Will look at the slicer side for getting things working there.

What I do wonder is if it would be possible for the nozzle to do a diagonal move (shown in purple), it always seems to get back to the previous part's Z position before starting no matter what I do. It always does the up/down motion in orange or green

11242da2-87db-4cba-b32e-73232f8c19cc-image.png

I tried using the following end bit in the tpost0.g and tpost1.g, but it would lower back to the Z position no matter what, even though there isn't anything in the tool changing scripts that would indicate that the Z motion should happen.

elif job.file.fileName != null ; When printing G90 ; absolute positioning if {(move.axes[2].machinePosition) < (move.axes[2].max - 4)} ; if there is enough space G1 Z{(move.axes[2].machinePosition)+3} ; move up 3mm else G4 P1 ; wait 1ms G4 P0 ; wait for moves to complete

@T3P3Tony Using M226 within the filament-runout.g had a weird behavior, the printhead would remain standing still on the bed, not moving on to execute the pause.g at all.

The normal M25 behaviour is much preferred over this, as the printhead should be moved away from the print as quickly as possible in a runout event, to prevent material from oozing out on the print and causing possible issues

I did notice some other small mistakes within the filament-runout.g (using if instead of elif on some parts), but those aren't the cause of the problem, just some oddities that I've fixed on my end now

@phaedrux I've tested it by moving the cable away, so that it no longer runs near motor cables, but sadly the info messages remain.

@comediantf2 I'm glad you got it working.

@phaedrux Thanks for the confirmation

@infiniteloop That did the trick. Much appreciated for that insight.

Final code:

echo >"0:/sys/config_PID_tune_E0.g" "M307 H0 R"^{heat.heaters[0].model.heatingRate}, "K"^{heat.heaters[0].model.coolingRate}^":"^{heat.heaters[0].model.fanCoolingRate}, "D"^{heat.heaters[0].model.deadTime}, "E"^{heat.heaters[0].model.coolingExp} echo >>"0:/sys/config_PID_tune_E0.g" "M307 H0 B0 S1.0 V"^{heat.heaters[0].model.standardVoltage}

That macro resulted in this config_PID_tune_E0.g

M307 H0 R1.990 K0.292:0.075 D4.7 E1.4 M307 H0 B0 S1.0 V23.9

@ComedianTF2 Thanks!

Do you happen to have the code for the v4 180x as well?

@comediantf2 please ask your supplier to replace your Duet 3 Mini, quoting this post as authorization. We have had a few instances of intermittent SD card communication in the first production batch.

Thanks everyone, that makes a lot of sense. Will do more reading!

https://www.dropbox.com/s/xlzhcwm6c8qfyar/benchy_not working.gcode?dl=0
https://www.dropbox.com/s/2kg1cpzdxq78m8h/benchy_working.gcode?dl=0