I found the cause (in front of the monitor) 🙂

Wasn't aware G31 is only used for auto calibration, was thrown of by "If, in later prints, you find the first layer is too thick or too thin, adjust the value in your G31 command" https://duet3d.dozuki.com/Wiki/Setting_up_automatic_probing_of_the_print_bed
Which is only sufficient when autocalibrating afterards which i don't.

I use auto calibration only for initial setup after changes on the printer. I found its not necessary to auto calibrate every time and it doesnt work when there is glue stick/hairspray/tape on the glass which i don't want to remove regularly.
So i needed to increase G31 Z and M665 H parameter with 0.075.

@dc42
I don't have a config-override.g

The 3 point leveling works very well, just gotta be precise in your leadscrew positions. I routinely get it down under 0.01mm across the bed.

My bad. Read the documentation too quickly. Thanks for the help I will experiment.

Do I add a M579 line to my config.g

@dc42:

Both M206 Y10 and G10 P0 Y10 ought to work. G92 Y0 will not.

I appreciate the info from all, but David I think there are some issues with M206. I went back and played with M206 Y10 again and it does some wierd sh*t. It probably doesn't matter; I admit my need is an outlier. But, in case it is of interest:

What I commanded (except for the initial M206, everything was done using "Head Movement" controls)

What the head did (also, the "Machine Status" display always matched the physical head location, not an axis shifted location)
–--------
M206 Y10
Home all axes head homes to Y= -10
Jog down to z=0 head moves to y= -20 while moving down (!?)
Jog Z+1 head moves up 1 and jumps to Y= -30 while doing so (!!??)
Jog to max Y Head moves to same physical y max as before the M206 (i.e. it doesn't really help me)
Jog Y+1 a couple of times (beyond the bed radius) the head jumps back y-10
Jog down to y min and a little off of the X axis normal movement
Jog Y+1 repeatedly to get away from the bed radius limit head moves in the X direction a little each time (!!??)

And other (repeatable) bizarre behavior.
But the bottom line is it doesn't move the axis globally. The head still obeys the M665 bed radius limit from the physical 0,0 center, not the axis-shifted center.
Using absolute coordinate gcode moves does remove the strange jumping around but the head still will go where I don't want it to go and it adds the confusion of the status display coordinates no longer matching the gcode coordinates.

Thanks!

@paboman:

where can I also find a list of all supported command by the duet in the documentation ?

All the supported Gcodes are here:
https://duet3d.dozuki.com/Wiki/Gcode

@dc42:

How long is the Bowden tube on your printer; and what was the printing speed?

The bowden tube is about 470mm between Titan extruder and E3D-v6.
Print speed was was 60mm/sec with outline at 48mm/sec.

@dc42:

Your M201 acceleration settings are quite low, which means that you probably have little need for pressure advance. Pressure advance is more important when you use high printing speeds and high accelerations.

I chose to start my testing at this speed as a "known" speed, and expected to ramp up from there. Because I had seen positive impact with Linear Advance at similar speeds on my MK2, I started with the same speeds here on the Delta. I'd agree that my starting position on the MK2 had worse looking corners at 60mm/sec than I do on the Delta. The process I had used on the MK2 was to try to get my 80mm/sec prints look as good as my 40mm/sec prints. I was thinking along the same lines for the Delta.

I had also selected this model since it was closer to my "real world" prints than some of the simpler tests.

Thanks for the insight.

John

After changing microstepping you need to re-home the axes concerned.

I have stall detection working - mostly, still trying to dial it in.

Is it possible to both log and pause? ie, M915 Z S52 F1 R1 R2? I feel this would be quite handy as far as knowing what caused a fault. Logging more details than simply "Warning: Driver(s) 2 stalled at Z height 55.00" would be quite a thing too. The command as I have pasted it certainly doesn't work, but is there something silly I'm missing?

That said, the fact that this works at all on a coreXY machine is amazing.

Another question - I believe the extruder is P3 on my machine (driver 3). This being the case, is it feasible to use stall detection to notice extruder backpressure and pause a print? Or is this idea likely to cause me much gnashing of teeth but not much success? I'm happy to have a crack at it, but just thought I'd see if anyone else has attempted this.

All I will say is there is 3D printing, which requires high precision but only up to a point. You are still making things by typically extruding plastic through a 0.4mm nozzle. Maybe you prefer a 0.15mm nozzle? Achieving 0.1mm precision on printed objects is quite achievable with much less precise hardware than you are talking about. However, there comes a point where it stops being 3d printing or engineering IMO and becomes physics. This is a different thing. Our piezo probes can achieve 10 microns accuracy, I've tested configurations which achieved an accuracy of 5 microns (0.00019685inch). Does this matter to 3D printing - no. We are working at a scale 1-2 orders of magnitude larger than this.

Check out this guy's printers I think it will be up your street.. https://www.nscrypt.com/3d-printing/ 12.5 micron layers, Z probes using laser interferometry etc…

@JohnOCFII:

Parts cooling fans should cool the filament shortly after it comes out of the nozzle. As you mention, you don't wants the parts cooling fan to cool the nozzle. Related, if you have an E3D-v6 hotend, you can use one of their silicon socks to help shield the heat, making nozzle cooling less of a problem.

I found these two articles useful in my understanding of parts cooling for FDM printers:

http://www.desiquintans.com/coolingtests
http://www.desiquintans.com/coolingtests2

THANKS…. very god articles, yours links and David link ... Conclusion, at test fault, think I have the layer fans pointing in bad direction... This confirms, David web info...

https://duet3d.dozuki.com/Wiki/Spurious_heater_faults_and_how_to_avoid_them

I use 20mm pancake steppers with titan extruders they do get hot, I bonded a passive aluminium heatsink onto the back, problem solved.

Yes, config-override.g serves exactly the same purpose as EEPROM does in 8-bit firmwares.

Both config.g and config-override.g contain only GCode commands. See https://duet3d.dozuki.com/Wiki/Gcode for the list.

The SD card file structure and the purpose of the files is documented at https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_SD_card_structure.

HTH David

It was indeed the case. The manufacturer listed the resistance at 100k but it’s more like 50k. I changed this setting on my M305 and now I’m getting the bed up to right temp.

It does take at least a minute before the heat goes all the way into the PEI. I’ll just add a timer before start of a print.

Thanks everyone. I’m calibrating the thing as of now and i have great hopes that I’ll improve quality of my prints

See M584 in the GCodes wiki page.

@timcurtis67:

Are you using relative extrusion in your slicer?

Nope.

ok that many points don't work i need to get G29 working

I printed the one that Phaedrux linked, it works OK as long as you arent using dual extrusion.