Oh right okay, I only mentioned this as I was pretty sure that I had retrieved information off of those pages when i brought my Duet WIFI. I must be incorrect though.

I fountd the culprit: the right formulation was S0 to end the calibration routine. I changed my file to the form in the Wiki:

M561 ; clear any existing bed transform
G30 P0 X10 Y10 Z-99999 ; define 4 points in a clockwise direction around the bed, starting near (0,0)
G30 P1 X10 Y190 Z-99999
G30 P2 X190 Y190 Z-99999
G30 P3 X190 Y10 Z-99999
G30 P4 X100 Y100 Z-99999 S0 ; finally probe bed centre, and calculate compensation
G1 X0 Y0 F5000 ; move the head to the corner (optional)

Whatever you limit your max extruder speed, acceleration to in the firmware will be the limit, no matter what your slicer asks the printer to do.

Same is true of other axis so, on those with lead screw driven Z axis for example, if you do a combined move (for returning to a set point at the end of a print or on pause for example) that includes a long Z move, all the axis will be slowed down to the max speed the slowest axis allows. That means if you wanted to retract during that move as well (for example on pause) the retract would be slow, so worth retracting on a separate G1 command.

Z4.80 in the G31 command specifies the probe trigger height in mm. You need to reduce it to make the nozzle higher after auto calibration.

@Corexy:

Yep, I'm loving mine too.

Really getting into the finer tweaking regarding extrusion, and am seeing better and better results.

Web control is awesome, and I can see why they couldn't understand me wanting to use SD cards (unless wifi was down).

From what I understand, you can upload (I guess to the onboard SD Card) and print from that. If (or when in my case…) Wifi Drops out, it doesn't really matter.

It's a shame I'm mega busy at the moment, partying tonight, gigging tomorrow, family time Sunday, then back to the day job Monday.
I can't see me having much time on it this weekend.

Babystepping as marlin implement it sends a specified number of extra step pulses to the z motor driver per turn of the encoder wheel. So it's coordinate-system independent, instant and in the latest versions theres a readout on the Lcd to say how many millimeters you moved, which you can use to set a permanent z offset in firmware or your slicer.

This is what we need really, it's tried and tested. If reprap firmware wants to steal a march on marlin then and option to save the offset for the next print would be a wonderful addition. Perhaps into the new configuration override file.

I accept that if you have a really precise, reproducible printer and you don't change it much then you set the z offset once and then just use it. But if your printer isn't that tight, or you're testing things or change nozzles a lot, or hot ends this can save you hours and lots of filament.

So all you are doing is sending (during printing the first layer) a G92 command to change the absolute Z coordinate. So if you are printing a 0.4mm first layer and you send G92 Z0.425 you've just told the printer that the current level is not 0.4 anymore its 0.425mm. You haven't physically moved anything. It takes the printer a few seconds to get to this command as there is a buffer, it lowers the nozzle by 0.025 on the next gcode command because this next command will ask it to be at Z0.4 and it thinks its now at z0.425.

Likewise if you send G92 Z0.375 the printer thinks its too low and at the next line of gcode it raises the nozzle 0.025.

I created two macros one for each command, so I can press lower or raise from the paneldue screen, but you can do it from the web interface instead. Or if using a host like pronterface create some buttons with these commands.

If you want to print 0.3 first layers, your lower nozzle macro would be G92 Z0.325 and raise would be G92 Z0.275

There are three reasons why this is a functional workaround but not very satisfying are that its not instant, the firmware has to process the commands in the buffer before it changes z level, so its hard to see if you need to press it once, twice etc… If you press to lower 10 times you might get a head crash. (A good reason to use 0.025 rather than 0.05). The other reason is that if you're printing a cube the brim or whatever you print first won't have that many moves in it, therefore you don't get a lot of time to make the adjustment unless you set your print speed to 10% as you begin. Also you have to use the same first layer height each time, or your need two macros for each first layer height you routinely print with.

My solution to this to make an object, one layer thick, with lots of short zigzags or similar, you place it next to the object you're printing in your slicer, make sure you've set plenty of skirt and brim to give you extra moves in which to have time (and moves) enough to adjust the z height and then leave it to print the object.

Marlin's babystepping which I helped (a little) to test with them just sends extra step pulses to the z motor as you turn the encoder wheel and does not alter the coordinate system. So on the plus side its instant, you can set it very quickly and you can do it with any layer height and at any point during the print (though why you would want to do it at any other point than the first layer I could not imagine). They eventually implemented a readout on the lcd which summed the extra steps and divided them by your z steps/mm and which shows how much in millimeters you moved, so at the next print you could enter a z-offset either in firmware or slicer, so provided your printer's reproducibility is good the next print just starts at the optimised Z height.

