Version 3.6.0-beta.2 now available

chrishamm

I'm happy to announce the availability of our next prerelease version 3.6.0-beta.2. Highlights of this version include bug fixes for the new input shaping implementation, a new WiFi server version which addresses potential connectivity issues, and various other improvements.

Please check the upgrade notes as always before upgrading or consider using ReleaseMgr to check for breaking changes. Release notes are available for:

The corresponding files for standalone mode are availalbe here. Users in SBC mode can upgrade using M997 S2 F"unstable" followed by M997 S2 (only supported with the Bookworm-based RPi image) or using the usual apt update/upgrade path.

If you encounter a problem, please open a new thread with [3.6.0-beta.2] in the title.

leone

Hi @chrishamm, I just noticed in the Git tree that the tag 3.6.0-beta.2 is pointing to a commit in the 3.5-dev branch (72d85117). Maybe the intended commit was 4cc23ddc in the 3.6-dev branch? Both have "Tidied up M307 processing" as message.

dc42

@leone thanks for pointing this out. I shall need to delete the release and re-create it to fix this. EDIT: done.

audryhome

Quick questions regarding 3.6.0 Beta.2 on a DUET6HC

Are the M260.1/M260.2 commands available on this beta version as stated in the doc ?

If YES: May I use simulateously
1-DuetWebControl through wifi for console operation
2-io0 serial IO connected t to a custom CNC-Pendant like board
3-io1 serial IO connected to an adapter talking to a modbus device (BLDC controller)

io0:I would send gcode command (M105, M409.... GXXX) through io0

io1:General idea is to keep spindle section electically isolated from DUET to avoid mass loops, since currents (both DUET 48V with NEMA23) and 400W BLDC are pretty high and cabling is quite complex, while having complete gcode control over BLDC (speed, CW/CCW, stall ....)

What is the max baud rate for each interface when used ?

is there any bottleneck/precaution to use this somewhat serial IO demanding configuration?

Of course I will carefully test all this and report any issue and/or success.

If NO or partially available, how long will I have to wait (project planning, I have no killing deadline ) ?

Many thanks for your help

Notepad

Do we know what was changed between 3.6.0-beta.2+2 and 3.6.0-beta.2+3?

Unfortunately I cant find any posts when I use the search with "3.6.0-beta.2+3" even though I can physically see a post with that string in the title https://forum.duet3d.com/topic/37032/rrf-3-6-0-beta2-3-corexy-kinematics-seem-to-be-broken

It might be a good practice to post each Alpha/Beta+X version to the pinned thread as I almost missed B2+3 and the search doesn't seem to be able to find it for some reason.

gloomyandy

@Notepad B2+3 is not an "official release" it is a test build for a particular problem. Those changes (which may not be complete) will probably end up (and be documented) in 3.6.0-beta.3

Notepad

@gloomyandy
That makes sense. I was mostly in the mindset that testing each +X version might identify unexpected behaviours by the small fixes of each unofficial version

gloomyandy

@Notepad That may or not be a good idea, I know that with the stm32 fork (that I look after), interim builds are not always for general use (they often contain experimental fixes and/or additional debug checks etc). Also the time needed to produce/document/test a full release build is quite considerable so I suspect that is why the Duet folks do not post the full details.. So if you do use an interim build use it with care (even more so than with a "beta release") and don't be too surprised if you hit problems, if you do hit a problem it is probably worth reporting it though.

Notepad

@gloomyandy Not to worry, most of our farm is still using the stable 3.5.x.
I do however have about 5 machines dedicated to testing Alpha/Beta + quick fixes/interim builds for the sole use of trying to find what breaks in the firmware so we can provide diag logs to help with the firmware development process.

Plus you never know if a small change has broken something elsewhere, that may only crop up if a machine has been running for X hours before it can manifest

dc42

@Notepad there is now a +4 build at https://www.dropbox.com/scl/fo/ga0jqwfksechhukg2uiz8/AOV3DR8z1C0UWczc8Rx25gE?rlkey=4saeh9luddndvxbhb0kdaqugr&dl=0.

I usually update the "<next release> (in preparation)" notes at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-beta3-in-preparation when I make changes, but I don't record the temporary version numbers there.

NikA

I've a problem with DuetRRF plugin since 3.6.0ß2:
Whenever I try to upload to the printer I get "internal server error".
Uploading via RRF web control UI works.

from Cura log:

2024-12-05 19:16:53,859 - DEBUG - [MainThread] DuetRRFPlugin.helpers.serializing_scene_to_gcode [13]: Serializing gcode...
2024-12-05 19:16:53,969 - DEBUG - [MainThread] DuetRRFPlugin.DuetRRFOutputDevice._onFilenameAccepted [233]: Connecting...
2024-12-05 19:16:54,381 - DEBUG - [MainThread] UM.TaskManagement.HttpRequestManager._onRequestError [394]: request[83eec2f3][get][PyQt6.QtCore.QUrl('http://192.168.1.12/rr_connect?password=&time=2024-12-05T19%3A16%3A53')][timeout=None][no-data] got an QNetworkReplyError Error transferring http://192.168.1.12/rr_connect?password=&time=2024-12-05T19%3A16%3A53 - server replied: Internal Server Error. The server returned: b'"expected start of object"'
2024-12-05 19:16:54,390 - DEBUG - [MainThread] DuetRRFPlugin.DuetRRFOutputDevice._check_duet3_sbc [241]: rr_connect failed with error NetworkError.InternalServerError
2024-12-05 19:16:54,390 - ERROR - [MainThread] DuetRRFPlugin.DuetRRFOutputDevice._onNetworkError [534]: <NetworkError.InternalServerError: 401>

SBC mode with RasPi.

BTW: this occured 2 times since updating to 3.6.0ß2: I connected via browser and Duet web control told me that not all plugins were loaded. I had to start them manually (DuetPi management plugin, height map, input shaping and g-code viewer). I'm not sure if it was browser-related. I've reloaded the website with cache bypass each time the error came up.
With this beta I was finally able to uninstall an old input shaper plugin. I think it was v3.4.x

dc42

@NikA that's one for @chrishamm.

resam

@chrishamm any insights into the error posted by @NikA ?
Was there a code change that I need to integrate into the Cura plugin to make it work with the latest DSF beta?

chrishamm

@NikA @resam I already identified and fixed this problem a while ago. A bug fix will be part of the next beta.