RepRapFirmware 3.01-RC6 released

gruen

I'm waiting for RC7.

dc42

@gruen said in RepRapFirmware 3.01-RC6 released:

I'm waiting for RC7.

There are no plans for a RRF 3.01-RC7 release, because there are no known bugs in 3.01-RC6 known yet other than the limitations described in the whatsnew-rrf3 file.

tobias_munich

RC6 works for me in standalone mode and is stable.
SBC mode is still unstable.
think the reason is still the current version of the duet framework.

jmjcoke

I have tried, sudo service duetcontrolserver restart and I still have Drive is unmounted. Any help on how I can goto RC5 from here, I cannot seem to get duetframework to anything but 1.3.1.

tobias_munich

@jmjcoke the problem is not RC6, it’s the Duetframework.
if you run RC6 in stand-alone mode you shoudnt have issues.

SpoonUnit

Successfully setup and printed with RC6. Only issue is that my kill switch isn't working. It's setup with this, to invoke trigger2.g:

M581 P"duex.e2stop" S1 T2 C0

Trigger 2 is working if I invoke with M98, and M999 (the only command in the trigger) also does it's job. I've tried all 4 permutations of the command that seem to make sense:

M581 P"duex.e2stop" S1 T2 C0
M581 P"duex.e2stop" S0 T2 C0
M581 P"!duex.e2stop" S1 T2 C0
M581 P"!duex.e2stop" S0 T2 C0

None of them result in activation of the trigger when the button is pressed.

The command executes fine from the console, and worked as intended with RC1. I can't see any reference in the notes for each release between RC1 and RC6 for this, but could have missed something.

Is there a way to simply report on the state of a given pin?

This output doesn't give me confidence it's been made available, but I never needed to investigate to this depth previously, so I'm not sure what the output in RC1 was:

M409 K"sensors.endstops" F"v"

{"key":"sensors.endstops","flags":"v","result":[{"triggered":false,"type":"inputPin"},{"triggered":false,"type":"inputPin"},null,{"triggered":false,"type":"motorStallAny"}]}

I'm not sure where else in the object model to look. Could this be it?

M409 K"inputs[5]" F"v"

{"key":"inputs[5]","flags":"v","result":{"axesRelative":false,"compatibility":"RepRapFirmware","distanceUnit":"mm","drivesRelative":false,"feedRate":50.0,"inMacro":false,"lineNumber":0,"name":"Trigger","stackDepth":0,"state":"idle","volumetric":false}}

If so, I don't see any key there for the value.

Any help appreciated.

deckingman

@SpoonUnit Something did change with M581. I'm on a phone right now so not easy for me to say exactly what. IIRC you need to add an M950 with a (I think) J parameter.

dc42

@SpoonUnit, read the upgrade notes for 3.01-RC2, or https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M581_RepRapFirmware_3_01RC2_and_later.

SpoonUnit

Thanks.

This was the end result of the conversion, which now works.

; buttons
;RRF 3.01 RC1
;M581 P"duex.e2stop" S1 T2 C0

;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

I guess this is reporting that the pin is active in the model, and not that the pin state is open. Where in the object model will J1 sit once defined? It doesn't seem to be in inputs or sensors.

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?

chrishamm

@ChrisP Thanks for reporting this, I'll try to reproduce and fix it.

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.