@phaedrux All axes do what they should

I had probably used too inflexible cable, because after I had replaced the white by a remaining blue in the cable channel was then the red broken. So I had to make the complete cable chain "empty", and replaced all cables of this type😑 . But now it works.😀

Thanks for all your help.

Now comes the installation con extruder and honend .... there I will soon probably put another call for help in the forum ... but first I will try to understand the existing Gcode.
Thanks and see you soon.🙂

@dc42 Perfect, this is exactly the thing. Thankyou!

@sathvik have you considered configuring the pipette as an axis instead of an extruder?

@phaedrux i know that now. It worked though because my endstops were wrongfully configured as low end for the last year. Don't ask me though WHY it worked that way. 😧

By the way: Its all working properly now. Thanks alot all of you!

I will be back in time probably since i am currently installing my new Duet 3 into my second printer. 😄

@jay_s_uk said in Monitoring Duet 6HC drivers:

@leobg no, they only provide 0 (cold), 100 (hot) and 130 (very hot)

Thanks for the clarification!

@stephen6309 Awesome, thank you!

@chrishamm pressing the button while it is on?

Thanks for the help!
Xavier

Have you checked the probe trigger height at multiple points on the bed?

Touch the nozzle to the bed, set G92 Z0, move up 10mm, test trigger height with G30 S-1.

Is the trigger height consistent at all XY points?

What type of probe is it? Is it affected by magnets or density?

It seems the mesh is working as expected, and that it is the probe results that are incorrect.

@deckingman said in TOOL T0 IS NON ACTIVATED IN config.g:

@gianluca I'm wondering if using M300 to play a 3 second beep just before the "T0" command in your config.g is having an effect? Try commenting that M300 out just to see. Or you could try putting a pause of (say) 4 seconds after the M300 and before the "T0" e.g. G4 S4.

The M300 is not the problem, and 4 sec. delay did not solve the problem. I solved by update the firmware from 3.3 to 3.4 b7.
The beta version worked better than a stable one

@dc42 Heater fault happens at power on only.
So far, my best remedy is to put a 30 Sec delay at the end of config.g and this cures the symptom.
Will investigate further. Possibly a config mismatch or a wiring problem, but since bed heater is also in the game, I doubt cabling is an issue since they are not running the same way on a bigbox.

@ololenok said in duet3d 3.3 delta calibtating problems after fimware update:

Also the config generator gave some very raw results for v3.3, like strange homedelta.g with movements after homing that lead to additional problems.

That's likely a result of mistakenly having it set to low end endstops at the beginning.

@zapp3r Good news. I'm glad you got it figured out.

@infiniteloop

Thanks for your help.
Removing the first T-1 P0; (line 5 below), did not solve the issue.
Removing the second T-1 P0; (line 13 below), did solve the issue (tried multiple times, seems to be reliably solved).

(Tried all 4 combinations of commenting out the lines).

Not sure why a T-1 P0; (Line 13) immediately followed by a T0 P6; (line 14) causes the T0 P6; to not complete.
Reminder: It runs through the macros, and even finishes executing tpost0.g, but never moves on to the next line.

Since it seems that the logic behind resurrection has been tweaked in 3.4, I'll wait for that release and see what happens.

Thanks!

resurrect.g that worked:

; File "0:/gcodes/HandleSet.gcode" resume print after print paused at 2022-01-31 21:07 G21 M140 P0 S110.0 G29 S1 T-1 P0 G92 X3.384 Y-123.624 Z0.300 G60 S1 G10 P0 S250 R170 T0 P0 M98 P"resurrect-prologue.g" M116 M290 X0.000 Y0.000 Z0.000 R0 ;T-1 P0 T0 P6 ; Workplace coordinates .... Following lines truncated...

@pre Awesome!

I'm glad you got it sorted.

@deckingman Thanks for the suggestion, replaced the thermistor wire and now its working fine

@phaedrux @dc42

Thanks so much guys!
Updating the firmware did the trick...

I'm learning a lot here, and I think this here project would be doomed if not for this forum. 😬

@solarsamuel As an aside, normally closed switches are usually better than normally open because if a switch fails, then the gantry will slam into the frame and the motors will continue to try and move it. But, the downside of using normally closed switches is that if a wire falls off, then it will appear to be open (as you have discovered), which will mean that the gantry is considered homed at a position which could be far away from it's true homing position. Strange or alarming things will then happen if you haven't noticed and try and run a print like that (this is the voice of experience talking) 🙂 .

So here is a little tip that you might find useful. Essentially check the state of the end stop at the start of homing and abort if it's already triggered. You need to find which end stop is for which axis but generally X=0, Y=1 and Z=2 (at least that's how it is on my machine). So to check the state of the Y end stop for example, before homing Y I use ......

if sensors.endstops[1].triggered abort "Y endstop already triggered at the beginning of the homing move - aborting"

Obviously the command for the X and Z axes would use ...endstops[0] or [3]) and the message would refer to the X or Z endstop.

HTH

@dc42 with my config any ideas? As far as I've been able to google around seems like the config most are using, but I don't rule out I've done something silly either.

Thanks!

What's your firmware version? Have you updated since you last used this?

Changing your resume.g may help

Instead of

G1 R1 X0 Y0 Z5 F6000 ; go to 5mm above position of the last print move G1 R1 X0 Y0 Z0 ; go back to the last print move

Try

G1 R1 X0 Y0 F6000 G1 R1 Z0

@deckingman Oh wow. I missed that bit. Thank you! 🙂