I pretty much have the same question. I have a X probe offset of -23mm and have that entered in the probe configuration. I would expect based on some other firmware testing that issuing a probe command would take the offset into consideration on the x / y points to probe. For example, I wanted to probe at 0,0. The nozzle moves to 0,0 and tries to probe which will fail because the probe is hanging off the bed by -23mm. So when I created the mesh map, I had to take that into account and skew all my x numbers by the offset. Where is the probe X offset actually used? I do not think I have run a G29 with non-adjusted numbers because I didn't want to crash the bed so I don't really know if I give a coord like X150, Y150 if it will end up moving to X173 (since it has to account for the -23 offset).

Ok, can or do I need to do a 5th in the center or just the 4 corners?

I have the IR Probe setup and have my homez and homeall configured and that seems to work. I have 5 bed probe points setup (4 corners and the center). I run the auto bed compensation routine and it probes all the points and I get the matrix and offsets. I am seeing error messages when I print and know they are related to the bed compensation but don't know what is wrong. Is my bed data out of tolerances? Do the probe points need to be in a certain order? Here is what I get:

After running the probe script:
< 9:31:04 PM: Z probe offsets: -0.011 -0.134 0.006 0.072 -0.194, mean -0.052, deviation from mean 0.097

Debug before a print:
Bed equation fits points [250.0, 280.0, -0.011] [250.0, 30.0, -0.134] [120.0, 160.0, 0.006] [0.0, 30.0, 0.072] [0.0, 280.0, -0.194]

and error messages streaming while trying to print:
Triangle interpolation: point outside all triangles!

Do I need to disable bed compensation before homing then re-enable during print? I see the triangulation errors during any homing attempt after the first homing.

I just added another request similar to this that can be done in the same fashion but to the Pushover service (would need to specify key and token). If M117 is used it would be a common command for email / pushover and screen / web which would be nice.

The one thing I am missing from using my new DuetWifi is job notifications on my phone. I used the Pushover plugin on octoprint and think it would be nice to add such a feature on the Duet since it has networking / wifi. The pushover API is pretty simple, just a post of some JSON parameters (I say simple but I do not know what is required on the Duet side). Maybe have it triggered with a macro file or M code. Each setup would need a configuration for the token and key (passed as a parameter or setup in the config file?) then the message. If it is a macro file then it can be called at the end of a print or even from within a trigger like a filament out so you can get the message if you are not right there by the printer. Here is the API: https://pushover.net/api#messages

Ok. Thanks. Is that just in case a bed thermistor isn't connected it won't think it needs to raise the bed temp to 0 and causes it to heat?

Ok, finally have the board connected and the temperature checks seem to work better now. I actually had an open in one of the extruder wires and it did the no rise alarm.

I did notice something with the bed temperature and don't know what it causing it. The gcode sets the bed to 55c then sets the extruder temp but after some time the bed acts like it stops heating. I get no alarms on the paneldue console or through the web console. The Active temperature shows the correct temperature (55) but the bed is showing around 33c and the light on the SSR is not on anymore.

I noticed that on my PanelDue the Active temperature for the Bed shows -273 on startup until I set it to anything else. The extruder shows 0 like it should. Probably just cosmetic or a variable initialization problem.

The silkscreen for the DuetWifi I downloaded shows E0/VIN backwards from what my board has. This normally would not matter but I use the E0 +12V output as a common to feed the two fans so they polarity matters. The VIN on both E0 and E1 are closer to the LED's and - are closer to the stepper connectors.

Ok, just seems odd that even if it prevents a heater from heating if it detects that it is bad that it will continue to try and print and possibly grind away at the filament. Shouldn't it maybe pause? Maybe have a definable trigger or something. I am going to try and wire it up this weekend. @deckingman, now sure I follow about the extruder being H1. I am looking at the board layout and I see E0 and E1 then the larger Heated bed connector. I don't see H0 / H1.