RepRapFirmware 3.01-RC6 released

[zerspaner_gerd]

Hi there,

Can it be that the G30 S-3. is no longer working properly?
With RRF2.05 this was saved automatically, max. an M500 was necessary.
Now it only works again with M500 P31

DWC shows the following message:

But config-override.g was not saved

greetings

[mwolter]

@garyd9 Try indenting the two dummy comments to the same level as the while loop. Have a feeling it sees them unindented and stops the while loop at that point

[dc42]

@garyd9 said in RepRapFirmware 3.01-RC6 released:

My best guess is that a previous RC would completely ignore comment lines, but the current RC will use still use the comment line indentation to determine end of loop.

That's correct. RRF used to throw comment lines away early on during processing. It no longer does that, because it parses certain comments for useful information during printing, e.g. comments containing object labels.

[gtj0]

@dc42 I don't think this has been reported already but move.extruders.factor only reports to 1 decimal place precision so for instance, if you do a M221 and set the value between 96 and 105, the reported value is still 1.0. This is the RRF value reported from M409 as well as from DSF.

[gtj0]

@gtj0 said in RepRapFirmware 3.01-RC6 released:

@dc42 I don't think this has been reported already but move.extruders.factor only reports to 1 decimal place precision so for instance, if you do a M221 and set the value between 96 and 105, the reported value is still 1.0. This is the RRF value reported from M409 as well as from DSF.

It looks like the move speedFactor is the same way.

[dc42]

Thanks, will be fixed in RC7.

[gtj0]

@dc42 @chrishamm I'm not sure if this is an RRF or DSF issue but I just did a pause and resume and this happened...

The extruder was drawing a brim counter-clockwise and the pause was done at the 7 o'clock position. My pause script moves the extruder without an increase in Z to prevent a blob from forming, then raises Z. When I resumed, the extruder returned to the spot it was paused but instead of continuing to follow the outline, the extruder moved directly to the 3 o'clock position and continued drawing the outline counter-clockwise. It's as though the moves in the buffer at the time of the pause were discarded.

; pause.g
; called when a print from SD card is paused
M83            ; relative extruder moves
G91            ; relative positioning
G1 X5 Y50 F3600
G1 Z50 E-5 F600   
G90

; resume.g
; called before a print from SD card is resumed
M83                  ; relative extruder moves
G1 E5 F100         ; extrude 5mm of filament

[dc42]

This sounds similar to a report from another user regarding unwanted extrusion during a tool change. We determined that it didn't occur in standalone mode, so it looks like an issue with DSF synchronising commands at the start and end of macros. There has been a lot of work on DSF and macros done recently, so I hope this will be fixed in the next 3.01 RC release of RRF and the corresponding DSF release.

[SpoonUnit]

Not sure if this is another known issue or not, so will add here. I'm finding that the combination of pause and resume result in a small change to the Z coordinate as reported in DWC. Have reduced pause.g to this:

M83			; relative extrusion
G10			; fw retract
G91			; relative motion
G1 Z5 F1200	; up 5mm
G90			; absolute motion
 
; swap spot
G1 X150 Y-30 F50000	

and resume.g to this:

G10
G1 R1 X0 Y0 Z5 F99999
G1 R1 Z0 F500

Repeated executions of pause/resume result in the nozzle getting slowly but surely closer to the bed. This only seems to occur if bed leveling is engaged via G29. If bed leveling is not in play, Z is unaffected. I've only tested this personally with RC6, but I believe it also occurred on RC3. I can't speak to whether this occurred before that release.

I do notice a complex resurrect.g is generated which also references a resurrect-prologue.g which is not present. Hope this is enough to go on.

[gtj0]

@SpoonUnit Do you use a probe and if so, what's its offset? Is the reported offset equal to the probe offset? Is it equal to the heightmap correction that would be applied at the location the pause was done, or the XY point you move to?

I've noticed that when I do a bed level (G32) with a dive height of 5mm and a probe offset of -0.05 that Z is left at 4.950. I'm wonder if if this is related.

[SpoonUnit]

@gtj0 I use an endstop switch as the probe, and the definition is as follows, including the mesh definition used for G29:

M558 P8 C"zstop" H3 F360 I0 T35000 ; Set Z probe type to switch, the axes for which it is used and the dive height + speeds
G31 P200 X0 Y0 Z0 ; Set Z probe trigger value, offset and trigger height
M557 X0:300 Y0:200 S33.3 ; Define mesh grid

I haven't tested whether I can produce an error with each tool yet, each of which has a slightly different Z offset for the nozzle itself. The problem certainly manifested itself with T0, where the offsets are defined as follows:

G10 P0 X-9 Y40 Z-4.9575

Therefore, the Z probe offset for T0 is -4.9575. This is definitely not the observed change in Z observed after a pause/resume cycle. It does seem far more likely to be related to the heightmap correction at the point of the pause.

[xnaron]

With this release I am unable to get the extrude button to become active in the webgui after the hotend heats up. See below for details.

https://forum.duet3d.com/topic/15580/3-01-rc6-extrude-button-does-not-come-active

[Hernicz]

I'm having issues with RC6 and RC8 (havent tried RC7, but possibly affected)
Using SBC ( RPi 3B ) I cannot get connected to Duet 3.
"Invalid protocol version 2"
I can connect with RC5.

Here's the journal output:

-- Logs begin at Sun 2020-04-19 17:17:01 BST, end at Sun 2020-04-19 17:57:41 BST. --
Apr 19 17:57:06 Wardialer-X5SA systemd[1]: Started Duet Control Server.
Apr 19 17:57:09 Wardialer-X5SA DuetControlServer[324]: Duet Control Server v1.2.4.0
Apr 19 17:57:09 Wardialer-X5SA DuetControlServer[324]: Written by Christian Hammacher for Duet3D
Apr 19 17:57:09 Wardialer-X5SA DuetControlServer[324]: Licensed under the terms of the GNU Public License Version 3
Apr 19 17:57:12 Wardialer-X5SA DuetControlServer[324]: [info] Settings loaded
Apr 19 17:57:12 Wardialer-X5SA DuetControlServer[324]: [info] Environment initialized
Apr 19 17:57:13 Wardialer-X5SA DuetControlServer[324]: [error] Failed to connect to Duet
Apr 19 17:57:13 Wardialer-X5SA DuetControlServer[324]:    System.Exception: Invalid protocol version 2
Apr 19 17:57:13 Wardialer-X5SA DuetControlServer[324]:    at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christia
Apr 19 17:57:13 Wardialer-X5SA DuetControlServer[324]:    at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean mustSu
Apr 19 17:57:13 Wardialer-X5SA DuetControlServer[324]:    at DuetControlServer.Program.Main(String[] args) in /home/christian/duet
Apr 19 17:57:13 Wardialer-X5SA systemd[1]: duetcontrolserver.service: Succeeded.
Apr 19 17:57:18 Wardialer-X5SA systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 19 17:57:18 Wardialer-X5SA systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 1.
Apr 19 17:57:18 Wardialer-X5SA systemd[1]: Stopped Duet Control Server.
Apr 19 17:57:18 Wardialer-X5SA systemd[1]: Started Duet Control Server.
Apr 19 17:57:19 Wardialer-X5SA DuetControlServer[851]: Duet Control Server v1.2.4.0
Apr 19 17:57:19 Wardialer-X5SA DuetControlServer[851]: Written by Christian Hammacher for Duet3D
Apr 19 17:57:19 Wardialer-X5SA DuetControlServer[851]: Licensed under the terms of the GNU Public License Version 3
Apr 19 17:57:20 Wardialer-X5SA DuetControlServer[851]: [info] Settings loaded
Apr 19 17:57:20 Wardialer-X5SA DuetControlServer[851]: [info] Environment initialized
Apr 19 17:57:20 Wardialer-X5SA DuetControlServer[851]: [error] Failed to connect to Duet
Apr 19 17:57:20 Wardialer-X5SA DuetControlServer[851]:    System.Exception: Invalid protocol version 2
Apr 19 17:57:20 Wardialer-X5SA DuetControlServer[851]:    at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christia
Apr 19 17:57:20 Wardialer-X5SA DuetControlServer[851]:    at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean mustSu
Apr 19 17:57:20 Wardialer-X5SA DuetControlServer[851]:    at DuetControlServer.Program.Main(String[] args) in /home/christian/duet
Apr 19 17:57:20 Wardialer-X5SA systemd[1]: duetcontrolserver.service: Succeeded.
Apr 19 17:57:26 Wardialer-X5SA systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 19 17:57:26 Wardialer-X5SA systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 2.
Apr 19 17:57:26 Wardialer-X5SA systemd[1]: Stopped Duet Control Server.
 

[ChrisP]

As per the release notes, you also need to update DSF/DCS to a compatible version if you're going to update the Duet's firmware.
Assuming you're using the unstable branch, just do sudo apt update followed by sudo apt upgrade.
This will ensure that everything is upgraded together so you shouldn't land yourself with the problem you have.

[Hernicz]

@ChrisP I think it will be something else.

wardialer@Wardialer-X5SA:~ $ cd /etc/apt/sources.list.d
wardialer@Wardialer-X5SA:/etc/apt/sources.list.d $ ls
duet3d.list  raspi.list
wardialer@Wardialer-X5SA:/etc/apt/sources.list.d $ sudo apt-get update
[sudo] password for wardialer: 
Hit:1 http://raspbian.raspberrypi.org/raspbian buster InRelease                                                   
Hit:2 http://archive.raspberrypi.org/debian buster InRelease                                                      
Ign:3 https://pkg.duet3d.com stable InRelease          
Get:4 https://pkg.duet3d.com stable Release [2,286 B]
Get:5 https://pkg.duet3d.com stable Release.gpg [228 B]
Fetched 2,514 B in 43s (58 B/s)                                                                                                       
Reading package lists... Done
wardialer@Wardialer-X5SA:/etc/apt/sources.list.d $ sudo apt-get install duetsoftwareframework
Reading package lists... Done
Building dependency tree       
Reading state information... Done
duetsoftwareframework is already the newest version (1.2.4.0).
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
wardialer@Wardialer-X5SA:/etc/apt/sources.list.d $ 
 

Right now I'm using Raspbian with manual install (unstable skipped), but I've tried DuetPi + RC6 with same results. RC5 works well on Raspbian, haven't tried DuetPi

As a sidenote: Please rename DuetPi to DuetOS or whatever. Cannot google it, I get results about DietPi...

[ChrisP]

No, it's not something else, it because you need to be on the unstable list to be able to what you're trying. Your options are to revert your firmware back or switch to unstable.
Tbh, your DCS version is not even recommended for RC5 you have 1.2.4.0 and 1.2.5.0 is recommended.

[Hernicz]

@ChrisP Added unstable to the list update/upgraded an installed RC8.
Now if I edit config.g save and reset then machine name reverts back to My Duet and heaters disappear from Dashboard graph.
The only way to get these displayed properly after config edit is by unplug the whole thing and restrart.

[ChrisP]

@Hernicz
That's pretty interesting. I haven't update my config.g since I' update to RC8, however, at least a few of us have experienced the issue you describe since updating to RC8. We get it when the emergency stop is pressed (for eg.), but the reset after config update would likely do the same. I suggest, you add a comment on this thread, so that other methods or re-creating the issue are recorded.

[Hernicz]

@ChrisP Done