I've actually given up using this as its now so well calibrated if I measure the nozzle to zprobe trigger point accurately, then calibrate the nozzle is 0.1mm above the bed everywhere and I can just print. Possibly adding an offset in slic3r for the next print if it was fractionally too squashed or too high.

David and Ian, thanks for the quick reply. Yeah, although the temperature measurement could be solved by drilling a hole in Al plate, long heating and cooling times could be annoying. For now, I am switching to a 220W 24V heating pad from a 12V Onyx, which is an improvement but nowhere near the 800W.

@Adamfilip:

I would like to install a thermistor to monitor Chamber/Enclosure temperture and if its too high then Turn on an exhaust fan to remove some heat
is this possible?

A

Yes that's possible. I'm going to do the same thing but measure the stepper driver temperature to turn on/off a fan in the Duet enclosure.
Connect the thermistor to spare channel (say E1) then use M106 to set the fan to monitor that channel and set the temperature threshold at which it will come on.

Thanks!
That solved it!

The E0 endstop is used for the U axis if you have one in firmware 1.16. In machines without the U axis it can be used to connect a Z probe (type 4 in the M558 command). Likewise E1 is used for the V axis. Endstop inputs that are not used for anything else can be used to trigger macro files, see http://reprap.org/wiki/G-code#M581:_Configure_external_trigger.

With firmware 1.16 the U and V endstop status is shown in the M119 respond and in DWC if you create the additional axes using M584 and then enable U and V endstop using M574.

I created a PCB Mounting Hole CAD File, if anyone needs one.
can be found here

https://grabcad.com/library/duetwifi-pcb-mounting-holes-1

@ianlee74:

So, what does M500 currently do in RRF? Does the RR wiki need to be updated to say it isn't supported?

It already says that.

@peridot:

Would it be feasible - this is a firmware question I guess - to respond to probe triggers when not probing? With the accelerometer set right you might be able to detect head crashes and stop the print. Obviously this doesn't make sense for all sensor designs.

Yes, if the acceleration in fast travel moves can be distinguished well enough from the abnormal situations you wan to detect.

Thanks, Worked first time.

Whenever I edit the config.g file and do a software reset, I am not getting any message in the g-code log. Any idea why? Most of the time, the heaters will shut off and I assume the config.g edit was saved.

This is a known issue. Either upgrade the PanelDue firmware to the 1.15 beta, or wait for DuetWiFiFirmware 1.16.

One more catch:

Browser side:

[[language]] "GET /rr_status?type=1" - successful request (req1) "GET /rr_status?type=1" - successful request according to Wireshark, but 200 OK empty request for browser (req2) "GET /" - again, JS requests index page (/) after failure

Wireshark side:
req1 (successful):

[[language]] GET /rr_status?type=1 HTTP/1.1 Host: 192.168.0.28 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest Referer: http://192.168.0.28/ DNT: 1 Connection: keep-alive HTTP/1.1 200 OK Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 Content-Type: application/json Content-Length: 387 Connection: close {"status":"I","coords":{"axesHomed":[0,0,0],"extr":[0.0],"xyz":[0.00,0.00,0.00]},"currentTool":0,"params":{"atxPower":0,"fanPercent":[0.00,100.00,0.00],"speedFactor":100.00,"extrFactors":[100.00]},"seq":1204,"sensors":{"probeValue":0,"fanRPM":0},"temps":{"bed":{"current":26.6,"active":0.0,"state":2},"heads":{"current":[25.8],"active":[0.0],"standby":[0.0],"state":[2]}},"time":26601.2}

req2 (shown with 200 OK status but with empty response body):

[[language]] GET /rr_status?type=1 HTTP/1.1 Host: 192.168.0.28 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest Referer: http://192.168.0.28/ DNT: 1 Connection: keep-alive HTTP/1.1 200 OK Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 Content-Type: application/json Content-Length: 387 Connection: close {"status":"I","coords":{"axesHomed":[0,0,0],"extr":[0.0],"xyz":[0.00,0.00,0.00]},"currentTool":0,"params":{"atxPower":0,"fanPercent":[0.00,100.00,0.00],"speedFactor":100.00,"extrFactors":[100.00]},"seq":1204,"sensors":{"probeValue":0,"fanRPM":0},"temps":{"bed":{"current":26.7,"active":0.0,"state":2},"heads":{"current":[25.8],"active":[0.0],"standby":[0.0],"state":[2]}},"time":26601.9}

The only thing I can understand at this moment that DWC requests index page (/) if it receives empty AJAX response and after this stops any further requests.

more of metal frame than enclosure

Just wanted to add that this a brilliant tool to use for initially getting the bed level if you have a 3 point levelling system. Just set the probe points as close as you can to where the levelling screws are and run the check. Leave one screw alone and adjust the others until the readings are as close as you can get it. I found it much easier than messing around with bits of paper or drill bits. Once set, you can always go back to 4 or 5 or more points is you want to.