I have already mentioned it in the duetbackup thread that I am working on a largely extended version of it and here it is. I call it

rfm - RepRapFirmware FileManager

It can be used to perform all file and directory actions available via RepRapFirmware's HTTP interface.

Usage

$ ./rfm help
rfm provides a command-line interface to perform file actions
against the HTTP interface of a device running RepRapFirmware.

Usage:
        rfm <command> [arguments]

Each command will at least expect the argument -domain which
specifies where on the network the device is located. This can
either be a resolvable hostname or an IPv4 address.

The commands are:
        backup     Backup a given directory on the device
        upload     Upload local files/directories to the device
        mkdir      Create a new directory on the device
        mv         Rename/move a file/directory on the device
        rm         Remove a file/directory on the device
        download   Download a single file from the device
        fileinfo   Get information on a file
        ls         Show the file tree of a given path

Use "rfm <command> -help" for more information about a command's
arguments.

Notes

• With the release of this tool duetbackup will be deprecated and discontinued
• Watch this thread for announcements of new releases
• Give any feedback here - whether bugs you found or possible changes

Source

As usual this is open source and (as usual for me) it is implemented in Go. Sources as well as releases can be found at GitHub and the Releases page respectively.

As part of the thread Extruder Linearity a calculator has been developed to calculate the optimal/minimum extruder microstep setting. The original spreadsheet has been converted into an online version and can be found at

microstep-calculator

If you find any issues or have ideas for improvements please reply in this thread (preferred) or open an issue at the corresponding GitHub issues page.

I am please to annound the release of PanelDueFirmware 3.2-RC1.

Pre-Release 3.2-RC1

This version is major rewrite of the underlying communication protocol between PanelDue and RepRapFirmware to enable a more flexible configuration in RepRapFirmware to be displayed correctly on PanelDue.

Upgrade notes:

• This release is compatible with RepRapFirmware 3.2-beta1 or later. It will partially work with RepRapFirmware 3.1.1 but not with any older version.
• Flashing this release will reset the configuration to defaults

Limitations

• Due to the lack of RAM this build will not run on version 1 or early version 2 PanelDue boards that use the ATSAM3S2B chip (models shipped until around the end of 2015). It is expected to work on later version 2 PanelDue boards using the ATSAM3S4B chip. If you have a PanelDue using the ATSAM3S2B chip, we suggest you replace the board by a version 3 PanelDue board, which can drive your existing LCD.

New and changed features:

• This release uses the RepRapFirmware ObjectModel instead of limited status responses
• Support for spindles with current RPM as well as active RPM
• Bed heater will only be shown if it is configured
• Support for chamber heaters (will only show if bed heater + number of tools <= 6)
• Tools and assigned heaters and extruders can be numbered arbitrarily (e.g. tool 1 can use heater 8 and extruder 2)
• A simple screensaver has been added to help preventing screen burn-in on long-lasting prints
• Tool buttons will reflect the tool status
• Prevent flickering if values did not change

Bug fixes

• Axes will be shown as they are configured, i.e. if configured axes are XYZA then PanelDue will display them like this instead of XYZU

Downloads and Instructions

Binaries can be found at https://github.com/Duet3D/PanelDueFirmware/releases/tag/3.2-RC1

EDIT: A new preliminary release with some bugs fixed can be found at: https://www.dropbox.com/sh/zbj590lu8udha8d/AADTx7RdBuGIhri8Xk18jNvua?dl=0

Flashing instructions can be found at https://duet3d.dozuki.com/Wiki/PanelDue_Firmware_update

Release plan

This is a release candidate and will either be followed by another release candidate in case bugs will be found or will be promoted to a final version.

@t3p3tony said in rfm - RepRapFirmware FileManager [duetbackup successor]:

@wilriker My vote goes for RepRapFirmware Total File Manager

Yeah, that's what I thought of, too.

Also another good idea might be
"[File-]Resource Manager for RepRapFirmware-based Filesystems" -> rm-rf
(Windows user's probably won't get this one)

I have written up a small guide to reduce motor stand-still noise at https://duet3d.dozuki.com/Wiki/Reducing_Stand-Still_Noise. I would like to ask for feedback.

Also I am missing the 500 reputation required to add a tag to this page so I would like to ask @dc42 or @T3P3Tony to add Duet Hardware tag to it so that it shows up on that page as well (or otherwise add it anywhere else where is would make sense).

P.S.: Another request to any moderator: this post should have gone to category "Tuning and Tweaking" and somehow ended up in "General Discussion" so please move it over. Thanks.

I am pleased to announce the final release of PanelDueFirmware 3.2.0. Following find the release notes:

Version 3.2.0

Upgrade Notes:

• This release is compatible with RepRapFirmware 3.2-beta1 or later. It will partially work with RepRapFirmware 3.1.1 but not with any older version.
• Flashing this release will reset the configuration to defaults

Limitations

