I do not know what happened, but it all works now.
I have tried several times with restart of both printer and PC in between. Maybe it comes back.
When upload from slicer failed I still could upload from DWC.
No errors, except within Slic3r when trying to upload.
I have installed latest DWC but I am not using it. I had failures without connecting with the DWC to the Duet since bootup of the Duet. So I do not thing the new DWC is the cause of this.
I will post again if this problem occurs again.
I am quite happy with the DWC v2.0.0RC3. You will want at least the DWC v1.22.6 if for no other reason than bug fixes. The Wifi server v1.22 is also good to have, it fixes a bug that the DWC v2.0.0 seems to tickle, though the 1.22.6 probably won't.
Glad you got it sorted!
@dc42 Thanks. I'll be doing some more tuning on the printer this weekend, so I'll update first and keep an eye on it.
If I do still get the problem after updating, what kind of information should I collect to help diagnose the cause?
Yes the 1.02 version boards can do homing by stall detection. Though, it will still be highly dependent on your motors and some fine tuning to get your sensitivity just right. If you have endstop switches already it's highly recommended to just use them.
It looks like you're still running some very old firmware. Now that you have access to the web control via wifi the easiest way to do a firmware upgrade is to upload it via the settings > general tab.
Here are the 3 files you'd need to update:
You may need to make a config change to get your homing working properly again.
I get this error message: "Error: G0/G1: insufficient axes homed"
Recent firmware versions do not allow axes to be moved before they have been homed. The only movements allows are homing moves (G1 moves with S1 or H1 parameter) and individual motor moves (G1 moves with S2 or H2 parameter). So any Z movements that your homing files make before Z is homed should use the S2 parameter. Alternatively, add M564 H0 to config.g to allow axis movement before homing.
@dc42 I do have a stop.g (but not cancel.g) that does contain the above G10 command.
Now I added explicit T0 to the beginning of my start.g and it seems to fix the issue.
EDIT: the tool was listed as off in DWC after the print finished. T0 in start.g changes it to active.
EDIT2: As an aside on this:
G10 P P0 R-273.15 S-273.15 does turn the tool to off and sets both active and standby temperatures to 0°C
M140 S-273.15 does turn the bed heater to off but it leaves its active temperature (and probably also the standby temperature) at the last set value.
Is this difference intented?
I was having a similar homing issue as well with my Taz6 printer after installing the duet wifi and installing the newest firmware. I don't know if it was the right thing but I just increased the negative move distances in the home x and home x files larger than the total possible movement of the axis. Seems to have fixed the issue.
EDIT: I spoke too soon. Last night when I went to start a print my Taz6 went to do the initial homing of all axis and it failed. The issue always seems to be with the y-axis not making it to it's endstop and then a failure stating insuffient axis homed.
I think user @biscuitlad has gone through the process. Perhaps they have a working config to share.
You can also search the forum for K8400. There have been a few discussions.
Here's one: https://forum.duet3d.com/topic/4145/using-the-reprapfirmware-configuration-tool
@macinyash, yes do that if you want the X=0 Y=0 position to be at one corner of the bed, but use negative values where appropriate. For example, if your printer has a X min endstop that triggers when the nozzle is 10mm off the edge of the bed, put -10 in the X minimum field. See https://duet3d.dozuki.com/Wiki/Centering_the_bed_or_setting_the_bed_origin. The values you select in the configurator are put in the M208 commands that it generates.