RRF 3.01-RC11, DWC 2.1.6 and DSF 2.1.3 released
-
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.
