Topics created by ComedianTF2

@T3P3Tony

I will be able to check that in January, once I'm back from holidays

@droftarts

Same, will test it out in January once I'm back. The wiring I've done per the guide you've shown. I had missed the driver enable polarity jumper, so that's quite likely the issue there.

With re-sending the commands we were able to get the printer up and running, and the printer has completed a successful print, though hopefully we won't need to use the driver_enable.g file I used before with the fixes recommended.

Thanks both for the help, I'll enjoy the Christmas break for now and get back to it in Jan

@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