RepRapFirmware 3.0

mudcruzr · 14 May 2019, 10:15

Should you not be able to use M401 instead of M280 to keep the menu files the same? I thought M401 called M98 P"deployprobe.g" which then can ve version specific?

I guess I could, but I expect RRF2 and RRF3 to diverge more and more as RRF3 develops and trying to include new RRF3 functionality while maintaining backwards compatibility with RRF2 seems a bit like making a rod for my own back. I fully expect the whole lot to be rewritten & redesigned more than once.

dc42 · 14 May 2019, 11:41

@mudcruzr said in RepRapFirmware 3.0:

No errors from config.g but I now have the probe working. I hadn't put the C"zprobe.in" in the M558 line because the probe was working without it (as long as the M950 was still in deployprobe.g). As soon as I added the C"zprobe.in" everything started working as it should. The M558 line is now:

M558 P9 C"zprobe.in" H5 F300 T4000 A10 S0.003 R0.5 B1

And M950 S0 C"zprobe.mod" is the last line in my config.g and nowhere else.

Thanks guys.

I can see why. The default pin configuration for M558 is "zprobe.in+zprobe.mod". For your M950 command to work, the zprobe.mod pin must be free. So you need to redefine the Z probe pins as just "zprobe.in" in M558, to free up the "zprobe.mod" pin.

dc42 · 14 May 2019, 11:45

@bearer said in RepRapFirmware 3.0:

Should you not be able to use M401 instead of M280 to keep the menu files the same? I thought M401 called M98 P"deployprobe.g" which then can ve version specific?

M401 does a little more than that, it also records the Z probe as being deployed. This means that when you come to do a G30, the firmware knows that the probe is deployed, so it doesn't do an automatic deploy/retract around the G30 command. This can be used to deploy the probe just once at the start of bed.g and retract the proibe just once at the end. [This doesn't work for BLTouch, which needs to be deployed/retracted at every probe point.]

So M401 should always be used in preference to M98 Pdeployprobe.g, and similarly M402 instead of M98 Pretractprobe.g.

gtj0 · 15 May 2019, 19:27

@dc42 just did a git pull to get your latest v3-dev changes and just fyi... auto bed levelling is still non-automatic. Calculations are done but no movement.

If you don't have time to look at it right now, that's cool. I can take a look this weekend.

dc42 · 16 May 2019, 15:51

@gtj0 said in RepRapFirmware 3.0:

@dc42 just did a git pull to get your latest v3-dev changes and just fyi... auto bed levelling is still non-automatic. Calculations are done but no movement.

If you don't have time to look at it right now, that's cool. I can take a look this weekend.

Does it work properly on your printer using 2.03RC2 ?

gtj0 · 16 May 2019, 16:49

@dc42 said in RepRapFirmware 3.0:

@gtj0 said in RepRapFirmware 3.0:

@dc42 just did a git pull to get your latest v3-dev changes and just fyi... auto bed levelling is still non-automatic. Calculations are done but no movement.

If you don't have time to look at it right now, that's cool. I can take a look this weekend.

Does it work properly on your printer using 2.03RC2 ?

I just double checked and yes it works on 2.03RC2. It does the 3 probes, calculates the offsets, then adjusts the motors to compensate.

dc42 · 16 May 2019, 17:46

@gtj0, thanks for confirming this. I will invesgigate the issue RRF3.

dc42 · 16 May 2019, 18:50

I think I have found the reason for leadscrew moves not working. I have pushed some updates to the RRF 3 source. Please note, I have also made some changes to the M558 command.

gtj0 · 16 May 2019, 23:29

@dc42 said in RepRapFirmware 3.0:

I think I have found the reason for leadscrew moves not working. I have pushed some updates to the RRF 3 source. Please note, I have also made some changes to the M558 command.

Working now, thanks!

mudcruzr · 17 May 2019, 09:51

Is there any chance of a new build with these changes in (for those of us without the wherewithall to compile) please?

dc42 · 17 May 2019, 09:58

@mudcruzr said in RepRapFirmware 3.0:

Is there any chance of a new build with these changes in (for those of us without the wherewithall to compile) please?

New binaries here https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0 and here https://www.dropbox.com/s/m0r3ldy424mxf4v/DuetMaestroFirmware.bin?dl=0.

mudcruzr · 17 May 2019, 09:59

@dc42 Many thanks David

oliof · 19 May 2019, 11:29

That last build does not move the extruder for me on a CR-20. I checked by moving the extruder motor to X and was able to move it. Downgrading to 2.03RC2 (what I ran previously) fixed the extruder.

I am pretty sure that nothing in my config.g needs changing, but maybe I overlooked something in the wiki. See attached file.

0_1558265361187_config.g

Dougal1957 · 19 May 2019, 14:27

@oliof you did have the nozzle heated didn't you?

oliof · 19 May 2019, 15:32

Yes, this was with a heated nozzle -- DWC showed extruder moves in the UI, but the motor was not moving and there was no error regarding attempting to extrude with a cold nozzle. And even enabling cool extrusion (with filament removed) with M302 P1 did not allow the extruder motor to move.

Dougal1957 · 19 May 2019, 17:49

@oliof just checking as it is a common mistake but not valid in this case

oliof · 19 May 2019, 18:32

@dougal1957 it's absolutely fair to ask (-:

dc42 · 19 May 2019, 18:49

Was the extruder motor connected directly to an output on the Duet?

oliof · 19 May 2019, 19:00

Yes, to output "E0" on the duet wifi board.

4lathe · 20 May 2019, 03:26

Sane for me. Just loaded latest 3.0 and modified my m558 as I use fsr’s on endstop e0. Motion control all fine as is bed and nozzle heat bur the extruder E0 will not extrude or retract. Its at temperature.