Many thanks for the clarification David.

Sorry for the misunderstanding; I don't have a 'turn everything off' macro (am I missing it?) - I was referring to the 'Turn everything off' button in the following screen capture snippet:

Maybe I broke that button's functionality when I hacked DWC to display a larger temperature graph - I don't see how, but it is a possibility.

I've just played again with that button and notice it's completely non-functional (i.e. with and without first cancelling a print) - If I turn all heaters on manually, then click 'Turn everything off', it isn't functioning.

Additionally, I just tried cancelling a print (with bed at set temp, extruder almost at set temp) and restarting the same print only to discover another problem: the extruder temperature is never re-set to printing temperature - the extruder head moves but cold extrusion protection is apparently kicking in to prevent extrusion. This probably needs more testing and verification, but will need to wait a week until I can play again.

Thanks for all the useful info, but I'm still a little confused after reading up on M0:

https://duet3d.com/wiki/G-code#M0:_Stop_or_Unconditional_stop says M0 H[non_zero_number] is sent by DWC to cancel a print job, keeping the heaters ON:
"M0: The optional 'H' parameter, whose value must be non-zero keeps all heaters active. This is what Duet Web Control sends to cancel a paused print."

Is it a correct assumption that if I have a sys/cancel.g file, that is called instead of DWC simply sending M0 H[non_zero_number]?

BTW, I can see how the default 'heaters remains on after cancelling print' may be useful behaviour for some cancelled print situations, however I'd like to suggest it is a less-safe default state in which to leave a machine after a print job is cancelled - especially for someone new to the hardware. I was recently caught out after cancelling a print, dashing out for an hour only to come back and discover the bed and extruder still hot - far from the safe state I expected it to be in. Would be interested to hear peoples thoughts.

I also discovered a possible bug in that after a print job is cancelled using the cancel button, the Control All > Turn everything off isn't functioning (in RRF v1.18beta2 - sorry I'm running a little behind the releases lately) - instead I need to turn off each heated device in turn.

Rather than start a new thread with similar title…

dc42 - I didn't find this info on your site or this forum:
What are the XZ offset dimensions (in mm, relative to upper surface of and in PCB coordinates) to the IR z probe's notional 'sense axis'?
Dimensions either WRT the PCB bottom left corner or possibly better yet, relative to the IR z probe PCB LH mounting hole would be appreciated.

My own rough estimate: X=12 from LH PCB edge | 9.3 from LH mounting hole center, Z=4 mm from PCB upper surface. N.B. To prevent confusion I'll delete my estimate after you reply.

I see the following from Appendix: Board dimensions and mounting holes for version 1.1 and 1.2 boards on your website, but no positional data for the probe's 'sense-axis' location.

If the bottom left corner of the board is position (0, 0) then other points on the board are at the following (X, Y) coordinates, in mm:

Top right corner (24.0, 17.62)
Mounting hole centres (2.70, 14.92) and (21.11, 14.92)
Mounting hole diameter 2.8

Last updated 2017-05-10.

Apologies for my stony-silence since opening this thread - I've been out and about without a spare moment.

@dc42:

Looks good! Would you care to upload it to Thingiverse? If you do then I'll add a link from the IR sensor fitting instructions.

@Roland:

Nice one. Do you have any provision to stop the duct rotating on the heatsink to prevent the back of the IR probe PCB shorting against the heater block - assuming no/defective silicone sock?

Thank you both.

Now published on Thingiverse as: E3Dv6 fan duct for dc42 IR height sensor V1 | http://www.thingiverse.com/thing:2250394

Although I don't currently have an absolute solution to the issue of the duct rotating on the heatsink, there are a few factors that give me peace of mind that the risk of the PCB shorting is minimal:

• With the PCB fixed to the side of the mounting tabs furthest from the heater block, it would be possible to rotate the PCB greater than ±45° with (IMHO) no significant risk of either the PCB or supplied screws touching the heater block. The same is not true if the sensor PCB is fixed to the inside of the mounting tabs - though for the PCB to be able to rotate through the 45° position would likely require the almost complete breakdown of the E3D silicon sock along a vertical edge,
• Along with dc42's own fitting instructions, I'm advocating the use of Kapton tape on the back of the PCB,
• On my own printer, the location of the duct between the X-carriage linear shaft bearings physically prevents significant rotation,
  Other thoughts:
