Feature request - ability to select gcode folders

deckingman

I'm not sure if this is a firmware "thing" or a DWC "thing" - probably both.

Usage case.

I have a number of hot ends that I switch between - single input, dual input, and six input. Obviously I also have a number of different machine configurations to suit each hot end. I can switch between configurations using M505 to "point" to a different .sys folder which makes it easy to change the machine configuration (including system macros) to suit whichever hot end is installed. But all the "job" files are in one place - the gcodes folder. I have to use a complicated naming convention but this isn't infallible, and it is easy to mistakenly select a file which was sliced to use multiple tools and attempt to print it with a single input hot end. Also, I end up with a long list of gcode files, only a selection of which are possible to print with any particular hot end.

I can think of a few more usage cases other than my own - e.g. machines which have both additive and subtractive capabilities.

Requested change

Ideally, only the files that were sliced for a particular machine configuration should be available to print when that configuration is selected.

I can think of a few ways that this could be implemented. One possibility is to expand how M505 is used. Currently it is in the format that .sys gets change to (e.g.) /sys/config1. So if another folder called (say) gcodes) were added to /config1 then DWC would only show the gcode files that are in that sub folder of .sys/config1. If there is no such sub folder, then DWC would show the gcodes that exist in the existing root folder. This would mean that existing users with just a single machine configuration would not be impacted by the change.

Thoughts? Possible? Doable?

MintyTrebor

@deckingman In the meantime, there may be a hacky solution using a global variable and M471...

Create new gcodes directories on the sdcard root for every discrete configuration set you have created eg: 0:\gcodesC1, 0:\gcodesC2, 0:\gcodesC3 etc

In each config.g for each configuration set define a global var to store the current selected gcodesC# folder. eg for C1

global currGcodeFolder = "0:/gcodesC1"

(you do this so that it remembers which one has been renamed on reboot, and to define the global variable)

Create a "switch config" macro for each configuration set which does the following : (example for changing from C# to C2)

M471 S"0:/gcodes" T{global.currGcodeFolder} ;renames the current config set gcodes folder back to its unique name
M471 S"0:/gcodesC2" T"0:/gcodes" ;rename C2 config set gcodes folder to default name
Set global.currGcodeFolder = "0:/gcodesC2" ; update global variable to the currently renamed config set gcodes folder
M505 P"[C2 config folder Name]" ; change to C2 config folder

refresh your browser and DWC will now be updated to the "new" jobs folder.

I have not explicitly tested this, but I have tested renaming the gcodes folder and this does work, so it is just a matter of building a solution with the global variables to manage the folder renaming.

Hope this helps you to come up with a work around...

deckingman

@mintytrebor Thanks. That seems like a plausible hack. I'll wait a while and see what the Duet guys have to say about a possible change to firmware/DWC and if nothing is forthcoming, then I'll give your idea a go. Thanks for taking the time.

T3P3Tony

@deckingman thanks for the suggestion

As you can have subfolders of the "gcodes" directory already, I think it would be better to put the jobs for a particular folder in that subfolder. e.g.

0:/gcodes/1_extruder/
0:/gcodes/2_extruder/
0:/gcodes/6_extruder/

(names are arbitrary).

At this point of course you need to manually select the sub folder so the change would be to have DWC automatically switch to displaying the subfolder, based on the M505 configuration.

It would still be possible to navigate out of that subfolder manually if you wanted to, so its not in fallible but normal drag and drop uploads would go into the subfolder displayed.

The "upload and print" would need updating as well , as currently files dropped on that go into the root gcode folder.

Lets see what @chrishamm thinks from a UI perspective.

@MintyTrebor thanks for the renaming work around. I think this would work ok, but it fails badly if a configuration parameter is changed incorrectly you could be with orphan folders that are not visible through the UI.

deckingman

@t3p3tony Thanks for that. I didn't know about the ability to use sub-folders for gcodes. That's a great start and I'll implement that straight away. That's 80% of the problem solved straight away.

T3P3Tony

@deckingman yep this

should create sub directories

the only limitation is the full path name can't be too long, including the file names. so the more nested the sub directories the longer the path name, so the less characters you have left for file names. The whole string is capped at 120 characters AFAIR.

e.g.

0:/gcodes/0123456789/012.gcode

counts as 30 characters

MintyTrebor

@t3p3tony I'm not sure implementing which folder to use/see automatically in DWC UI is ideal, it would make it harder for plugins to determine which folders they should be using if a plugin happens to use these folders, and the user has switched configs. From memory I think DWC uses the directories .### object to determine the current paths.

I do agree that using sub folders is the right approach, but I think any change would have to respect the current object model directories.### objects, so that plugins are sure they are accessing the correct folders. Changing the directories.### object values in the object model should also mean that uploads would go the right sub folder too (I think). Maybe (as @deckingman suggested) changing the M505 command to include gcodes/macros/filament paths would be the most aligned with the current approach to directory handling.

T3P3Tony

this prompted me to add a bit to the documentation about max file lengths:
https://duet3d.dozuki.com/Wiki/Gcode#Section_Filenames_and_Paths

deckingman

@t3p3tony I add "XYUVAB" to the end of gcode file names after post processing so that the original sliced file remains intact and "unadulterated". But even so, 120 characters including the path should be ample, even for my unusual (extreme?) use case.

chrishamm

@t3p3tony Recent versions of DWC should use the paths defined by directories in the object model. So if there was a way to change the directories.gCodes value from RRF, DSF/DWC should use that instead of the default 0:/gcodes path.