RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released
-
@dc42 Will you be sticking a fork in 3.01 sometime this year or can we expect 3.01RC50 sometime around Christmas?
Continuing to add new features to release candidates goes against pretty much every definition of "release candidate". -
@gtj0 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
@dc42 Will you be sticking a fork in 3.01 sometime this year or can we expect 3.01RC50 sometime around Christmas?
Continuing to add new features to release candidates goes against pretty much every definition of "release candidate".Agreed! I have been waiting for DSF to catch up with RRF so that we can do a 3.01 release in which the functionality with SBC is as good as the functionality standalone, and to be sure that the SPI transaction protocol between RRF and DSF is stable. The last few RRF releases have been mostly bug fixes, however as I had time I thought it worth bringing a couple of minor features forward that had been intended for the 3.02 release. That's why I added the aux raw mode in this release - a feature that several users have asked for.
Now that DSF has caught up with RRF in almost all respects, I really hope that the next release will be 3.01 stable. But that depends on no serious bugs being reported in RRF 3.01-RC11.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
@gtj0 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
@dc42 Will you be sticking a fork in 3.01 sometime this year or can we expect 3.01RC50 sometime around Christmas?
Continuing to add new features to release candidates goes against pretty much every definition of "release candidate".I thought it worth bringing a couple of minor features forward that had been intended for the 3.02 release. That's why I added the aux raw mode in this release - a feature that several users have asked for.
Now that DSF has caught up with RRF in almost all respects, I really hope that the next release will be 3.01 stable. But that depends on no serious bugs being reported in RRF 3.01-RC11.
It's a well known corollary... "The least significant new feature slipped into a 'final' RC will be the source of another RC."
-
DSF mode: In Marlin response, io_1 in raw mode isn't outputting "ok" consistently.
https://forum.duet3d.com/topic/16016/rrf-3-01-rc11-dsf-mode-io_1-not-outputting-ok-consistently -
Duet 3 users: Connector IO_0 is no longer dedicated to PanelDue, therefore if you connect a PanelDue to this port you must use the following command in config.g to enable it: M575 P1 S1 B57600
Does that imply that only 57600 will work with the paneldue and duet3?
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
@garyd9 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
Duet 3 users: Connector IO_0 is no longer dedicated to PanelDue, therefore if you connect a PanelDue to this port you must use the following command in config.g to enable it: M575 P1 S1 B57600
Does that imply that only 57600 will work with the paneldue and duet3?
No, you can use other baud rates too.
-
@garyd9 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
Duet 3 users: Connector IO_0 is no longer dedicated to PanelDue, therefore if you connect a PanelDue to this port you must use the following command in config.g to enable it: M575 P1 S1 B57600
Does that imply that only 57600 will work with the paneldue and duet3?
Confirmed: It works fine on the Duet3 at 115200.
-
DCS 2.1.3: M500 writes invalid G10 command to config-override.g
https://github.com/chrishamm/DuetSoftwareFramework/issues/130 -
M117 does not allow conditional gcode statements to be inserted into a string.
https://forum.duet3d.com/topic/16036/rrf-3-01-rc10-bug-m117-and-conditional-gcode-statements -
I've put new RRF binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 to fix the following:
- Changing baud rate for the PanelDue port didn't work unless the M575 command was repeated. Note that in this version, the M575 command is mandatory when using a PanelDue, even on the Duet WiFi, Ethernet and Maestro.
- Virtual extruder position was missing from the object model
- HTTP requests for files with very long names reported a "Filename too long" error and didn't return a response. They now return a 404 response and issue a warning of a possible virus attack from the sending IP address.
On the Duet WiFi, Ethernet and Maestro it shojud now be possible to use the two I/O pins of the PanelDue port as GPIO, if there is no M575 p1 command in config.g.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
Note that in this version, the M575 command is mandatory when using a PanelDue, even on the Duet WiFi, Ethernet and Maestro.
temporary or something that will be part of 3.01?
-
@bearer said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
@dc42 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
Note that in this version, the M575 command is mandatory when using a PanelDue, even on the Duet WiFi, Ethernet and Maestro.
temporary or something that will be part of 3.01?
All of these changes will be included in 3.01 stable.
-
The "iterations" meta command variable isn't handled correctly when using a D3+SBC setup. This was discovered when attempting to use the example object identification macro posted here. The code example there works as intended when the D3 is used in standalone mode, but returns an error in a D3+SBC setup.
-
-
@ChrisP said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
The "iterations" meta command variable isn't handled correctly when using a D3+SBC setup. This was discovered when attempting to use the example object identification macro posted here. The code example there works as intended when the D3 is used in standalone mode, but an error if the a D3+SBC setup.
@ChrisP said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
The identification of objects by parsing the object label comments (PrusaSlicer) and process comments (Simplify3D) for object cancellation features etc. currently works on a D3 in standalone mode but fails if using a D3+SBC setup. Noted here, but first identified here.
These will get better attention if you open issues for @chrishamm on GitHub if you can.
-
@dc42 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
- HTTP requests for files with very long names reported a "Filename too long" error and didn't return a response. They now return a 404 response and issue a warning of a possible virus attack from the sending IP address.
Wat?
-
@bot said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
@dc42 said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
- HTTP requests for files with very long names reported a "Filename too long" error and didn't return a response. They now return a 404 response and issue a warning of a possible virus attack from the sending IP address.
Wat?
See https://forum.duet3d.com/topic/15346/duetwifi-error-filename-too-long.
-
Perhaps one for @chrishamm ....
I had previously reported here that a pause caused by the filament sensor resulted in the printer just halting this was with D3+SBC setup. On trying again in standalone, the pause works as expected and can be resumed. Therefore a DCS issue? -
@ChrisP said in RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released:
Perhaps one for @chrishamm ....
I had previously reported here that a pause caused by the filament sensor resulted in the printer just halting this was with D3+SBC setup. On trying again in standalone, the pause works as expected and can be resumed. Therefore a DCS issue?I believe that issue is already on his list to look into.
