Is there a guide for a recommended file structure?
-
I'm discovering piecemeal that certain files are needed to create a functional system. I know that it's "just code" and that there's a million ways to do things (with macros, for example), and not everyone has need of every function, but I keep getting surprised to find that another gcode is expecting a routine to exist that doesn't.
Is there a guide or list for all the routines necessary for a full system? For example, G29 calls bed.g, M703 tries calling a filament config file (confusingly named) config.g, homing X expects that there will be a homex.g, and so on. Some (most?) of these post no error or warning if the file is not present, so I've ignorantly gone on my way, only later figuring out what's going on. Having the list would be helpful because it makes users aware of what's expected in case we use that function.
And yes, the little voice in my head is saying "well if you'd read the gcode guide, you'd know what each gcode does and what it expects..."
Scratch-built 350mmx350mm coreXY, linear rails, ballscrews, 3 Z axis, Duet3 6HC, v3.3, Tool Board v1.1, BondTech LGX + Mosquito hot end
-
@kb58 See https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_SD_card_structure and https://duet3d.dozuki.com/Wiki/SD_Card#Section_Creating_the_file_structure
There's also another folder now; 'Firmware' (from RRF 3.3) which holds the firmware files.
Ian
-
@kb58 said in Is there a guide for a recommended file structure?:
And yes, the little voice in my head is saying "well if you'd read the gcode guide, you'd know what each gcode does and what it expects..."
That's basically how I learned - along with asking questions here.
Frederick
-
You can also see what the config tool generates. It won't have some of the more advanced features but it will have all of the required files.
-
Great question - I'm closing in on a multi-tool design and pondering the order that the tpreN, tpostN, and tfreeN files are called and if what might call them other than a TN or T-1 code. My plan is to add some comments in those files and watch the log.
Semi-related.... code style. The group I'm working with keeps our gcode stack in github and I wrote a python script that walks through all the files and copies flagged comments into a separate .md file so that we have some auto generated documentation. I'd be happy to evolve to some common standard if there is one. Here's is an example of our config.g and config.md files. ( I had to change the .md filetype to .md.txt to get past the upload filter)
config.g
config.md.txt -
@mikeabuilder said in Is there a guide for a recommended file structure?:
Great question - I'm closing in on a multi-tool design and pondering the order that the tpreN, tpostN, and tfreeN files are called and if what might call them other than a TN or T-1 code. My plan is to add some comments in those files and watch the log.
tfree#.g is called first if a tool is already selected, where # is the number of the old tool. Then tpre#.g is called, where # is the number of the new tool. Then the new tool is activated; the tpost#.g is called.
The only other command that may call these files is M109, because M109 does an implicit tool selection if no tool is selected. This is a workaround for slicers that issue M109 without selecting a tool first.
-
Thanks. So my assumption about T# and T-1 being the primary caller of the tools is correct (something I'll add to the wiki if I get to the point of editing). One thing that is unclear to me is why there is a need for tpre#.g and also tpost#.g instead of a single command. My assumption at this point is that the separation is for users that want to pre-heat their tools prior to tool selection, maybe as part of machine startup, or maybe in the header of a part file. I assume the RRF does not insert other execution steps between the two when executing a T#.
-
@mikeabuilder said in Is there a guide for a recommended file structure?:
One thing that is unclear to me is why there is a need for tpre#.g and also tpost#.g instead of a single command.
It's not necessary to use both macros. Leave one macro empty, then it's acting like you have only one macro...
-
True, I could use just one. But I like to know why things are designed as they are. Usually a very good reason that I might not have thought of.
-
@mikeabuilder The possibilities are much greater with having both macros.
There are very different setups and use cases with the Duet boards. The toolchange setup can also be very different.
I think, there are users which are happy to have a tpre#.g and tpost#.g -
@mikeabuilder said in Is there a guide for a recommended file structure?:
So my assumption about T# and T-1 being the primary caller of the tools is correct (something I'll add to the wiki if I get to the point of editing).
https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_T_Select_Tool
https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCartesianPrinter#Section_Tool_change_files
-
@Phaedrux, thanks for the pointers to the wiki. I've read it before but the step describing setting the tool to the new operating temp after tpre#.g is executed disappeared from my memory.
My pseduo code for the three files are:tfree:
;!0. Remember the tool location.
;!1. Lower the bed a bit.
;!2. Retract the filament a bit.
;!3. Call the nozzle wiping macro (if we make one).
;!4. Set the nozzle temperature to a standby value.
;!5. Move the tool in front of the tool dock.
;!6. move the tool into the dock.
;!7. Call the macro that turns the tool latch to the unlatched position.
;!8. Move the tool carrier back from the tool dock.
;!9. Perform some task that confirms the tool was really left on the dock and is not still attached to the carrier, or fell out of the dock. No idea how to do this yet.
;!10. Return to the remembered location.tpre:
;!0. Heat the nozzle to it's target temperature.tpost:
;!1. Lower the bed a bit so we don;t hit anything.
;!2. Switch to the master coordinate system so we can find the tool dock.
;!3. Move to a position just in front of the tool dock.
;!4. Move the tool carrier into the docked tool position (advance Y).
;!5. Call the macro to lock the tool to the carriage.
;!6. Move backout of the dock. Hopefully we have something that verifies the tool is porperly docked.
;!7. Switch to this tools coordinate system (means engage it's offsets in X, Y, and Z).
;!3. Execute the wiping macro (if we make one).
;!4. Move back to the remembered location
