As DC42 mentions here:
https://forum.duet3d.com/topic/6815/saving-result-of-simulation-to-gcode-file

The resulting print time of a simulation is stored in the gcode-footer. My experience is that this estimation is very accurate, much more so than estimations from the slicer or DWC during print (based on filamet use, file progress and layer time).

Would it be possible to read this information from the gcode during print and display it alongside of the other print time estimations?

I would also be nice to see the print time estimation from simulation in the gcode file browser.

I think it would be nice if the resulting print time of a simulated (or real) print would be stored in the gcode-file header as a comment. This value could then be displayed in the gcode-file browser to get a good estimate if you would like to print a file again. It could also be used as a fourth estimate (apart from file, filament and layer progress) to get an estimate of when a print is done.

If print time is stored on the first line in the file every time, the most recent time estimate will be on the first line, and older estimates will be further down (if changes made in printer config affects print time)

Together with this, an option to batch run simulation on many files would also be nice. Perhaps an option to simulate all files, all files in a folder or all files that does not contain a print estimate.

I run my BL-Touch (the newest version) with 4 leads through a Molex Micro-Fit. The two GND-leads are internally connected in the BL-Touch. No need to connect both to the Duet board.

A few safetytips in addition to the ones mentioned above:

• Add a fuse with an appropriate rating on 230 V input. I use a separate fuse for the PSU and the bed, but that's not necessary. In my case the bed is at almost 1 kW, and the PSU on 200W and a single fuse would allow quite a lot of extra power to the PSU if the bed isn't active
• As Danal said, connect your frame to protective earth, but also the buildplate if that's conductive.
• Add a temperature switch to your buildplate. I use one rated at 130 deg C, which will protect me in case the SSR fails in shorted mode.
• Use the printer from an outlet protected by a RCD.

To avoid Z-banding it's important that the leadscrews are rigidly mounted in one end. Both ends is a bad idea, especially if the leadscrew or coupling isn't perfectly straight.

I have 3 printers:

• Prusa I2 style: Leadscrews hanging from a flexible coupling on the motor, no support in the bottom. -> Z-banding
• Prusa I3 style: Flexible coupling in the bottom to the motor and a bearing with set-screws on the top. -> no Z-banding
• Hypercube Evolution: Rigid couplings on the bottom by the motors, floating in normal bearing in the top. -> no Z-banding

Using VPN is a much better alternative. It also gives you the possibility to securely connect through your home internet when on a public wifi. I also use my VPN when traveling since a lot of Swedish streaming services will only work if your connection comes from within Sweden.

Installing a OPENVPN server on a spare Raspberry Pi is super easy with for example http://www.pivpn.io

Now it's back to not detecting the SD-card again

The sticker on the back of the board says:
Mini 5+ V1.0
202101-0374

A boot followed by a M122 gives the following output over the USB connection:

RepRapFirmware for Duet 3 Mini 5+ version 3.2.2
Warning: Cannot initialise SD card 0: Card is unusable
Ethernet is disabled.
RepRapFirmware for Duet 3 Mini 5+ is up and running.
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.2.2 running on Duet 3 Mini5plus Ethernet (standalone mode)
Board ID: AVUXR-A196U-D65J0-40KMG-1N03Z-7ZJ7D
Used output buffers: 1 of 40 (1 max)
=== RTOS ===
Static ram: 98732
Dynamic ram: 100904 of which 612 recycled
Never used RAM 44968, free system stack 152 words
Tasks: NETWORK(ready,544) HEAT(blocked,367) CanReceiv(blocked,947) CanSender(blocked,372) CanClock(blocked,363) TMC(blocked,123) MAIN(running,666) IDLE(ready,20) AIN(blocked,272)
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:00:12 ago, cause: power up
Last software reset at 2021-06-05 20:33, reason: User, GCodes spinning, available RAM 44196, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Supply voltage: min 0.0, current 0.9, max 0.9, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 1: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 2: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 3: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 4: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 5: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Driver 6: position 0, ok, SG min/max not available, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0
Date/time: 1970-01-01 00:00:00
Cache data hit count 34743441
Slowest loop: 0.18ms; fastest: 0.12ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 0.2MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.17ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 0 of 8
- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages queued 65, send timeouts 64, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 16
ok

