Thanks a lot for the help.
I actually went through that tutorial before.. but, now it just works.
Didn't have to change a line and was few hours on that already,
I have no clue what happened... but happy o/
Mosfet usually fail always on (or catastrophically to the point where there is nothing left of the part)
So if the fan works on the always on output but not on Fan0 before and after the replacement its not untinkable the fault is elsewhere, unfortunately the next part in the chain is the main processor (FAN0 goes straight to pin 90 on the ATSAM4S8C)
To further diagnose verify the part has connectivity from the Gate to R42, from the Drain to Fan0- on the header and from Source to ground. Then (with power on) check if you have a gate signal on either side of R42 with respect to ground when the fan is turned on.
@dc42: Does it sound like a bug for the probe offset to be applied over and over on repeated G30 P3 X0 Y180 Z-99999 F2000 calls?
That doesn't sound right. Please post the complete macro file you are running, and your config.g file, and tell us which firmware version you are running.
I was originally on 3.0, and now on 3.01-RC4
Unfortunately, I did not save the macro before modifying it. That is my fault.
I did find one error in my code, in asking it to probe at X0, when my probe has a +12mm offset. I feel like the firmware should catch this more gracefully though. It appears that it ignores the endstop switch and the X0 minimum designation, and tries to aggressively get the probe to X0 anyway, which hard crashes into the machine limit and jumps the belts.
Also, it appears that I can't probe more than 32 points before I am "out of range"
Which version of Duet Web Control is it running? Look in the Settings General page to find out. The latest version is 1.22.4.
Thinking about this more I wonder? If I change the config file and reload the firmware without power cycling the board or force reloading the Web interface, what are the chances I would get some of the behavior I was seeing? What determines the button actions, and can they get out of sync with config.g?
BTW, I believe the default micro stepping when I installed the board was 16 for XYZ and 8 for E. With this as a starting point it's likely things went off the rails for reasons I didn't grasp at the time. There was definitely a period where the web interface was not in sync with what config.g was set to. And it persisted through reloading and power cycling because it happened of the course of several days.
i´m still having the same problem. Do I need to use M558 P2 for the "digital probe"? if I do so, the Probe Z status in DWC shows 0 (5) when not triggered and 0(1000) when triggered. By Triggerd i mean a red LED.
Sorry for the late response. M558 P1 is correct for the IR sensor that we sell. P2 is only for the sensor that RepRapPro included in the Ormerod 2 printer and I think also the Huxley Duo and one of their Mendel printers.