RepRapFirmware 3.01-RC6 released

dc42

@SpoonUnit said in RepRapFirmware 3.01-RC6 released:

;RRF 3.01 RC6
M950 J1 C"duex.e2stop" ; Define Input J1 for pin duex.e2stop
M581 P1 T2 C0 S1 ; Connect Input J1 (P1) to trigger 2 (T2) always (C0) for inactive to active (S1 - also default)

One source of confusion was that M950 J1 alone reports this, regardless of whether the button is pressed or not:
M950 J1
Pin duex.e2stop, active: true

As you have not inverted the input, it should report 'active: true' when the input is high and false when it is low (i.e. shorted to ground).

Where in the object model will J1 sit once defined? It doesn't seem to be in inputs or sensors.

It should already be in sensors.inputs[1].

Also spotted on the M950 example:
M950 J1 C"!^e3stop" ; Input 1 uses e0Stop pin, inverted, pullup enabled
Should this not read that Input 1 uses e3stop, instead of e0stop?

Thanks, I've corrected the example.

dc42

I've just tested exactly that configuration: M950 J1 C"duex.e2stop". M950 J1 always reports "active: false" which is incorrect. I will fix this in RC7. M409 K"sensors.inputs" reports it correctly.

SpoonUnit

@dc42 Strange I get active:true, regardless of whether the button is pressed or not, whereas you get false. Good to know what you intended for it.

echo sensors.inputs[1].value

Reports true, where I expect it to report false. Regardless, the button is performing its intended function now.

dc42

Is the button NO or NC? What's happening is that the button state is being read when the port is created, but then M950 J1 is reporting that initial state, not the current state. I am testing with a NC button, so it's active when the button is pressed. With a NO button it would be active when the button is not pressed, unless you invert the pin.

SpoonUnit

I honestly don't know what N0 or NC is. However, I've just had a moment to test and I can see the sensors.inputs[1].value does flip when the button is pressed. I guess my button (just an arcade button) is NO (default:open ?).

deckingman

@SpoonUnit NO - Normally Open, NC = Normally Closed. HTH

garyd9

@dc42

Something seems to have broken my delta auto-calibration script (bed.g) between RC3 and RC6 related to the 'iterations' variable on my duet3 running in stand-alone. (I don't see anything in WHATS_NEW related to that variable.) Each time I run G32, it does the initial probe, and then immediately breaks the loop assuming iterations is = 5. For a complete context:

My bed.g contains (comments removed):

M561 ; clear any bed transform
G28 ; always home before calibration

M98 P"/sys/Calib-Probe-Points.g"

while true
	if iterations = 5
		abort "Too many auto-calibration attempts"
	if {abs(move.calibration.final.deviation - move.calibration.initial.deviation)} < 0.005
		break;
	echo "Repeating calibration to merge deviations"
	M98 P"/sys/Calib-Probe-Points.g"
echo "Auto calibration successful"
G1 X0 Y0 Z150 F8000			; get the head out of the way of the bed

... and Calib-Probe-Points.g contains:

G30 P0 X0.00 Y130.00 Z-99999 H0
; .. G30 P1 thru G30 P17 
G30 P18 X0 Y0 Z-99999 S8

Running G32 results in a single run of Calib-Probe-Points.g and then the script aborts. (It also aborts if the deviation is too great and it should try again.)

Calibrated 8 factors using 19 points, (mean, deviation) before (-0.008, 0.028) after (0.000, 0.027)
Too many auto-calibration attempts

I doubt I'm the only person using a script like this for calibrating, and I don't see anyone else complaining, so I'm assuming (hoping) that I missed something in one of the 3.0.1 RCx changes (or discussions.) If so, please point me in the correct direction (and perhaps add something to the 'update notes' in WHATS_NEW.)

EDIT (with solution at the end):

I've narrowed this down and it doesn't seem to have anything to do with the 'iterations' variable at all, but instead with the loop processing. Again, this used to work fine with RC3... Rather than describe every change, here's an updated bed.g:

;M98 P"/sys/Calib-Probe-Points.g"

; start looping...
while true
	echo iterations
	if iterations = 5
		G1 X0 Y0 Z150 F8000
		abort "Too many auto-calibration attempts"

; dummy comment
; dummy comment

	if {abs(move.calibration.final.deviation - move.calibration.initial.deviation)} < 0.005
		break;

	echo "Repeating calibration to merge deviations"
	M98 P"/sys/Calib-Probe-Points.g"
echo "Auto calibration successful"

The key changes are that I added something to display the value of 'iterations' each iteration, and I have some dummy comments in there (that used to contain different variations of testing the deviation.) When I run G32 with those changes in place, I see the following in the console:

0
1
2
3
4
5
Too many auto-calibration attempts

Notice how it's iterating the loop, but not displaying the 'repeating calibration' message? That gave me the clue I needed... If I remove the two dummy comments, everything works as expected.

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.

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:
G31 S-3 Meldung.jpg
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.