Writing ALL profile-parameters into the gcode as comments

Hi there,

When I am doing a lot of experiments with slightely different settings it is quite an manual overhead to follow all the changes one is doing for the print, the filament and the printer.

Is there a way to write to the top of gcode all parameters that had been used as a comment?
e.g.
all parameters for the print, the filament and the printer
all used filenames + paths which had been used for the particular gcode

In total these will be about 200 parameters (estimation) but one could easily follow which parameters had been used for the particular gcode-file

best regards,
Leo

Check for them at the end of the file

Cool, that will help a lot :-)

Thanks for your answer!

best regards,
Leo

Quote
KORYBA
all used filenames + paths which had been used for the particular gcode

This particular piece of information is not in the gcode file (as far as I can see), and at least to me that would be highly useful. I often have several gcode files sliced from different versions/revisions of an STL, and knowing the filename and timestamp it was read would be very helpful in some cases.

Well, you have the time stamp right in the first line
With the filename, don't know what to say. I thing file management is a general issue, and if one is not able to keep files in the proper order, there are little chances that keeping an "inventory" of all the files on the plate won't be of too much help.
In normal circumstances you "assemble" a plate o parts that belong to the same complex object/project. If this is the case you should simply organize your "source" files correctly (for example by sub-assembly) and give an appropriate name to the aggregated plate.
If is just a single object, then keep the implicit same filename and make sure is in the directory you want (perhaps in the project directory).
If you have some significant difference between two gcodes of the same stl, simply add something to the file name (for example, abs or pla, blue or red, etc.)
It is more important to correctly administer the profiles. As you can see, there is yet no record on the name of the actual profiles used (if any has been saved). So, if you do some "reverse engineering", you really have to check/enter each parameter.

Well, I guess some people can easily adapt their "workflow" to fit what the software can do, but at least for me it would be of great help sometimes to see exactly which .stl files went into Slic3r, and the timestamp when they were read (or the timestamp of the file at the time it was read). I often have several versions of a file, and different sliced versions of it. Most of the time I can keep things in good order so that it doesn't matter, but it would be very useful to be able to find the correct source file for the times I don't.

Quote
3Dmaker4U
Well, you have the time stamp right in the first line
With the filename, don't know what to say. I thing file management is a general issue, and if one is not able to keep files in the proper order, there are little chances that keeping an "inventory" of all the files on the plate won't be of too much help.
In normal circumstances you "assemble" a plate o parts that belong to the same complex object/project. If this is the case you should simply organize your "source" files correctly (for example by sub-assembly) and give an appropriate name to the aggregated plate.
If is just a single object, then keep the implicit same filename and make sure is in the directory you want (perhaps in the project directory).
If you have some significant difference between two gcodes of the same stl, simply add something to the file name (for example, abs or pla, blue or red, etc.)
It is more important to correctly administer the profiles. As you can see, there is yet no record on the name of the actual profiles used (if any has been saved). So, if you do some "reverse engineering", you really have to check/enter each parameter.

Regarding your last point some time ago I made the suggestion that it would be quite useful if Slic3r could be able to read the printing parameters of an existing G-Code; that way it would be easier to replicate the settings used on a particular print quickly and with no risk of missing some parameter.

I'm curious about what was the response to the request. Did you actually requested on github or here?
Since the config comments are exactly the config content, I suppose would be easy. I think may be useful as well.

Quote
3Dmaker4U
I'm curious about what was the response to the request. Did you actually requested on github or here?
Since the config comments are exactly the config content, I suppose would be easy. I think may be useful as well.

I only posted it here, github gives me a headache...

Edited 1 time(s). Last edit at 09/04/2014 09:55PM by CaptainObvious.