Topics created by Argo

@Argo thanks for reporting this. Please test again with beta 3 when we release it.

@dc42

Thanks! I can confirm that problem has been fixed.

@CCS86 @dc42 made a build of 3.6.0-beta.2 for Maestro for internal testing, to see how bad it would be. I tried it on my Maestro-equipped delta printer. This was printing at 100mm/s, bed mesh but no IS or PA, and had a large number of hiccups, totalling almost 12 seconds of time in a simple 15-minute print (which is a lot)

=== Move === Segments created 88, maxWait 138992ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0/133392 (11888.88ms), max steps late 0, ebfmin 0.00, ebfmax 0.00

While visibly the print looked okay, the lack of FPU on the Maestro means it just can't handle the code complexity. If it was this bad with this simple example, it would just get worse with anything more complicated.

I also tested the same print on 3.5.4. No hiccups, but one Underrun, which is less of an issue than actual hiccups (for some reason I did it without mesh enabled, though)

=== Move === DMs created 84, segments created 47, maxWait 10279136ms, bed compensation in use: none, height map offset 0.000, max steps late 1, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 1.00 no step interrupt scheduled Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0 === DDARing 0 === Scheduled moves 207302, completed 207302, hiccups 457, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1

As a 'cheap' version of the Duet 2 WiFi/Ethernet, the Maestro has had a good run. Duet3D EOL'd it June 2020, and I think the design is nearly 7 years old, back when the RRF 1.x was current. It still works, it just hasn't got the power to support the firmware developments made in that time.

Ian

@dc42

Once again I’m impressed.
Thank you. Your suggestion was spot on. I have installed a frame thermistor because I’m observing thermal frame expansion on Z and that frame thermistor got loose and touched the frame which caused ESD which I can also reproduce.

@chriss I started working on my corexy printer before they became popular. At the time I saw some forum posts from people who had built them using linear guides complaining that when the temperature in their shop changed 10 or 20 degrees, the XY mechanism would bind. The loose coupling for the X axis (and no additional support) was my response to that problem. I heat that printer to 50C when printing ABS and it never binds.

I haven't had any problems with first layer adhesion, either, even though the printer has no auto tramming or bed unflatness compensation.

@gloomyandy

Correct. PID tuned as a heater the variance is +/- 0.2°C at max which is pretty good.
So PID tuning as a heater works for me but I suspect it's not how the feature "PID as tool" is intended to be.

About my Hotend:
The Rapido is quite isolated and the fan shroud is optimised with simulations etc. (not by me). So there is not much fan hitting the nozzle.

@dc42
Second K value = zero is the same as PID tuning the hotend as a heater and not as a tool? Then see my response to gloomyandy. That works quite well.

Interesting! My take:

Interpolation: we've never noticed any problem, although we know that interpolation can't be accurate during acceleration and deceleration. I think any error should be very small, less than 1 or possibly 2 microsteps. If it does cause a tiny error, then using interpolated 1/32 microstepping instead of the default interpolated 1/16 microstepping should halve the error.

Hold current (called standstill current reduction in RRF): we don't have any reports of issues using hold current. The default for those Duets that support it (Duet Maestro and all Duet 3s) is 70%. If a non-moving motor is under a static load then it's certainly possible that the reduction to hold current after the motor hasn't moved for a short time could cause a slight shift, especially if the hold current is set lower than the default. This might perhaps be seen when a CoreXY machine does a printing move at exactly (or very close to) 45 degrees to the XY axes, because then one of the XY motors won't be moving and the movement of the other motor will apply a load to it. RRF has a separate idle current factor that is used after all motion has stopped for a while.

StealthChop: I recommend disabling stealthChop anyway except perhaps at very low speeds (to reduce idle noise), because it makes the printer more likely to skip steps when the load increases suddenly, for example if the nozzle hits a blob or overhang. I can well believe that it affects print quality, because it works by reducing motor current and hence torque to the minimum that is deems is necessary.

@argo thanks. Thanks to your example I found another bug, which is that if a macro contains a non-blocking M291, some motion and then a blocking M291, with no M400 or G4 between them, then the blocking M291 can appear ahead of the non-blocking one and then you can't cancel the blocking one. This is fixed in the forthcoming 3.4.0rc1. Please try 3.4.0rc1 when that is released.

RRF 3.4b7:

I first calibrated my PA.

IMG_0801.jpg

Then some real world testing with PA set to 0.064 and

IMG_0872.jpg

To get rid of the bulging I would need to increase to very high PA values which does impact all other areas whilst printing like starving infill ends etc. (see pictures above).

Used input shaper: M593 P"zvdd" F54.32

With RRF 3.3 I had similar PA values but no overshooting corners.

@argo thanks for confirming this.

@dc42 said in Input Shapers: 2HUMP_EI & 3HUMP_EI + Auto Tuning:

@ccs86 that entry in that table is incorrect.

Edit: I have corrected it.

@dc42 That makes a lot more sense. Would you mind shooting me a PM?

@Argo I’d guess the bed pwm is interfering with the probe. You can turn off heaters when probing, using the B parameter of M558. See https://duet3d.dozuki.com/Wiki/Gcode#Section_M558_in_RepRapFirmware_Num_3

Ian

Thanks. It's normal to get one write error per driver the first time you run M122 after power up or reset. Running M122 clears the error counts, so they should read zero after that unless you get a VIN under-voltage event.

@jay_s_uk

Thanks. I'm using a newer version of python and the cmd is py not python. That why it didn't work.
It's working now.

I've compiled a stable 3.2.2. firmware (Duet 3 Mini 5+) with the TMC22xx.cpp fix from 3.3b1, so sensorless homing does work without loud crashing 😃
Now, after 2-3 full days of experimenting, time to enjoy this nice new board a bit.

If anyone needs it, here you go: https://www.file-upload.net/download-14505164/Duet3Firmware_Mini5plus.uf2.zip.html

@Veti said in Duet 3 Mini noisy StealthChop + no sensorless homing:

@dc42
its not in the changelog

Thanks for pointing this out. It is now.

@Kolbi Thank you so much for this spreadsheet, it made it so much easier to configure CoolStep for me. Currently have my steppers running at 1/2 amperage mininum and temps went down from 58C to 33C without dropping speed/accel/jerk settings.

I did just switch the case fan from constant power to fan2 and followed the guide here: https://duet3d.dozuki.com/Wiki/Mounting_and_cooling_the_board#Section_Cooling

M308 S2 Y"drivers" A"DRIVERS" ; configure sensor 2 as temperature warning and overheat flags on the TMC2660 on Duet M308 S3 Y"mcu-temp" A"MCU" ; configure sensor 3 as thermistor on pin e1temp for left stepper M950 F2 C"fan2" Q100 ; create fan 2 on pin fan2 and set its frequency M106 P2 H2:3 L0.15 X1 B0.3 T40:70 ; set fan 2 value

""""Creates sensors for the driver overtemp flag and the MCU temp reading using M308 as S2 and S3. Creates a fan port for Fan2 with M950. Then creates a fan command to link those sensors to fan2 with a temp range of 4code_text0-70 using M106.""""

*This made the case fan MUCH quieter and with that it only runs when its needed.

This is exactly what I has having a while back.

My IR probe was having issues reading my printed glass bed and I switched to a regular glass. Now it is much better but because it is much flatter.

My bed has a slight lower in the upper left corner and I print nothing there as it won't stick because it is too far from nozzle (0.2mm difference)

i have this line in config-override.g that helped too:

M376 H10 ; Set bed compensation Taper