RepRapFirmware 3.0

mudcruzr

I've modified my Maestro 12864 menu files to work with RRF3b1, but to avoid confusion I've created a separate new repository on Github for them. There are no changes to functionality yet, they do the same as before but work with RRF3.

Here they are: https://github.com/mudcruzr/Duet-Maestro-12864-Menu-Files-for-RRF3b1/releases/tag/v0.1.RRF3b1

A Former User

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?

PaulHew

@mudcruzr Thank you, greatly appreciated.
Yes I saw the Y and Z's in the code and did wonder!

Time to back everything up and try it!
Thanks again.
Paul

mudcruzr

@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?

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

@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

@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

@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

@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

@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

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

dc42

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

@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

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

dc42

@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

@dc42 Many thanks David

oliof

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

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

oliof

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

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

oliof

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