BTW. config.g is still present in the sys-directory

@phaedrux It's v 1.0 ordered from Dold Mechatronik in Germany end of May.

Resoldering the SD-card holder seems to have solved the issue though. Fingers crossed, but now it detects the card every time. I did not have to do anything to the ESD-suppressor.

Hi,

I recently purchased a Duet 3 mini 5+ from one the official resellers. I've noticed problems with intermittet function of the SD-card and found this thread:

https://forum.duet3d.com/topic/21004/duet-3-mini-5-unable-to-connect-via-browser/23

I also get the error "Cannot initialise SD card 0: Card is unusable"

I also saw @dc42 mentioning that it could be fixed with a no-clean flux pen and a hot-air station. Something I have and know how to use...

I was thinking that I will give it a go to fix it instead of sending it back to Germany from Sweden. Is the chip that had the QA-ussues the SD-card ESD-protector denoted U20 in the schematic? Would it be suficient applying flux and reheat it with hot air or should I de-solder it, clean, apply new paste and flux and solder it back? The 0.4 mm pin pitch of the CM1624 is not impossible, but a bit smaller than I'm used with.

Seems like most of you have a very high pressure advance. I run a Zesty Nimble on a Hypercube Evolution with a 0.6 mm E3D Volcano hotend. Sweet spot seems to be somewhere around 0.01-0.03 depending on how flexible the filament is.

I usually run 2 mm retraction at 40 mm/s, seems to work good for the Volcano.

I created this script to generate test files for pressure advance calibration if you would like to try:
https://github.com/LHelge/RRF_PressureAdvanceCalibration

Hi,

When I give the following command to query the current pressure advance:

M572 D0

I get the response:

Extruder pressure advance: 0.020, 0.000

When my pressure advance is set to 0.02. What is the second value? 0.000

I use RRF 2.02(RTOS) (2018-12-24b1)

I've had a similar thought. In my printer I have a 24 V 200 W Meanwell PSU for the duet (steppers and hotends). I also have a smaller 50 W meanwell with 5V and 12V output. Right now I Only use the larger one, but I would like to connect a constant feed to the duet. Would it be possible to do like this:

• Small PSU with constant power, feeding 5V to Duet and 12 V to a few LED-strips and the positive control input on a SSR.
• The negative feed on the LED-strips and the SSR connected to PS_ON pin.
• This SSR turns on power to the main 200W PSU and the SSR controlling the mains powered heatbed.
• Heatbed, small PSU and large PSU each have separate fuses on mains power.

Then the PS_ON pin would turn on the LED-strips and enable power to both the heatbed and themain PSU.

Would this work?

Using VPN is a much better alternative. It also gives you the possibility to securely connect through your home internet when on a public wifi. I also use my VPN when traveling since a lot of Swedish streaming services will only work if your connection comes from within Sweden.

Installing a OPENVPN server on a spare Raspberry Pi is super easy with for example http://www.pivpn.io

I have a P3Steel with Bondtech BMG and standard E3Dv6 (0.4 mm) and a Hypercube Evo with Zesty Nimble and switching between standard E3Dv6 (0.25 mm) and Volcano with 0.6 mm nozzle. I run 0.8 mm retraction at 40 mm/s on all three and it seems to work fine.

I would guess the BMG and Nimble are quite similar since they are both geared direct extruders. But the Nimble is set up with much lower jerk and acceleration.

@garis Would be interesting to se your settings, both slicer and config.g

I also use a Zesty Nimble with 0.6 mm Volcano right now. Around 0.01 seems to be a quite good value for PETG, not even close to resulting in any jerk/acceleration issues.

I've had that problem when the setscrews on the X motor pulley were loose. Could be worth checking.