RepRapFirmware 3.0

A Former User

Maybe a page on the wiki with machine descriptions and associated config.g?

"Templates" for use with the online firmware configurator is already possible by means of the config.json file that can be loaded and changed as needed (as long as the configurator support making the neccecary changes or they can fit in the custom g-codes section at the end).

dc42

I have put a new RepRapFirmware 3 binary for Duet 2 at https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0. This restores support for M577, M581 and M582. See https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview for details of changes to those commands.

The only RRF 2 feature not yet supported in RRF 3 is now the ability to use stall detection to terminate an extruder move.

smoki3

Today I switched to the 3.0.

@dc42 So I got everything to work besides the Z-Probe.

I use a normal mircoswitch connected to zstop pin on the duet2wifi.

But it tells me that it it always triggered.

I used this according to the documentation:

M574 Z0 C"nil" 				       ; no Z endstop switch, free up Z endstop input
M558 P5 C"zstop" H3 F180 T25000 I1 	       ; Z probe connected to Z endstop input

I also tried to remove the inversion "I1" and put an "!zstop" in the C command. But it doesnt help.

In DWC I see the probe value changes from 0 to 1000 if I press the switch. But the background of the value is always read

I played alot now with all the parameters. Looks like the probe is always trigged no matter which pin is selected. But I can not test an older build because the files in dropbox is replaced.

Here are some console outputs:

M119
Endstops - X: not stopped, Y: not stopped, Z: not stopped, Z probe: at min stop

M574
Endstop configuration: X: low end motor stall (any motor), Y: low end motor stall (any motor), Z: none

M558
Z Probe 0: type 5, input pin zstop, output pin nil, invert yes, dive height 3.0mm, probe speed 180mm/min, travel speed 25000mm/min, recovery time 0.00 sec, heaters normal, max taps 1, max diff 0.03

dc42

@smoki3 said in RepRapFirmware 3.0:

I use a normal mircoswitch connected to zstop pin on the duet2wifi.
But it tells me that it it always triggered.

What does - the M119 report, or something else? Are you saying that DWC shows the correct Z probe status, but M119 does not?

smoki3

for the outputs see my post above.

M119 shows always " Z probe: at min stop "

In the status windows i can see that the Z-probe value switches between 0 and 1000. But its always in read color

dc42

I found the problem. The threshold is not being initialised. A workaround is to put command G31 P500 (or whatever threshold you want to use) after the M558 command.

smoki3

@dc42 said in RepRapFirmware 3.0:

G31 P500

Thanks this works fine

jay_s_uk

@dc42 I've also upgraded to RRF 3.0 to try it out.
Previously, in RRF 2, when setting up a Z Probe, I used to have M558 H4. This H4 was added to the z probe offset so it would look for the bed, in my case, 31.66mm above z, as my probe offset is 27.66.
Now I'm having to use H30 as RRF 3 seems to be ignoring the z probe offset. Is this correct?

dc42

@jay_s_uk said in RepRapFirmware 3.0:

@dc42 I've also upgraded to RRF 3.0 to try it out.
Previously, in RRF 2, when setting up a Z Probe, I used to have M558 H4. This H4 was added to the z probe offset so it would look for the bed, in my case, 31.66mm above z, as my probe offset is 27.66.
Now I'm having to use H30 as RRF 3 seems to be ignoring the z probe offset. Is this correct?

No, that's not correct. RRF 3 should not ignore the Z probe offset, and I am fairly sure it doesn't on my printers.

The default M558 H value is 5. It's normally only necessary to increase it when aut-calibrating a delta printer for the first time, when the homed height and delta radius enters in the M665 command are likely to be inaccurate.

How come your Z probe trigger height (which is what I presume you mean by "offset") is as high as 31mm?

jay_s_uk

@dc42
I have a linear plus with an E3D hot end. So I use the probe that came with is as well as little block to allow me to miss the heat block on the hot end. This has increased the z probe offset somewhat from 16.8ish that comes as standard to 27.6ish.
Its works fine with RRF 2 without issue.
But switching over to RRF 3, the z probe was coming into contact with the bed way before it was actually triggering.
I increased the H from 4 to 30 and this allowed me to run G32 and the M500. But I've had to leave H as 30 otherwise the z probe comes into contact with the bed. And the gap it maintains between the probe and the bed is only around 3mm, hence why I think it is ignoring the z probe offset.

