@RogerPodacter your M669 command is referring to axes and motors that don't exist at that point because the M584 command that creates them hasn't been run yet.

@droftarts my guess is 99% a problem in dwc especially with the changes in multi-stream input behavior handling, but I have not had a chance to repro and see what devtools says

@Herve_Smith
i did, but it kept giving errors, I switched back and forth between stable and unstable, reset date/time, and it then worked.

IS is working in beta4 on markforged kinematics, so it indeed was a bug in beta2

@dc42 If there's a code bug it's probably not duex specific, I have the same issue when running the strip from the duet2 wifi.

@dc42 This did not fix the axis drop when sending m18 but it did seem to keep the axis from dropping upon hitting emergency stop.

I also noticed on this belt driven z with the 1HCL that sometimes the axis will drop during tuning using 3.5.0-beta4 (and still with beta4+ from dropbox). I believe I've fixed the issue by increasing the current slightly but if it worked in 3.4.5 with the lower current that would be the ideal situation. Can open a new thread for this if need be.

Overall the new firmware is making my X and Y 1HCL axes run super smooth/quiet and they seem to be able to run much faster than before.

Cheers,
T

@jens55 3.4.6 contains critical bug fixes, not all the (significant) new features of 3.5.

@chrishamm Thanks Chris. That did it

Hi,

Checking back in to see if anyone has any advice on how best to adjust the M307 code.

Previous to 3.0 I think it heated well with no issue and the new heater algo means that it really struggles to both Autotune and reach 70-75 degrees

M308 S0 P"temp0" Y"pt1000" A"bed Heat1" ; configure sensor 0 as thermistor on pin temp0 T100000 B4725 M950 H0 C"out1" T0 ; create bed heater output on out0 and map it to sensor 0 ;M301 H0 P-10 I0.2 D50 T0.3 M307 H0 R0.051 K0.098:0.000 D32.76 E1.35 S1.00 B0 ; old M307 H0 R0.066 K0.191:0.000 D45.54 E1.35 S1.00 B0 ;M307 H0 R0.076 K0.292:0.000 D42.95 E1.35 S1.00 B0 ;M307 H0 R0.070 K0.416:0.000 D62.44 E1.35 S1.00 B0 ; disable bang-bang mode for the bed heater and set PWM limit M140 P0 H0 ; map heated bed 0 to heater 0 M143 H0 S90 ; set temperature limit for heater 0 to 90C

That's the current setting for one of three heat beds.

Thanks in advance,

Nate

Any updates?

@dc42
Thanks for the clarification.

@chrishamm resolved in b4, thank you 👌

@tas This problem has now been solved by @chrishamm. Refer to this post by @alexjx

https://forum.duet3d.com/topic/32762/3-5b4-input-shaping-plugin-bug-data-collection-cancelled/13?_=1687311263398

Go down to the google drive link provided.

Thanks for the combined effort @chrishamm, @droftarts, and @jay_s_uk. Also thanks to @alexjx for zeroing in on the problem so it could be solved.

@jay_s_uk Excellent! Thank you. This works on my Duet 2 Wifi standalone.

@Ethelred please start a new issue. That is a different issue to the one being discussed

@RogerPodacter Best to start a new thread as this one is marked solved.

@mikeabuilder

Not sure if it helps - but my understanding of prusaslicer is that if you include heater settings in Printer Settings --> Custoem G-Code then prusaslicer will not emit its own.

I don't have time to check now, but I recall that the current prusaslicer beta (2.6.0) includes an option to specifically inhibit heater gcodes (even if you do not set them yourself as Custom G-Code).

@chrishamm I isolated the problem to be specific to only one of our machines. So it's not firmware related, the problem is on our end 🙂

@Skan can you start a new thread please and provide all the relevant information

@cichaczech thanks for confirmation! The fix will be included in 3.5.0-rc.1. I'll mark the Github issue I created at https://github.com/Duet3D/RepRapFirmware/issues/869 solved.

dc42 created this issue in Duet3D/RepRapFirmware closed [3.5beta3, beta4] Unexpected reset when using laser mode #869

@jay_s_uk
Thank you!
It worked