RepRapFirmware 3.0
-
@bearer said in RepRapFirmware 3.0:
On that note, would it be worth while having M208 without parameters show the current values? Probably most usefull for testing as opposed to opening the config-overide.g file.
It already does!
The general rule with RepRapFirmware is that a command without parameters, or with just the parameter to select which of several instances you want, reports existing values.
Examples of commands that report values when no parameters are provided:
M201 M203 M204 M207 M208 M302 M564 M572 M574 M584 M906 M913 M915
Examples of commands that report existing values when just the instance selection parameter (e.g. tool number, drive number, heater number) is provided:
M305 M307 M569 M591
-
Odd, I was sure I tried that as you say it seems to be the norm. It does it now for both 3.0beta and 2.02.
-
It only shows the output from M208 if you run it from the G-code console. The quick g-code thing at the top will run the command, but the output gets truncated in the log, even when the console is otherwise showing.
-
@bearer Which version of DWC are you running I think there was a few issues like this with the early V2 releases
-
@dougal1957
Duet Web Control 1.22.6 (as distributed with Duet2Firmware-2.02 release) -
I'm sorry, I can't reproduce that. The GCode Console shows the reply whichever box I enter it in. I tested with DWC 1.22.6 and with 2.0.0RC6.
-
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.
-
@dc42 Bed levelling via
G32 S3
doesn't seem to be working.bed.g:
M561 G29 S2 G1 F600 G30 P0 X0 Y3 Z-99999 ; probe near a leadscrew G30 P1 X227 Y455 Z-99999 ; probe near a leadscrew G30 P2 X455 Y3 Z-99999 S3 ; probe near a leadscrew and calibrate 3 motors G1 F2400 M98 Phomexy.g
When run, the 3 points are probed and the results displayed...
Leadscrew adjustments made: 0.086 -1.598 -0.980, points used 3, deviation before 1.027 after 0.000
But the 3 Z motors aren't actually activated to effect the changes needed.
Running v3-dev branch as of today.
-
@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.
-
@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.
-
Pulling my hair out here. Has anyone running RRF3 on a Maestro with a BLTouch got it working OK?
-
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"
-
@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.
-
@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.
-
@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?
-
@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.
-
-
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.
-
@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. -
@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.gEdit: I should mention that I have 2 separately controlled Y motors and 2 separately controlled Z motors.
-
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