I am quite happy with this DWC 2.1.2 + RRF 3.01-RC7 combo.

DWC somehow feels more responsive, and my phone loads DWC without issues now. It often happened that the loading of DWC froze with the 'blue bar' halfway, and I had to reload a few times.

@bearer said in SDCard errors - Duet3, various 3.01 betas:

Doing a full format, preferably with the sd formatter tool, can help stability, at least for a while. On the other hand Murphys law..

...

@garyd9 said in SDCard errors - Duet3, various 3.01 betas:

I use the one suggested by the duet wiki. I also turn off the "quick format" option in most cases to ensure every byte on the card is touched (so that any errors are seen during the format.)

As for Murphy's Law, that also dictates that if the copy machine repairman is on the premises (dc42 is watching this thread), that the copy machine will work perfectly.

Thanks for considering these topics. Timing "is what it is" with changes this big, that's understood. Thanks for taking a look at some of the fundamental directions.

DWC 2.1.2 and RRF 3.01-RC7 are now available too.

@dc42 stupid me, thank you so much!

You could have the problem that filament monitoring is only active when printing from teh SD card
https://duet3d.dozuki.com/Wiki/Gcode#Section_M591_Configure_filament_sensing

Thank you 👍

@Pumlux said in RepRapFirmware 3.01-RC5 available:

It might be a worth to change the B1 parameter to B0 in the toubleshooting doku for BL-Touch.

Well the problem with that is that turning the heaters off is a solution to other BLTouch problems, so it's not as simple as one way works for all cases.

As DC42 mentioned, the real solution would be to use M116 to wait for temps to return to the set point before proceeding.

It would also be a good idea to check to see if B0 or B1 works better for your setup.

@brendon Sorry to hear you're having problems with the CAN board while connected over the SBC. I'd like to figure out why it is happening, but I will need two separate debug logs for this. Can you please connect your Duet 3 over USB to a computer, open a serial terminal, send M111 P3 S1 and try to reproduce this bug once with the SBC connected and once without it? I hope that will allow me to spot differences in the execution of G/M/T-codes and to track down the underlying bug.

@blt3dp I have tested it and it's working, although I believe the performance could be further increased. Besides DSF does not write the print/simulation times to the G-code files yet.

This is solved in DSF 1.3.0

Check out my config.g for my ToolChanger. It is important to note that I am using CAN toolboards, but if you adjust the extruder drive mapping, heater output, and thermistor inputs it might be helpful:

https://github.com/bdtower8/Duet3ToolboardToolChanger/blob/master/sys/config.g

Line numbers that would need to be changed:

40, 61, 62, 66, 67, 71, 72, 76, 77, 83, 86, 89, 92

@droftarts ,I try to reduce it to 16mm / s

Nice find, and great that it is working now.

I've just removed the ^ too and as expected - makes no difference.

Correct setup for analog is

M558 P1 C"zprobe.in" R0.5 H3 F360 T9000 A5 S0.03 ; P1 = Analogue mode G31 X0 Y0 Z-0.1 P530 ; X, Y, Z offsets, P530 = trigger threshold

and for digital:

M558 P8 C"^!zprobe.in" R0.5 H3 F240 T9000 A5 S0.03 ; P8 = Digital mode (unfiltered) G31 X0 Y0 Z-0.1 P100 ; X, Y, Z offsets, P100 = debounce interval

If your probe is inconsistent you could switch to using manual probing (M558 P0) which would prompt you to manually jog the nozzle to touch the bed.

The problem is that without establishing exactly where Z0 touches the bed, you are depending on the endstops to have a perfectly calibrated Z height from the bed surface, which is difficult to do.

Also, if your height map was generated without first accurately defining the bed surface, it can cause an offset to be present when you load it.

I hope that makes sense.

I know you don't want to be messing around with things at times like this. Good luck with the face shield printing.

@DIY-O-Sphere, thanks for reporting this. I have fixed it in the internal build of RRF at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Wooo Hooo!!! Good find.

The object model DID change. 🙂

Yeah I don't get it either. I'll track it down, thanks!

Might you be in absolute extrusion mode when you run that macro? Try putting M83 at the start of it.