dc42

You are right, it's not adding the trigger height to the dive height. I will fix this in the next build. Thanks for reporting it.

jay_s_uk

At least I'm not going mad. Thanks

dc42

@jay_s_uk, please try the new binary at https://www.dropbox.com/s/zfv4p7dr2ycmjzd/Duet2CombinedFirmware.bin?dl=0.

jay_s_uk

@dc42 thats spot on

dc42

@jay_s_uk said in RepRapFirmware 3.0:

@dc42 thats spot on

Thanks for confirming!

wilriker

I also now tried out RRF3 and first very obvious observation: Fan PWM inversion does not work. I do have

; Fans
M950 F0 P"fan0" Q10                               ; Fan 0 has a low PWM frequency of only 10Hz
M950 F1 P"!fan1" Q25000                           ; Fan 1 has a high PWM frequency of 25kHz and is inverted
M950 F2 P"!fan2" Q25000                           ; Fan 2 has a high PWM frequency of 25kHz and is inverted
[...]
M106 P0 S0 H-1 C"Part Cooling Fan"                 ; Set fan 0 value. Thermostatic control is turned off
M106 P1 S1 L0.7 H1 T45:220 C"Hotend Fan"           ; Set fan 1 value. Thermostatic control is turned on
M106 P2 S0 H-1 C"Hardware Fan"                     ; Set fan 2 value. Thermostatic control is turned off

where the first fan is a regular 3-wire fan but the other two are 4-wire PWM controlled fans and both spin at 100% speed after startup (I know fan 1 is thermostatic but the hotend is at room temp). Unless I make fan 1 non-thermostatic I have no way of stopping it (I stopped fan 2 by issuing M106 P2 S1).

EDIT: Second observation:
I have two independent Z steppers. Also each stepper has a separate endstop switch. Homing Z works fine with both steppers running until their appropriate switch is triggered. After that I un-hide W axis (right of the two Z steppers) and apply a correction since the switches are not perfectly aligned. So far this works. What does not work is M119 for W axis. It will always show that the endstop is not triggered even though at the same time it shows triggered for Z.


M584 X0 Y1 Z2:3 W3 E4                              ; Assign one driver X, Y and E and two to Z
[...]
M574 Z1 S1 P"zstop+e0stop"                         ; Set active high endstop at low end on Z with two separate endstops
M574 W1 S1 P"e0stop"                               ; Set active high endstop at low end on W

Since I never use W axis outside of homez.g and don't even have a homew.g for me this is purely cosmetical - but their are probably other users that depend on this working correctly.

dc42

@wilriker said in RepRapFirmware 3.0:

I also now tried out RRF3 and first very obvious observation: Fan PWM inversion does not work. I do have
; Fans
M950 F0 P"fan0" Q10 ; Fan 0 has a low PWM frequency of only 10Hz
M950 F1 P"!fan1" Q25000 ; Fan 1 has a high PWM frequency of 25kHz and is inverted
M950 F2 P"!fan2" Q25000 ; Fan 2 has a high PWM frequency of 25kHz and is inverted
[...]
M106 P0 S0 H-1 C"Part Cooling Fan" ; Set fan 0 value. Thermostatic control is turned off
M106 P1 S1 L0.7 H1 T45:220 C"Hotend Fan" ; Set fan 1 value. Thermostatic control is turned on
M106 P2 S0 H-1 C"Hardware Fan" ; Set fan 2 value. Thermostatic control is turned off

The pin name parameter in the M950 command (and most other commands that don't take axis parameters) is C not P.

What does not work is M119 for W axis. It will always show that the endstop is not triggered even though at the same time it shows triggered for Z.

You can't currently assign the same endstop input to more than one axis. So the M574 command to assign e0stop to W is failing. If you run that command from the console you will get an error message.

wilriker

@dc42 said in RepRapFirmware 3.0:

The pin name parameter in the M950 command (and most other commands that don't take axis parameters) is C not P.

In that case the example code for M106 in the RRF3 wiki is wrong (I checked M950 has it right).

You can't currently assign the same endstop input to more than one axis. So the M574 command to assign e0stop to W is failing. If you run that command from the console you will get an error message.

As I said no real problem for me but thanks for clarifying.

dc42

I have corrected the example.

wilriker

@dc42 Thanks. Just wanted to do it myself only to find it's been done already.