Posts made by wilriker

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

By the way, what is the network protocol used by rfm?

rfm uses HTTP as the underlying communication protocol.

I will miss him, too. We had long conversations (outside of the forum) and he was always given me great and blunt feedback and advice on my ideas - whether 3D printers or anything else.

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

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

If I want to back up the macro folder on that Duet, what should the command look like? Based on the help section of rfm, I was trying ./rfm backup /macros -domain 192.168.1.163 but I get 'directory not found'.

You need to switch the order of parameters:

rfm backup -domain 192.168.1.163 <local-path> 0:/macros

Note that local-path is mandatory if you specify a remote path.

@phaedrux said in [DSF Extension] Exec On MCode (was: Shutdown SBC):

What's the answer?

The answer is that it depends on whether or not you use the -execAsync flag when starting execonmcode. If you do it won't block and if you omit it it will wait until the command has finished.

@martinnyhc said in PanelDueFirmware 3.2.11 released:

@wilriker OMG....I just ignored the second input file

No worries, hardly anyone (still) uses cat for what it originally was intended (neither do I).

@martinnyhc said in PanelDueFirmware 3.2.11 released:

Just recognized that there is a small typo in the README on github.

On Linux: Run this Linux command to append it to the binary: cat PanelDue-v3-5.0-nologo.bin myimage.bin > PanelDueFirmware.bin

should read

On Linux: Run this Linux command to append it to the binary: cat PanelDue-v3-5.0-nologo.bin myimage.bin >> PanelDueFirmware.bin

Actually the former command is correct because it will create a new file PanelDueFirmware.bin from the con_cat_enation of the two input files PanelDue-v3-5.0-nologo.bin and myimage.bin. The second command will work as long as there is no PanelDueFirmware.bin already present. If that is the case it would append the result to the existing file making it an invalid (and too large) firmware binary.

@oozebot said in [DSF Extension] Exec On MCode (was: Shutdown SBC):

Any interim builds out there floating around I could download to get past this issue?

There are no interim builds of DSF available. You would have to build it yourself from sources. What @Phaedrux posted was "only" preliminary builds of RRF 3.3-rc3.

@CrazyCreator @oozeBot I can confirm that this bug will be fixed with DSF v3.3-rc3.

@crazycreator It's not RRF but DSF (DCS to be exact) that has that problem. And the next RC is planned to be released within the next couple of days unless important issues will postpone it.

@crazycreator Hm, there is something strange here. I can now reproduce your issue. I have to investigate that.

EDIT: It seems that you discovered a but in DCS 3.3-rc2 (and possibly earlier) that will be fixed in the next RC (I have to confirm that still).