Allow subfolders for config files

niocio01

Is it somehow possible to create subfolders in the "system" folder and still have duet recognize the files inside it?

I'm running a 7 Axis Systems with 4 tools and the system folder with all the config files has alot of files in it by now.

With one file per axis for homing and three files per tool + all the other config files it gets a bit unwieldy.
So a "Homig" and a "Tools" folder would help to get them more organized.
I've tried the naïve approach in just putting them inside folders, and hoping they would get recognized anyway, but no luck.
Is there a way to put them inside Folders?

fcwilt

@niocio01

Are you trying to call the files in the sub-folders from a file in the SYS folder, using M98?

If so just reference the path to the file in the sub-folder: M98 "folder_name\file_name"

Frederick

niocio01

@fcwilt
No, I'm trying to move the system defined files e.g. "homeall.g" into folders, which doesn't work out of the box.

I'm familiar with M98 for calling macros / subconfigs.

fcwilt

@niocio01 said in Allow subfolders for config files:

@fcwilt
No, I'm trying to move the system defined files e.g. "homeall.g" into folders, which doesn't work out of the box.

I'm familiar with M98 for calling macros / subconfigs.

I would think @dc42 would be the one to ask - it may take a firmware modification.

I've currently got 87 .G files in the SYS folder and it is not too bad.

But I rarely edit the files directly in the DWC.

Most editing/creating is done using a text editor called EditPad Pro would supports "projects", which are a collection of related files, and can use an FTP connection to the printer.

The FTP connection can be configured to access the parent folder of SYS in which case you have access to the Macro and Filament files as well.

If desired the FTP connection can also be configured to make backups (on the printer) of each file that is changed and to keep copies of each file on your computer.

Having all of the features of EditPad, like "Search and Replace", is just a bonus.

Good luck.

Frederick

niocio01

@fcwilt
Yea, I figured there is no easy way of just remapping the files, without firmware support.

Good tip with using an external editor. (Why haven't I thought of that )
I might be able to setup my usual code editor (VSCode) to do all the configuring remotely via FTP / SSH.

Thanks
Nico

deckingman

@niocio01 There are some thing that you can do. You don't have to put files in the in the .sys folder - it just makes calling them a bit easier. But you can put them in the macros folder or a sub folder therein as long as you use the correct path when calling them. For tool change macros, you can use meta commands and conditional gcode to create "universal" ones. There is a thread on here somewhere that I made about it. You still need tfreen, tpostn and tpren for each tool but all they contain is an M98 to the "universal" files which I called "ToolFree.g", "ToolPre,g" and "ToolPost.g". In my case I had 9 tools for different filament types as well as combinations thereof but they all used the same "universal" tool change macros.

niocio01

@deckingman
Yes, I saw your post a while back. I am planing to implement something similar.
I was thinking, I could use the arrays that are beeing introduced in RRF 3.5.0.
That way I can keep all the settings in one file and just use global variables to set the settings per tool to arrays. I can use the same code this way and just index the array with the tool number.

"
You don't have to put files in the in the .sys folder - it just makes calling them a bit easier. But you can put them in the macros folder or a sub folder therein as long as you use the correct path when calling them.
"
I guess this is only true for custom files, which have no defined naming convention like "HomeX.g" or "ToolPreN.g" right?
Which is what I'd like to do.

deckingman

@niocio01 said in Allow subfolders for config files

I guess this is only true for custom files, which have no defined naming convention like "HomeX.g" or "ToolPreN.g" right?
Which is what I'd like to do.

I don't think naming conventions are the problem and so I suspect that you could use the exact same names in different folders as long as you include the correct path in the M98 call. Having said that, I suspect that DWC uses a fixed path (one of the Duet guys would have to confirm that). If that is the case, then none of the homing buttons on the dashboard would work, unless there are copies of the files in the .sys folder, which rather defeats the objective. If the path that DWC uses can be changed, then we'd be able to put files in sub folders or anywhere else. I'd guess that the path for the tool change macros is also fixed in firmware, in which case we're likely to be stuck with having them in .sys. Although as I've explained, we can have simplified versions of tree, tpre and tpost which call other macros. Perhaps @dc42 could comment on if it's possible to change the path to those native macros.

dc42

@deckingman said in Allow subfolders for config files:

You still need tfreen, tpostn and tpren for each tool

That's no longer true in RRF 3.5. You can now have a single tpre.g file that is called for any tool that does not have its own tpreN.g file. Similarly for tpost.g and tfree.g.

niocio01

@dc42 said in Allow subfolders for config files:

You can now have a single tpre.g file that is called for any tool that does not have its own tpreN.g file. Similarly for tpost.g and tfree.g.

That's great to hear.
Is this also true for the "TriggerN.g" Files?

deckingman

@dc42 said in Allow subfolders for config files:

@deckingman said in Allow subfolders for config files:

You still need tfreen, tpostn and tpren for each tool

That's no longer true in RRF 3.5. You can now have a single tpre.g file that is called for any tool that does not have its own tpreN.g file. Similarly for tpost.g and tfree.g.

Brilliant!

dc42

@niocio01 said in Allow subfolders for config files:

Is this also true for the "TriggerN.g" Files?

No.

deckingman

@niocio01 said in Allow subfolders for config files:

Is this also true for the "TriggerN.g" Files?

DC said no, so what do your your trigger files look like? Could you use conditional gcode to make one "universal" triggerN.g?