• Addition of an anti-torque grub-screw or extra clamp to the design ought to be possibile,
• Five of the six ducts I've printed have all gripped the E3D Heatsink much more firmly than the original E3Dv6 duct ever did. For a more detailed explanation, visit the Thingiverse page and read the Note under Print Settings regarding higher print speed resulting in firmer grip characteristics.

Any thoughts appreciated - especially if you think I'm being over optimistic in my assumptions.

Not being quite satisfied (for various reason) with the current IR sensor mounts for E3Dv6 fan ducts - and wanting to get my teeth into Onshape for some time, I'm happy to present the hairy_kiwi 'E3Dv6 fan duct for dc42 IR height sensor V1'

Fitted, in use:
photo to follow

Design intent:

• Moderately-strong clip strength to attach to E3Dv6 Heatsink - both radially, at top and bottom of the Heatsink, and also vertically, to ensure minimal influence on probe z-position,
• Improved airflow rate + fan-noise reduction - by increasing duct internal volume between 30mm fan and Heatsink,
• 30mm fan mounts with E3D supplied screws.

Printing guide:

• Orient with the inlet face to the printer bed,
• NO support material required,
• 0.3mm layer height,
• 1 perimeter,
• infill 35%,
• 3 solid top and bottom layers.

Files:
Onshape Part/Assembly
E3Dv6 fan duct for dc42 IR height sensor - V1 - via MoI3D.STL
E3Dv6 fan duct for dc42 IR height sensor - V1 - via MoI3D.STP

Awesome!

Are there any plans to offer an optional WiFi daughter board for the Duet Ethernet?

@dc42:

I think you mean binary search. I remember using this technique when i was a student, to determine the appropriate amount of chilli to use when cooking chilli con carne. It only took me 3 meals to get it right.

That's it dc42! Many thanks for enlightening

@Jackal:

What kind of model is good for testing pressure advance?

A solid infill 20 - 30 mm square x 3 mm height block ought to be of sufficient size to visually assess all the nuances of changing pressure advance. You may even need less z-height than 3mm to reach a conclusion. I would also suggest using the half-split-successive-guesstimate-technique* to derive your preferred value, rather than changing the value in small increments; you should find it much easier to see any changes that way. Until last week I was using a single 50 x 50 x 1.8 mm block with 0.3mm layer height and solid infill while setting up my machine. I found it a useful size block for checking bed flatness, E-steps/mm, jerk and acceleration and did also use it for setting pressure advance, but its size is probably overkill if you only want to set pressure advance.

*There's bound to be a bona fide mathematical process name for what I'm describing, but I can't find it so I've mashed one together: the half-split-technique (from electrical fault-finding) with successive-approximation (from mathematics, for finding roots of equations). 'Approximation' is further replaced by 'guesstimate', because at the end of the day it's all a somewhat subjective process.

Good luck! Have fun

@roboduet:

@hairy_kiwi - do you have photos of printed parts with and without M572?

No, sorry. I'll post some when I get a moment.

Running a wade-derivative direct drive + RRF1.18beta2 and printing at around 50mm/s, I saw a noticeable improvement last week with pressure advance values in the range dc42's suggesting.

I'm currently running M572 D0 S0.025 in each gcode start-code block - i.e. not in RRF config.g. I read a good reason for it, but forget. Anyone care to remind?

The nice thing about tweaking pressure advance is M572 can be issued while printing, making it super easy to experiment - thank you dc42
I started with the rather extreme value of S5.0 just to check pressure advance was visibly functional. That resulted in a crude chamfer (approx 2mm) being applied to external square corners, S0.05 resulted in very slight but noticeable rounded corners and right now I'm happy with S0.025.

IIRC S0.05 actually made for 'nicer' external perimeter corners than S0.025, but also resulted in gaps beginning to appear between infill and perimeters/outlines - perhaps more perimeter/outline overlap might solve this (currently its 15%).