The Z value in G31 "tells" the machine how far the nozzle is away from the bed when the probe triggers. So, once you home the Z axis then do G1 Z0, the Z axis will move 0.672mm in your case and at that point, the nozzle should be just touching the bed. If the nozzle is 1.5mm above the bed, then the Z value is incorrect which means that you haven't calibrated the probe correctly. If as you say the nozzle is 1.5mm above the bed when you do G1 Z0, then you'd need to increase the Z value in G31 from 0.672 to somewhere about 2.172.

20um?!? Sh*t. Well, I just ordered a larger caliper and a digital protractor. I'm guessing that play in the rod ends is important too at this level. I need to change those. Hopefully in a few days I'll get the error down. Thanks!

The thermal vias are connected to at least 4 different pins on the driver chip, which must remain insulated from each other. If you stick heatsinks on them, you will be relying on the solder mask to insulate the traces from the heatsinks. I advise against that.

@wannathermal:

I am using Slic3r right now.

Filament settings - Cooling.

Tick the box to enable auto cooling. Under "Fan settings" set the min and max fan speeds, the bridge fan speed and whether to disable the fans for the first "n" layers. Under "Cooling threshold" set the print time below which cooling is enabled, set the print time below which slow down of print speed will be applied and set the minimum print speed.

thanks! issue fixed!

I had this happens when I accidentally uploaded an STL rather than a GCODE file.

To switch to 24V you should get a new bed heater, new hot end heater cartridge, and new fans. I don't advise running a 12V heater on 24V at low PWM because of the fire risk if anything goes wrong. It's possible to add a 24V to 12V converter so that you can go on using 12V cartridge heaters and fans, but cartridge heaters and fans are so cheap that I don't think it's worth the hassle.

See if these help
https://duet3d.com/wiki/G-code#M143:_Maximum_heater_temperature
https://duet3d.com/wiki/G-code#M570:_Configure_heater_fault_detection

Are those networks 5ghz? The Duet Wifi is 2.4ghz only.

Great, glad it's working for you now. My story on this is that I am using a wifi module in a product (not the same module as the Duet uses) and I found that after a while the mdns queries to it failed even though you could still access it using the ip address. After a lot of investigation that involved changing both the AP and the DHCP server I never got to the bottom of it. To this day I remain convinced that it is a bug in the wifi module. But then I got a duet and noticed the same thing could occur with the duet. So now I just access the duets using their ip addresses and the connections never drop out. Could still be something else that's causing the problem but I've wasted enough time already so I'm not chasing it any more. Cheers, Mark.

Okay so this file https://1drv.ms/u/s!Apv79JfGbPIwgvU7gaGP7552Y1OYHA
Machine starts with no tool selected. It homes once, then a second time as it gets to Bed.g then T0 is selected and it runs the Tpost0.g file first time giving a "Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault", then I ran it again but the hotend was at around 140 deg C so it stalled the motor.

If I run this file https://1drv.ms/u/s!Apv79JfGbPIwgvU8jO-nhSQcv9iFcQ which has m109 T0 in it. I get the same error just before auto-calibration "warning: tool 0 was not driven". It doesn't behave differently.

If I start the machine with no tool selected and manually select T0 before homing, then run the first file again it activates tool 0 just before autocalibration giving the "warning: tool 0 not driven…....."

So even if there are no M109 Tx or Tx commands within the gcode file it selects a tool.

Sure if tfreex.g, tprex.g and tpostx.g are not available then it changes tools without any unwanted behaviour. Maybe we just need a Tx Z0 switch to not run tool change macros?

@dc42:

@NoSkillzEngineer:

Since I do not know how to modify dc42's reprapfirmware just yet, I'll either use marlin to start, or I'll have to quickly learn enough java…C++ might be just a bit easier, but I prefer the duet so I'll probably force myself to learn java better.

RepRapFirmware is written in C++, so no need to learn Java.

Is it really?! Why on earth did I think it was Java?! Hmm. I must have gotten it confused with Android. Wow….That's good because I'm much more familiar with C++ than I am with Java, so that's good. I was under the belief that it was in java for most of the last year. Thank you for that correction! 🙂

Update :

Working on Duet 0.8.5 with release 1.19alpha2

The F parameter only takes into account XYZ movements, the U axis now adapts it's speed to be completed on time.

(But if U max acceleration is too low, it will still slow down the overall movement, adjust it with M201 command)

THANKS DC42 !

Update: So just for the heck of it I decided to remove the I1 from the M558 command and now it is working.

What I am using.
; Z Probe
M558 P1 X0 Y0 Z0 H5 F120 T6000 ; Set Z probe type to switch, the axes for which it is used and the probe + travel speeds
G31 P500 X0 Y-19.5 Z1.497 ; Set Z probe trigger value, offset and trigger height

Thanks for the explanation, David.

I will make the suggested changes.

John

Thanks for sharing!

PM'd you on reprap but Ill send another in light of this thanks.

Thanks Dougal1957 - will do.

I think things are looking better. I took everything apart once again in all 3 towers. Stripped the belts, idlers, steppers, all of it.

Found two possible things… one, my pulleys on my steppers weren't as well aligned as they could have been. Adjusted that, which cleaned up the belt path. (They weren't bad, just a tick off)

The other is the Z stepper wiring was directly laying on top of my 12v PSU's output ports. Not sure it was definitely getting any interference, but it's probably something to avoid. The first layer looks better now, so it's promising that was it. Need to run through a few prints to see.