• Due to the lack of RAM this build will not run on version 1 or early version 2 PanelDue boards that use the ATSAM3S2B chip.
  • Version 1.0, 1.1 and earlier v2 PanelDue: ATSAM3S2B processor (64MHz, 32kb RAM, 128kB flash) - these are the ones that the new firmware probably won't run on.
  • Version 2 PanelDue manufactured from August 2016: ATSAM3S4B processor (64MHz, 48kb RAM, 256kb flash). Will run the new firmware, but not as fast as version 3 will.
  • Version 3 PanelDue, including all 5i and 7i: ATSAM4S4B processor, 120MHz, 64kB RAM, 256kb flash. Will run the new firmware.
• There will be no reliable status updates coming from RepRapFirmware while waiting for heaters to reach temperature (and some other cases) before RRF 3.2-beta3.

New and changed features:

• This release uses the RepRapFirmware ObjectModel instead of limited status responses
• Support for spindles with current RPM as well as active RPM
• Bed heater will only be shown if it is configured
• Support for chamber heaters (will only show if bed heater + number of tools <= 6 on 5" and 7" or <= 4 on 4.3")
• Tools and assigned heaters and extruders can be numbered arbitrarily (e.g. tool 1 can use heater 8 and extruder 2)
• A simple screensaver has been added to help preventing screen burn-in on long-lasting prints
• Tool buttons will reflect the tool status (only "Active" and anything else ("Standby" is displayed as "Off" because it is confusing otherwise)
• Prevent flickering if values did not change

Changes within the Release Candidate iterations

• Status colors of tools were confusing (because a tool can never go to "off" after being active once) so it only shows "active" or "anything else"
• Extrusion and retraction commands are now a single line to prevent being interleaved by other commands
• Screensaver is now a popup to better interact with existing or incoming popups
• No longer fetch detailed M409 for Fans or Sensors (as they are currently not required)
• Only request null-flag for state request

Bug fixes

• Axes will be shown as they are configured, i.e. if configured axes are XYZA then PanelDue will display them like this instead of XYZU

Bug Fixes within the Release Candidate itereations

• In some cases setting a tool's heater would instead the heatbed temperature
• Chamber and heatbed icons did not change colors according to their state
• It was not possible to disable the chamber heater by tapping the chamber button
• Move popup buttons were none-functional
• Commands entered via on-screen-keyboard were not echoed into the text field
• Screensaver timeout select pop-up would not disappear when clicking anything but "Set" or a tab button
• Extrusion factor was not always targeting the correct extruder
• Extrusion factor controls were not hidden if amount of tools was decreased
• Bed and chamber controls were not hidden if they were removed from config
• If a JSON key path was too long it would result in an endless fetch-loop
• Message box was not closed on PanelDue if closed e.g. in DWC
• Fix some fields not being hidden correctly (possible screensaver fix)

Downloads and Instructions

Binaries can be found at https://github.com/Duet3D/PanelDueFirmware/releases/tag/3.2.0
Flashing instructions can be found at https://duet3d.dozuki.com/Wiki/PanelDue_Firmware_update

@mundsen said in Duet 3 Mainboard 6HC - initial production run.:

I got a question about duet 3 and pi - is the code transfered to the duet before the print Job starts or is it controlled real time by the pi during the print?

It is controlled real time. This also allows to implement plug-ins to do arbitrary modifications while the print is in progress. For example I have implemented a first version of an Object Skipper, i.e. a plug-in that is given the information on how to identify a certain object in the GCode (many slicers put specific comments in the GCodes) and then will filter out any commands related to this object (or multiple).

This allows for a print to continue where you have multiple objects on the platform but printing fails for whatever reason for one of them.

I will probably release this early next week.

pydsfapi

Here is a first version of the official Python 3.5+ client library to DuetSoftwareFramework.

I covers all connections modes available with the C# client. Currently the Machine Model is implemented as a very simple class that holds all the values as dictionaries. This might change in the future once the object model is stable.

You can find it at GitHub.

Feedback

Please test it and report any issues you find here so it can be fixed/changed to get to a stable API as soon as possible.

Request to Python experts

This code has been ported with a less-than-optimal Python knowledge. I would kindly ask for Python experts to have a look where things can be made more Pythonic or implementations can be improved (I assume significant improvements can be done with the custom HTTP endpoint code in regards of starting and stopping the EventLoop).

And to toss in one more solution: I wrote a small command line tool in Go to do exactly that. You can find it at https://github.com/wilriker/duetbackup. It works over the existing HTTP interface that is enabled by default (in contrast to FTP).

Right now there are no binary releases, i.e. you'd have to compile it yourself but on request I can very easily provide binaries for Windows, Linux (also for Raspberry Pi) and Mac.

Based on the calculations discussed in this thread and the resulting spreadsheet that @deckingman was so kind to provide to me I created an online version:

Maximum Acceleration Calculator

Just enter your details and the calculator will provide the maximum possible acceleration that your motor could handle.

By default it does not take any friction into account but under Advanced Settings you can find the "Axis friction factor" that can be used as a multiplier on the mass to move.

As always: feedback very welcome!

@Tinchus said in Maximum Acceleration Calculator:

Hi all. Question: the calculator here https://wilriker.github.io/maximum-acceleration-calculator/ request some data but what is about the case where you dont use pulleys? (axis moved directly using ballscrews for example)

In case of using any kind of screw to directly drive the axis you can approximate the pulley radius by dividing the screw lead by 2π. Remember to before or after convert from whatever unit you used to centimeters (if necessary). The value will probably be a tad bit too large but not in the amount that matters - and you should anyways always remove a security margin.

Example
if your screw has a lead of 2mm, i.e. every full rotation results in movement of 2mm, then you divide

2mm/2π=0.31831mm

Divide that again by 10 to convert it into cm and you have your virtual pulley radius.

I just released rmf v1.2.0 yesterday.

It contains a bug fix for the backup command when the amount of files in a directory on the SD card exceed the amount that can be returned by RRF in one single response - rfm used to go into an endless loop then.

Besides that it is not possible to abort any operation by sending an interrupt signal (pressing CTRL+C on the console). I recommend everyone to update to the latest version.

@jens55 Thanks for confirming!

I edited the pre release into an actual final release of rfm 1.2.0. No need for you to switch out anything it's the exact same binaries.

Will update the tool thread tomorrow. Happy this was solved so easy and sorry for the bug.

@jens55 Since I changed a lot of things besides fixing the issue for large file lists I bumped the version again and released the pre-release rfm v.1.2.0-RC1. Please check this. It should now work as intended. Besides the whole process can now be canceled by pressing CTRL+C cleanly.

@jens55 Yes, that actually helped. I found the issue and will provide a fixed version soon.

The problem is that www/js on your SD card contains more files than fit into a single response and while trying to fetch the remaining entries for this directory rfm locks itself in an endless loop because there is a bug on fetching the next entries.

Hi @jens55

Could you run rfm with parameter -verbose. This will print out more details that might better indicate where the problem actually happens. Please post the results here then.

EDIT: I just released rfm v1.1.2-RC1 that fixes an issue with the -debug flag that will print even more details than -verbose (but otherwise has no change in behavior).

@Nightowl rfm uses two sources to get the parameters to connect to a device. For convenience means it will save connection settings (-domain as well as -port and -password) in a config file. By default it uses a device called default for that.

You have to provide this information (only -domain is actually necessary, the other two can use the default value in 99% of the times) once and after that you can omit these because they are saved in the config file. So you need to call

rfm backup -domain <network address of your duet> -device Weeble ...

once to init the config file. After that you can omit -domain ... and just use -device Weeble - or unless you want to address multiple devices you can also omit the -device Weeble part and from the start and use the default device.

After that it should work.

@Nightowl Sorry for the very late reply. First of all rfm has an extensive help page, accessible via rfm help as well as rfm help <command> to get more details on specific commands.

rfm backup Weeble 0:/ //Libraries/CNC Files/Backups

looks somehow wrong to me. Most likely you missed -device in front of "Weeble". Also beyond that you have further three parameters where rfm only expects two, namely the local path (to write the backup to) and the remote path a.k.a. path on the Duet (specifically in this order). So your command rather likely should look like

rfm backup -device Weeble //Libraries/CNC 0:/

but where would be the best folder to locate rfm?

As you said you put it on your PC (so I assume Windows), to have it most easily working you need to add the directory you store rfm in into your PATH (I haven't used Windows in a decade so please bear with me if I cannot tell you how to do that on recent editions). On Windows there is (or at least was) no standard way of puting custom binaries anywhere so again this is left to you where to actually put the binary (sorry).

I'm assuming all the folders should be backed up, but does rfm process them all

rfm will simply backup everything recursively under the given remote path. In your case 0:/ will simply back yup every single file it can find on the SD card.

Is there a naming protocol for the backup files, or will they be overwritten every time they're backed up?

They will be overwritten continuously with each run. It will leave remotely removed files locally though unless you also pass the parameter -removeLocal.

@Garth_42 rfm is intended to be used with boards in standalone-mode. AFAIR SBC builds do not support the full HTTP interface for file management plus any SBC has much more powerful means to interact with files than I could ever implement.

@Nightowl said in rfm - RepRapFirmware FileManager [duetbackup successor]:

The first question I have is, should I install rfm on the Mac and run it from there, or install it on the Surface Pro and run rfm from the Mac (via RD), and the second question is, which version should I use if it's installed on the Mac?

Actually this just depends on what is more convenient for you. As long as rfm is able to connect to RRF via network this does not matter.

I personally would probably install it on the Surface Pro just because it is closer. But again, it just boils down to what is more convenient for you. Mine is installed on a Raspberry Pi that is lingering around somewhere in the house and runs a background task that periodically checks if it can backup anything or not.

If you want to install it an the Mac use darwin binary. Although this will not work on a M1 MacBook. When I compiled rfm the last time there were not M1's around AFAIR.