Posts made by Notepad

@Aurimas I can also confirm this has happened a few times on my machines.
If you can make a new thread, Ill post my config.g there for tracking and debugging

@dc42 I also agree with this choice.

@JJJJ Most of the ones on ebay / amazon are fake.
Either buy from RS-components. Direct from factory. Or the link dc42. I use GOLDSSR brand, but its very hard to get them in the country. Most good relays cost over £15.

@JJJJ agreed, gut feel is death via overheating.

install a 128 degree c fuse

Feel free if its easier to install a 150C one. then you dont have to worry about it blowing early if you want to print 110C on the bed for PC-GF or other higher end materials.

That linked relay should be fine, however I personally use SSRs like you found, just make sure they are rated about 2x higher, and have a heatsink, then itll be fine.

@JJJJ Hi there,

No matter what relay you use you will keep encountering this problem. The reason is this is a DC relay. and they get HOT very quickly.
SSR relays fail deadly when they get too hot, and they fail in a way unable to shut off the relay.
Have a look at W70 heatsinks. These are designed to be used with the relays passively, but I personally always add an active cooling fan as well.

Sometimes when a relay overheats it can permanently damage itself. If it resets it might be fine to still use. but personally I would replace the entire thing.
If you bed is also powerful enough to cause a fire hazard if the relay fails, you can always put two relays in series, so it would require both relays to fail before the bed becomes uncontrolled.
alternatively, you can add a thermal fuse onto the bed -which is what I do

Additionally, these relays CAN BE (but not always) directionally limited. Try plugging the PSU positive into the relay terminal 2, then the relay into the bed positive into Relay terminal 1.

@SonnyD1 The power supply is good as it has integrated filtering. If you did want a cheap solution without changing the PSU, have a look at filter EMI power receptacles.

@jltx Have a look at M2.5 low profile bolts. I recommend the ones with a torx slot as its easy to strip M2.5.
I personally use the M2.5 ones and the head is about 0.8mm thick
https://www.aliexpress.com/item/1005005070119421.html

@SonnyD1 This is going to sound real odd. But what powersupply are you using.
I know the M122 says the reason is a software shutdown. But I have experienced in the past a weird brownout situation where one printer with a cheap PSU was browning the entire power ring for my house, and it would randomly do weird power spikes which caused machines to fail

@dc42 Yup, this machine is still on beta.4 The rollout of RC1 has been applied to most machines, but ones still ill a production job are still on B4

@dc42 I got sent this from the print farm, unfortunately its not the WebUI full log but this might help be

@dc42 At the moment we are making our own 4 wire (twisted pair 24AWG) runs with double wrapped ferrites on each end. Lengths 850mm and 1.4mtrs. We do have other machines planned that might need longer lengths, but these aren't specified yet
This works for us and the ferrites keep the EMI to within Class B which is great. Only downside is we have to make our own bundles which is just a chore, and we cant use the SD card slot.

I did a quick search on the forum for any posts regarding the USB port on the PanelDue having a separate mode but couldn't find anything. So i was just wondering if there was any reading material surrounding this update

@chrishamm Do we have any available documentation for the

The USB port can now be switched into PanelDue mode (support for this may not be complete)

This would solve so many issues I have with long cable runs for the PanelDue

@dc42 Dang, Ill try capture it next time. The code 7 has been incredibly rare for me, this is the first over 12 machines

Hi all, Had my first Code 7 today. Ive attached the M122 for any needed debugging

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-beta.4 (2025-02-11 09:50:40) running on Duet WiFi 1.02 or later
Board ID: 0JD2M-9F8TA-GJ4TJ-6JTF4-3SD6L-16VG6
Used output buffers: 3 of 26 (24 max)
=== RTOS ===
Static ram: 24016
Dynamic ram: 68220 of which 0 recycled
Never used RAM 10264, free system stack 68 words
Tasks: NETWORK(1,ready,15.6%,181) LASER(5,nWait 6,1.5%,214) HEAT(3,nWait 5,0.1%,307) Move(4,invalid,7.0%,239) MAIN(1,running,75.8%,736) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 07:38:49 ago, cause: power up
Last software reset at 2025-02-25 15:15, reason: User, Gcodes spinning, available RAM 12712, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 11.5ms, write time 535.5ms, max retries 0
=== Move ===
Segments created 729, maxWait 1677858ms, bed comp in use: mesh, height map offset 0.000, hiccups added 57/113 (3.51ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 19909.00/20410/-0.49 6675.00/6893/-0.86 15700.00/15693/-0.79
No step interrupt scheduled
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min 0
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 340521, completed 340481, LaErrors 0, Underruns [0, 0, 0]
Segments left 6
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 3
USB is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
=== Network ===
Slowest loop: 537.88ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.2.1
Module reset reason: Power up, Vcc 3.36, flash size 2097152, free heap 39160
MAC address a4:e5:7c:03:da:6c
IP address 192.168.1.174
Signal strength -71dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

@bernardomattiucci

Interesting that you are saying your filament gets stuck. What type of filament are you using. I find Matte and Silk materials tend to be the most likely to clog over time.
Would it be also possible for you to show your Config.g so I can see what motor current you have your hemera set to? It could be the amperage is too high and its heating up the motor enough to soften the filament in the cold side.

@bernardomattiucci As Jay has said you would want to remove the checkbox in your slicer.

For reference (as the firmware retraction values are quite low) the Hemera retraction speeds should be between 40-70mm/s and a 0.8-1.2mm distance.
The faster your printers travel moves, the less retraction distance you need as there is less opportunity for the material to ooze

@Ce72 "Fail Deadly" is simply just the opposite of "Fail Safe". A failsafe relay would open the circuit stopping power from transferring. These SSR style relays all tend to faildeadly if they get too hot. Normally these relays run quite cold, but if its getting towards the EOL, there is a chance its accidently keeping the power on for too long causing heat based pulsing, similar to BangBang z banding. This would explain your PID tuning inaccuracies.
Its very unlikely as these relays are pretty robust, But I have had 2 personally die on me even when they are joined with the officially recommended W70 Passive Heatsink.

@Ce72 There is a possibility it could be the relay controlling the heater bed. If its an AC relay, they do tend to fail deadly if they get to hot

You might be happy to know you can up the mesh points to 900. I use a 30x30 grid (specifically because I use the Duet Scanning Probe) with no issues.

@Ce72 Some things come to mind seeing this. Because the slicer seems to have an impact on the visual artefact. it could be related to extrusion multiplier on a material basis. whilst the print settings might be the same, there might be small differences in the material settings for each slicer.

Its weird that the woodgrain test appears to be normal and and then your next two prints have this weird artefact.
One noticeable difference between the woodgrain vs the two gray prints, is it looks like the grey prints are larger in XandY.
This does mean we cannot exclude the Z axis from this behaviour, as it could be a byproduct of the bed mesh compensation (though the chance of this is unlikely)

Unfortunately I couldn't tell from the photos of the grey prints if the angle of the banding changes when the model becomes slightly thinner. that would be a strong indication that the problem is extruder related instead of the motion system.

@Triet Which firmware version are you using. The new 3.6.beta4 firmware (findable in the beta firmware forum category) is absolutely fantastic as it has a new input shaping methodology, You may find this helps your issues.