Posts made by Notepad

@dc42 Reading the release notes are one of the major highlights of the updates!!

@elmoret Can confirm, E3D testing is always a "worst case" recommendation. The max motor amperage is only if they are pushing ultra high flow high pressure, in a 50+C heated chamber, for extreme lengths of time.
You may want to raise your amperage as that would give you more force available.

@Pat Thats interesting as PA has been changed quite heavily between 3.5.4 and 3.6.x

@luc Less current normally means less vibration force. If it works, Try 1200 or 1400

@o_lampe OO very interesting, I never considered the difference between 19 20 and 21 tooth. Id say start with 21 tooth as bigger pulley = more grip

@luc This could be many things, and is generally referred to as VFAs (Vertical Fine Artifacts)
Whilst there is not much you can do about it as it could be a variety of issues, I have a few tips that might be able to help find out where the problem lies.

1. Belt tension, If the belts are too tight the tooth patten may show up in the printed surface
2. Motor accuracy. Motors have predefined "steps" which the microcontroller smoothes out. Try printing the part faster or slower, and see if that changes the surface regularity. If it does, then it means you might have a printing speed close to the motors resonant frequency
3. If speed doesn't fix it, then it might be a bearing, either the motion system or the extruder.

In general on a 20T belt pulley, I find printers have 2 resonant speed frequencies, 60-80mm/s or 100-130mm/s. Try to find out which one your motor doesn't like, and avoid those speeds.
You also want to loosen your belts as much as possible without compromising your accuracy or risk belt slippage. its VERY easy to overtighten your belts if you don't have measurement equipment.

Just piping in for visibility, I have noticed one of my prints on RC2 had extruder skipping steps on what looked like exterior perimeters on a smooth curved object.
I've not printed enough on RC 2 to say if its the print settings or the firmware or enough time to do further testing. But thought it might be relevant enough to add a +1 to this thread just in case it shows up later.

@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