RepRapFirmware 3.0

dc42

@alexander-mundy said in RepRapFirmware 3.0:

I'm at the stage of commissioning a new Delta with a new Duet 2 wifi board (don't have the towers installed yet but the base is done) and figured I might as well start a clean slate with 3.0. I installed the beta firmware and updated to the latest wifi server and web interface. I have printed out the wiki overview but if someone has a working delta config.g that they would share for me to look at while I try to config this new printer to 3.0 it would help.

I didn't have to make any config changes to run RRF3 on my delta. The same is likely to be true for you unless you use a Z probe whose output is connected to an endstop switch instead of to the Z probe IN pin.

dc42

@gtj0 said in RepRapFirmware 3.0:

But the 3 Z motors aren't actually activated to effect the changes needed.
Running v3-dev branch as of today.

Thanks, I'll check this out.

mudcruzr

Pulling my hair out here. Has anyone running RRF3 on a Maestro with a BLTouch got it working OK?

A Former User

Only briefly tested deploy and retract of the probe, but that worked. Need to sort dual z motors out before I can try actual probing

4:59:46 PM	Disconnected.            <- estop
4:59:14 PM	G30 
4:57:36 PM	M558 P9 C"zprobe.in" H5 F120 T3000
4:52:11 PM	M280 P0 S10
4:51:17 PM	M280 P0 S90
4:50:13 PM	M950 S0 C"zprobe.mod"

mudcruzr

@bearer said in RepRapFirmware 3.0:

Only briefly tested deploy and retract of the probe, but that worked. Need to sort dual z motors out before I can try actual probing
4:59:46 PM	Disconnected.            <- estop
4:59:14 PM	G30 
4:57:36 PM	M558 P9 C"zprobe.in" H5 F120 T3000
4:52:11 PM	M280 P0 S10
4:51:17 PM	M280 P0 S90
4:50:13 PM	M950 S0 C"zprobe.mod"

Thanks for that, it confirmed that I was on the right track. I have it working now.
I had the M950 line in my config.g, assuming it was global, but it doesn't seem to be. I had to put it in my deployprobe.g and retractprobe.g files ahead of the M280 lines to make it work.
However, my printer is now homing and doing a G32 no problem!
Next I'll try the heaters and then maybe even a print!

P.S. @bearer - I didn't have to change anything for my dual Z motors to work

Edit: Aaand.... she is printing!! Woot! Now for the 12864 menus.

A Former User

@mudcruzr said in RepRapFirmware 3.0:

P.S. @bearer - I didn't have to change anything for my dual Z motors to work

I didn't say it worked in 2.03

Anyways pretty sure you should only need the commands once in config.g. Maybe its a ordering of things thing, I haven't studied the changes in too much detail, but when putting it at the way bottom of config.g it seems to work.

mudcruzr

@bearer said in RepRapFirmware 3.0:

I didn't say it worked in 2.03

Lol!

I tried the M950 command as the very last line in my config.g and it didn't work, I also can't see anything in config-override.g that would change it. So I think it's a question for @dc42

@dc42 David, where must the M950 command reside? I have it as the very last command in my config.g but in order to use my bltouch probe I must also put it in the deployprobe.g file immediately before the M280 for it to work.

After the deployprobe.g file has run once, I don't need to put M950 anywhere else, everything just works. Are there any rules about where it must be either before or after certain other commands?

dc42

@mudcruzr said in RepRapFirmware 3.0:

I tried the M950 command as the very last line in my config.g and it didn't work, I also can't see anything in config-override.g that would change it. So I think it's a question for @dc42

@dc42 David, where must the M950 command reside? I have it as the very last command in my config.g but in order to use my bltouch probe I must also put it in the deployprobe.g file immediately before the M280 for it to work.

After the deployprobe.g file has run once, I don't need to put M950 anywhere else, everything just works. Are there any rules about where it must be either before or after certain other commands?

Putting the M950 command at the end of config.g should work. The rules are:

At the point where you run M950, the pin you are assigning must be free. So you must cancel any default or previous assignment before the M950 command.
The M950 command must be executed before the command that uses the mapping it sets up - so in your case, before the first M280 command is executed.

It may help to run M98 P"config.g" so that you can see any errors that are thrown when config.g executes.

mudcruzr

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.

PaulHew

@mudcruzr Would you care to share your config.g please. I have been looking to upgrade to RRF3 but need a template to work from!
TIA Paul.

mudcruzr

@paulhew said in RepRapFirmware 3.0:

@mudcruzr Would you care to share your config.g please. I have been looking to upgrade to RRF3 but need a template to work from!
TIA Paul.

Sure, here you go:
0_1557820856402_config.g

Edit: I should mention that I have 2 separately controlled Y motors and 2 separately controlled Z motors.

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.