@Gianluca we haven't yet issued any 3,5,2 beta versions, however we expect to release 3.5.2-rc.1 within the next few days.

@resam Thanks for reporting this and sorry for the trouble you had. Your curl call works as expected with a Duet 3 in SBC mode but something is off in RRF with a Duet 2 in SBC mode. I'm looking into it.

Edit: This is now fixed upstream.

@dc42 I have a question about array assignment. I'll post it as a separate item in Meta Commands, but since you mentioned arrays here and it might be related I thought I'd mention it. See "Question: Array Assignment".

@o_lampe my test was at Z10, as was that done by @achrn. It's not the shape at the top we are concerned with here, it’s that it goes beyond M665 B parameter. The cone at the top is limited by the endstop switches, so I’m pretty sure the firmware takes account of that, though I didn’t test that. It’s why you always have to move down in Z after homing, before moving in X and Y. okay, rereading @achrn’s post, it’s trying to go outside the cone at the top too. I’ll update the issue on GitHub.

Ian

@dc42 Let me know if you need anything from me. I realize I am probably apart a small few experiencing this issue.

I stumbled on to this when upgrading an old Duet 2 Ethernet from v3.3 to the current 3.5.1. I set up my router to assign a specific IP address to the Duet based on the MAC address and had a slight freak out when the DWC couldn't reconnect to the Duet. Might be worth mentioning on the updating firmware page.

https://docs.duet3d.com/User_manual/RepRapFirmware/Updating_firmware

@droftarts Sounds great, just wanted to be sure I wasn't pulling from the wrong repo or anything 😉

Has this happened again since?

@chrishamm said in 3.5.1 forgets whether filament is loaded with M999:

Edit: I've got a bug fix ready. I suggest you change something that modifies the move key at the end of your config.g (as I did with M906 E...) to work-around this problem for now.

Excellent thanks. I changed the 'real' M906 E1000 near the top of the config to a lower value (actually 500) and put my desired M906 E1000 as the last statement in config.g and it now doesn't forget about the filament, either for a M999 or for a full power down and power up again.

@T3P3Tony closing this issue, please comment once tested.

@Nate-Nygren please see my response to this thread which I see you have also contributed to https://forum.duet3d.com/topic/35611/my-printer-reboots-alone/14.

@benecito said in y slope with 3.5.0-rc1, not seen with 3.4.6:

want me to move it to a new thread.

probably would be a good idea to start a new thread. include as much info as you can.

@IndeX4D is ths forum still the right place for questions?

@R006 sounds like its a mechanical issue or you've set speed limits that are higher than your machine is capable of.
if it was a firmware issue, everyone would be affected

@dc42 just a follow upletting you and anyone following this issue that in my case the expression nesting was still too deep even under 3.5.1. I corrected it by making my macro a little cleaner. Basically not loading so much into one variable assignment. but spreading out the math 🙂

@Phaedrux, while not impossible, I don't really know what I am doing. Could you give me a hint as to what you expect to see? There is no apparent (at least to me) difference in printer behaviour between a printer that shows hiccups vs one that doesn't produce hiccups. I don't know if maybe one would see choppy motion for example ... but there is no hint of choppiness.

If it's a bug we can reproduce we can try to fix it.

@chrishamm It appears to be happening much less with 3.5.1, though I was able to trigger a SPI reset; it happened after about 40 moves instead of one or two.

Instead it appears the data capture is being cut off somewhere, as the received data should be 1 second long but i am only getting around 150-350ms of data back for each run. Once in awhile (about every 10 runs) I get a complete data log.

Here's a screenshot showing my settings and the returned data:
db01f3ba-889e-418a-8981-56b10fd9b04e-image.png

EDIT: Looks like I spoke too soon, it seems to be resetting just as often on longer moves (100mm+).
I also validated that the endstop wasn't the culprit by unplugging it after homing, it still seems to reset without that connected.

@dc42 3.5 has gone stable AND you already managed to fix that??

Thanks a lot - and congratulations! That was some really hard work for you and the whole Duet team! If I remember correctly, 3.5. had the longest beta / RC phase of all the RRF versions I saw and used in the last seven or so years.

(edit - after upgrading the printer yesterday, I just took the chance to test the updated function: crash detection works, and now U behaves exactly as X did - i.e. U does not crash into the endstop any more, but the X carriage ends up at places where it should not go. But that bug is just an inconvenience, not critical for the printer)

@omtek thanks for reporting this, and I'm sorry that you suffered a broken nozzle.

I have created issue https://github.com/Duet3D/RepRapFirmware/issues/978 to be resolved in RRF 3.5.1. Meanwhile I have added a new entry in the Upgrade Notes for RRF 3.5.0 to say that any use of M400 in deployprobe.g or retractprobe.g or macros that they call need to have the S1 parameter added.

dc42 created this issue in Duet3D/RepRapFirmware open Using M400 in deployprobe.g causes machine to try to move outside limits #978