@bugsysiegals I can't see why not, but I'm on holiday now until July, but (if I remember) I'll look at it when I get back. If you don't hear from me by say the 5th or 6th of July, I've forgotten - send me a reminder, lol.

@mudcruzr said in duetbackup - CLI tool to backup your Duet SD Card:

@wilriker said in duetbackup - CLI tool to backup your Duet SD Card:

Release 1.1.0

I just released v1.1.0 and I think this will make @mudcruzr quite happy - as well as I hope that other users will also be happy with the new feature. Release notes below.

LOL

Happy? Happy? I'm absolutely ecstatic mate! Seriously, many thanks for a very useful tool.

Ah! not so happy now even with the exclude flag it's still including all the gcode files.

Command line:

./duetbackup -domain "192.168.0.52" -outDir "Feynman" -dirToBackup "0:/" -exclude "0:/gcodes"

(Sorry!)

@wilriker said in duetbackup - CLI tool to backup your Duet SD Card:

Release 1.1.0

I just released v1.1.0 and I think this will make @mudcruzr quite happy - as well as I hope that other users will also be happy with the new feature. Release notes below.

LOL

Happy? Happy? I'm absolutely ecstatic mate! Seriously, many thanks for a very useful tool.

Maybe I'm missing something here but why not simply plug the printer in via the smartplug and use your smartphone or even better Alexa to turn the printer on & off. That's what I do, before I go to my workshop I say "Alexa, turn on workshop" and everything that's plugged in via a smartplug switches on. Of course I can control each smartplug individually too.
Another advantage is that I can leave the workshop with the printers finished printing but with the hotend fan still running while the printers cool down and turn everything off later. Previously I'd wait, twiddling my thumbs, until the hotend had cooled down before switching off for the night.

@wilriker said in duetbackup - CLI tool to backup your Duet SD Card:

Release 1.0.2

I just released version v1.0.2.

• This release should fix the time zone issue @mudcruzr described.
• Also starting from this release the (callable) filename for all target platforms now is duetbackup - for this the files are package as either tar.gz or zip depending on target

Works for me, many thanks! (Windows 10)

I have a suggestion (only semi-seriously), if it's not too cheeky: an exclude switch, e.g.

./duetbackup -dirToBackup "0:/" -excludeDir "0:/gcodes" -domain "192.168.0.53" -outDir "./bkup"

(I didn't realise how many files I had accumulated in my gcodes directory, lol)

Under windows 10 I run:

.\duetbackup.exe -domain "192.168.0.53" -outDir ".\bkup"

(Tried it with & without the quotes and using ./bkup and .\bkup all with same error.)

and it errors with the following:
2019/06/01 20:15:32 Fetching filelist for 0:/sys
panic: time: missing Location in call to Time.In

The whole error message is here 0_1559416600853_Duetbackup_errors.txt

@dc42 Many thanks David

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

That'd work.

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

@deckingman said in Suggestion for change to implementation of baby-steps:

@danal said in Suggestion for change to implementation of baby-steps:

I view it as an "operator override" for that one job, that should not persist.

+1 for this from me too.

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

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

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.

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

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

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

I wouldn't have an issue with that but I guess it'd be up to @dc42

I've updated a couple of the 12864 menu files to cope with the changes in 2.03RC1

As usual they are in https://github.com/mudcruzr/Duet-Maestro-12864-Menu-Files

2 Files required updates to cope with the changes in 2.03RC1

The new files are main_for_203RC1 and heat_for_203RC1

Upload the 2 new files, rename the existing heat and main to something like heat_backup and main_backup then rename the 2 new files to heat and main respectively.

Note these files are ONLY for using with 2.03RC1

I've updated a couple of the 12864 menu files to cope with the changes in 2.03RC1

As usual they are in https://github.com/mudcruzr/Duet-Maestro-12864-Menu-Files

2 Files required updates to cope with the changes in 2.03RC1

The new files are main_for_203RC1 and heat_for_203RC1

Upload the 2 new files, rename the existing heat and main to something like heat_backup and main_backup then rename the 2 new files to heat and main respectively.

Note these files are ONLY for using with 2.03RC1