Interest in saving effort by sharing gcode?
Posted by tobben
|
Re: Interest in saving effort by sharing gcode? September 12, 2016 03:15PM |
Tobben,
I want to get to the root of your issue, so bear with me - I'm not trying to pick it apart - I am providing possible solutions.
My background is in all facets of design and development of multi-tier computer systems and desktop apps, and I have been working for over a year on analyzing and post processing gcode from multiple slicers.
My basic design rules are:
#1: First carefully describe the output/result that you really want.
#2 There needs to be a good reason/benefit for any work done.
#3 Complexity kills - don't do it.
You listed these goals which I've prioritized and summarized:
(Convenience, Sharing, Just click Print)
1) For convenience.
2) It would make RepRapping easier and allow us to leverage on each others' slicing work as a community.
3) My teen workshop students want to "just press print" a couple of times before they dig into slicing details. I give them default slicing settings and automatic instantaneous slicing, but it gives them ugly prints.
(Portability)
4) I just like the idea of sending off ready-to-use gcodes to my RepRapping friends, especially those who dislike slicing themselves.
5) Portable gcode would allow people to specialize on slicing well, and we would benefit from their work. Consistent and well-behaving gcodes.
(Good Models / Model Repair)
6) I often run into damaged STL-files on CAD sharing sites. Portable gcode would save in on my time and attention even if it made my printer run slower, if it just worked.
7) Tools for manipulating gcode, who give visual and fine-grained control, would make more sense to use and develop for portable gcode.
So here is my analysis:
1, 2, 3 - (Convenience, Sharing, Just click Print)
What is really needed is printers that just print well - because the firmware and slicer settings are tuned properly. This is the root of the problem, and nothing else will fix it, not moving the slicing to a stranger for sure, and not having it sliced from a CAD file, or by an agnostic gcode to tuned gcode converter.
There are several things that would make tuning easier, and multiple complications - since the Reprap community, and it's printers are by definition not "standard".
Solution 1: There could be a central repository of ini files - by firmware type and by printer type. This would help new Reprappers get started tuning their machines by having some sane defaults. This would need to be curated.
Solution 2: A repository of good slicer settings by printer model and slicer. This would help with the more common printers, but there are multiple complications - different hot ends and filament types and even filament batches require different speeds and temperatures, variations in thermistor readings, the temperature of the room, quality of the build, etc. Still, it may help get started with sane values. This also would need to be curated. One could always ask in a forum.
Solution 3: A Guided Calibration program - to guide the user through calibrating each variable (firmware and slicer print settings). This would output gcode specific to their printer to test a specific variable - the user would print the test and visually or by measurement - pick the best result. I know this will work because I have already programmed and tested multiple modules for Guided Calibration, but I'm busy working on other things - gcode post processing for pressure compensation.
Solution 4: For your students - you should go through the calibration process with one of your printers, and supply the students with the conservative slicer settings that you find work well. This is what our maker space does. The default settings in slicers are only good for one printer - the printer the slicer developer used!
Solution 5: Buy a commercial slicer like Simplify 3D if it already has a profile for your printer. This will only get you started tho, you still need a calibrated printer and known good settings for temp, speed, extrusion width etc for your particular printer, hot-end, and filament.
BTW, although it would be nice, it would be of little use requesting the free slicer developers to add default parameters for different printer models. Some are a year or more behind in bug fix requests... Someone has to do the work... often for free, and "someone" would still need to supply the particular tuned profile for each different printer/hot end combination. I think it's better for them to concentrate on making it bug free... I do notice that Simplify 3D has been adding a lot of printer profiles lately for commercial printers.
4, 5 (Portability, Well behaved gcode)
You are talking about printer agnostic gcode that just works. However, as stated above, both the firmware and gcode commands executed need to be tuned for the particular printer, hot end, filament, etc.
So what is going to apply the tuned settings to the Gcode? Shifting the burden to a new PC based program to take the agnostic gcode, and output well tuned gcode (or other instructions) means you must already know what the well-tuned firmware and print parameters are for your particular printer, filament, hot end, etc.
This burden can not be moved to the firmware either for multiple reasons. A) the people writing the firmware have enough on their plates just making the printer do what it's told to do by the gcode.
The firmware is already complex - adding further complexity will break it on 8-bit machines (not enough processor cycles), and will make it un-maintainable for all machines. C) Firmware should be set-it-and-forget-it. Most firmware requires a recompile to update the settings. (Rule #3)
"Slicing well" means you have done the calibration and test prints, and know the limits of your machine, so you use the right values in different situations.
There needs to be a better calibration guide here - I was planning on writing one for Slic3r - but too busy doing other research, and I've switched to S3D!
6,7 (Good Models / Model Repair)
Good models - Unfortunately you will not get what you want by sharing Gcode. You will only get less or no models, as the free sites you describe will not be publishing gcode.
Solution 1) Use a better model repository that has checked their models.
Solution 2) Buy you model if you have to - your time is worth money.
Solution 3) Create your own model.
Solution 4) Get a good repair tool. I have learned to use Meshmixer. It's free and very powerful. It does have a learning curve, but is better than anything else I have seen for the extensive repairs I have done. Watch the videos.
Solution 5) Request that people also share their models as well as the gcode (so they can be more easily modified)
I have done extensive post-processing including the insertion of angular hops, breaking segments or converting segments to other uses (like early retract or unretract, pressure compensation, etc), calculation of loop acceleration profiles, speed, extrusion rate, so I understand gcode.
Unfortunately there are a few other things that will make sharing gcode impractical.
- The primary thing dc42 alluded to has implications: "Nozzle diameter: the slicer needs to be able to choose the extrusion width, otherwise solid infill isn't going to work."
The fundamental thing that gcode describes is the tool path, not the object shape. There is no getting around this. For example if someone slices using an extrusion width of .65mm, the tool path exactly describes the printhead movement to lay the filament that X/Y distance apart (give or take overlap). It is not practical to move/add to/subtract from/convert the tool path to work with another extrusion width. Please do not suggest multiple versions of the same gcode for different extrusion widths.
The next issue is layer height. The tool path described by gcode lays down the perimeters and infill at a specific layer height. Well, what if they want to print at .15mm instead of .25mm, or vice versa? The converter/optimizer would have to basically re-slice and interpolate, and the unavoidable result will be the loss of precision. An STL or other 3D format better describes the object, and slicers already slice well... Please do not suggest multiple gcode versions of the same object for different layer heights AND extrusion widths.
Why do it? (Rule #2). Just output to stl or obj, and slice.
Well, I hope I have provided some perspective and possible solutions!
Good luck with your endeavors.
My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!
I want to get to the root of your issue, so bear with me - I'm not trying to pick it apart - I am providing possible solutions.
My background is in all facets of design and development of multi-tier computer systems and desktop apps, and I have been working for over a year on analyzing and post processing gcode from multiple slicers.
My basic design rules are:
#1: First carefully describe the output/result that you really want.
#2 There needs to be a good reason/benefit for any work done.
#3 Complexity kills - don't do it.
You listed these goals which I've prioritized and summarized:
(Convenience, Sharing, Just click Print)
1) For convenience.
2) It would make RepRapping easier and allow us to leverage on each others' slicing work as a community.
3) My teen workshop students want to "just press print" a couple of times before they dig into slicing details. I give them default slicing settings and automatic instantaneous slicing, but it gives them ugly prints.
(Portability)
4) I just like the idea of sending off ready-to-use gcodes to my RepRapping friends, especially those who dislike slicing themselves.
5) Portable gcode would allow people to specialize on slicing well, and we would benefit from their work. Consistent and well-behaving gcodes.
(Good Models / Model Repair)
6) I often run into damaged STL-files on CAD sharing sites. Portable gcode would save in on my time and attention even if it made my printer run slower, if it just worked.
7) Tools for manipulating gcode, who give visual and fine-grained control, would make more sense to use and develop for portable gcode.
So here is my analysis:
1, 2, 3 - (Convenience, Sharing, Just click Print)
What is really needed is printers that just print well - because the firmware and slicer settings are tuned properly. This is the root of the problem, and nothing else will fix it, not moving the slicing to a stranger for sure, and not having it sliced from a CAD file, or by an agnostic gcode to tuned gcode converter.
There are several things that would make tuning easier, and multiple complications - since the Reprap community, and it's printers are by definition not "standard".
Solution 1: There could be a central repository of ini files - by firmware type and by printer type. This would help new Reprappers get started tuning their machines by having some sane defaults. This would need to be curated.
Solution 2: A repository of good slicer settings by printer model and slicer. This would help with the more common printers, but there are multiple complications - different hot ends and filament types and even filament batches require different speeds and temperatures, variations in thermistor readings, the temperature of the room, quality of the build, etc. Still, it may help get started with sane values. This also would need to be curated. One could always ask in a forum.
Solution 3: A Guided Calibration program - to guide the user through calibrating each variable (firmware and slicer print settings). This would output gcode specific to their printer to test a specific variable - the user would print the test and visually or by measurement - pick the best result. I know this will work because I have already programmed and tested multiple modules for Guided Calibration, but I'm busy working on other things - gcode post processing for pressure compensation.
Solution 4: For your students - you should go through the calibration process with one of your printers, and supply the students with the conservative slicer settings that you find work well. This is what our maker space does. The default settings in slicers are only good for one printer - the printer the slicer developer used!
Solution 5: Buy a commercial slicer like Simplify 3D if it already has a profile for your printer. This will only get you started tho, you still need a calibrated printer and known good settings for temp, speed, extrusion width etc for your particular printer, hot-end, and filament.
BTW, although it would be nice, it would be of little use requesting the free slicer developers to add default parameters for different printer models. Some are a year or more behind in bug fix requests... Someone has to do the work... often for free, and "someone" would still need to supply the particular tuned profile for each different printer/hot end combination. I think it's better for them to concentrate on making it bug free... I do notice that Simplify 3D has been adding a lot of printer profiles lately for commercial printers.
4, 5 (Portability, Well behaved gcode)
You are talking about printer agnostic gcode that just works. However, as stated above, both the firmware and gcode commands executed need to be tuned for the particular printer, hot end, filament, etc.
So what is going to apply the tuned settings to the Gcode? Shifting the burden to a new PC based program to take the agnostic gcode, and output well tuned gcode (or other instructions) means you must already know what the well-tuned firmware and print parameters are for your particular printer, filament, hot end, etc.
This burden can not be moved to the firmware either for multiple reasons. A) the people writing the firmware have enough on their plates just making the printer do what it's told to do by the gcode.
The firmware is already complex - adding further complexity will break it on 8-bit machines (not enough processor cycles), and will make it un-maintainable for all machines. C) Firmware should be set-it-and-forget-it. Most firmware requires a recompile to update the settings. (Rule #3) "Slicing well" means you have done the calibration and test prints, and know the limits of your machine, so you use the right values in different situations.
There needs to be a better calibration guide here - I was planning on writing one for Slic3r - but too busy doing other research, and I've switched to S3D!
6,7 (Good Models / Model Repair)
Good models - Unfortunately you will not get what you want by sharing Gcode. You will only get less or no models, as the free sites you describe will not be publishing gcode.
Solution 1) Use a better model repository that has checked their models.
Solution 2) Buy you model if you have to - your time is worth money.
Solution 3) Create your own model.
Solution 4) Get a good repair tool. I have learned to use Meshmixer. It's free and very powerful. It does have a learning curve, but is better than anything else I have seen for the extensive repairs I have done. Watch the videos.
Solution 5) Request that people also share their models as well as the gcode (so they can be more easily modified)
I have done extensive post-processing including the insertion of angular hops, breaking segments or converting segments to other uses (like early retract or unretract, pressure compensation, etc), calculation of loop acceleration profiles, speed, extrusion rate, so I understand gcode.
Unfortunately there are a few other things that will make sharing gcode impractical.
- The primary thing dc42 alluded to has implications: "Nozzle diameter: the slicer needs to be able to choose the extrusion width, otherwise solid infill isn't going to work."
The fundamental thing that gcode describes is the tool path, not the object shape. There is no getting around this. For example if someone slices using an extrusion width of .65mm, the tool path exactly describes the printhead movement to lay the filament that X/Y distance apart (give or take overlap). It is not practical to move/add to/subtract from/convert the tool path to work with another extrusion width. Please do not suggest multiple versions of the same gcode for different extrusion widths.
The next issue is layer height. The tool path described by gcode lays down the perimeters and infill at a specific layer height. Well, what if they want to print at .15mm instead of .25mm, or vice versa? The converter/optimizer would have to basically re-slice and interpolate, and the unavoidable result will be the loss of precision. An STL or other 3D format better describes the object, and slicers already slice well... Please do not suggest multiple gcode versions of the same object for different layer heights AND extrusion widths.
Quote
tobben
Consuming STEP files would be great, but requires a huge effort. How do you suggest we start a STEP consumption project?
Why do it? (Rule #2). Just output to stl or obj, and slice.
Well, I hope I have provided some perspective and possible solutions!
Good luck with your endeavors.
My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!
|
Re: Interest in saving effort by sharing gcode? September 13, 2016 07:12PM |
Calibration constants will be the same whether you feed them into a ini-file or a firmware. You do not in general need to compile/upload firmware to feed it some constants. Machine specifics should be contained within the machines, and their interfaces should be kept clean if you care about design principles. Gcode is the interface between the desktop computer and the RepRap.
Firmwares are not complex compared to other small/medium sized c/c++ programs we use every day.
I use print widths between 0.5 to 0.8 mm regularly without changing nozzle and it works well.
I like to slice myself, and would not stop slicing even if portable gcode existed. I would also like to share the gcode I created.
Technical designers often know how their 3d designs should be fabricated in order to function as specified. Portable gcode (or STEP) would give them a language to communicate their knowledge clearly.
Portability and modularity are good things.
Edited 1 time(s). Last edit at 09/13/2016 07:19PM by tobben.
torbjornludvigsen.com
Firmwares are not complex compared to other small/medium sized c/c++ programs we use every day.
I use print widths between 0.5 to 0.8 mm regularly without changing nozzle and it works well.
I like to slice myself, and would not stop slicing even if portable gcode existed. I would also like to share the gcode I created.
Technical designers often know how their 3d designs should be fabricated in order to function as specified. Portable gcode (or STEP) would give them a language to communicate their knowledge clearly.
Portability and modularity are good things.
Edited 1 time(s). Last edit at 09/13/2016 07:19PM by tobben.
torbjornludvigsen.com
|
Re: Interest in saving effort by sharing gcode? September 14, 2016 11:43AM |
Wow! Careful and well thought out post-processing of gcode can give developers fantastic flexibility, that's very true 
Nice work!
torbjornludvigsen.com
Nice work!torbjornludvigsen.com
|
Re: Interest in saving effort by sharing gcode? September 15, 2016 05:00PM |
Yup, portable gcode would be for the lazy and those designers with detailed fabrication instructions. 
I kind of envy designer that get to assume full STEP-NC support. Also the programmers that get to work on STEP-NC support in slicers and firmware are quite lucky. I have a Master's in engineering physics, specialized on scientific computing in C and some experience with firmware hacking for my Hangprinter. I'd love to serve the lazy and the nitpick-designers if there is interest here?
torbjornludvigsen.com
I kind of envy designer that get to assume full STEP-NC support. Also the programmers that get to work on STEP-NC support in slicers and firmware are quite lucky. I have a Master's in engineering physics, specialized on scientific computing in C and some experience with firmware hacking for my Hangprinter. I'd love to serve the lazy and the nitpick-designers if there is interest here?
torbjornludvigsen.com
|
Re: Interest in saving effort by sharing gcode? September 15, 2016 08:06PM |
Agree about need for good top-level languages for objects and how to manufacture them. I'm suggesting improved (but still sub-optimal) gcode as a compromise to save in on required work hours. If lots of interest build up around changing stl and gcode for something better entirely then count me in on that project =)
Gcode has some fundamental limitations. Gcode files are ASCII-encoded, and therefore big (ASCII is transparent and handy, but sometimes you just need a smaller file). Gcode doesn't allow one to express allowed tolerances (marking important parts would let us speed up the rest). Gcode files are also large because curves need to be chopped into line segments. A better format would let us express curved paths as splines or Bezier curves, or maybe even as functions from t to (x, y).
Still, I think the worst thing with gcode (or the way RepRaps use gcode) is that it is mildly machine specific. This means designers can't use it to specify how their object is intended to be manufactured, and we who like slicing can not let others leverage on our slicing work.
Edited 1 time(s). Last edit at 09/15/2016 08:07PM by tobben.
torbjornludvigsen.com
Gcode has some fundamental limitations. Gcode files are ASCII-encoded, and therefore big (ASCII is transparent and handy, but sometimes you just need a smaller file). Gcode doesn't allow one to express allowed tolerances (marking important parts would let us speed up the rest). Gcode files are also large because curves need to be chopped into line segments. A better format would let us express curved paths as splines or Bezier curves, or maybe even as functions from t to (x, y).
Still, I think the worst thing with gcode (or the way RepRaps use gcode) is that it is mildly machine specific. This means designers can't use it to specify how their object is intended to be manufactured, and we who like slicing can not let others leverage on our slicing work.
Edited 1 time(s). Last edit at 09/15/2016 08:07PM by tobben.
torbjornludvigsen.com
|
Re: Interest in saving effort by sharing gcode? September 16, 2016 05:14AM |
Cool Cable printer...results are a little ropey though, & slow, I've seen some very fast cablebots,
I understand your idea for a suite of tools & an OS pre installed to a thumbdrive to function as class or off the shelf production factory,
I kinda did the same with my BeatSkool (10 years ago) I stopped short of a VM because it can be slow. and getting graphics card to work on the pass through is not an easy thing to do, but didn't take it quite as far as to write a thesis I dont have that formal training, so I can see your not the lazy type, and have a good reason for wanting another solution, I dont have programming skills so wouldnt say it cant be done, those clever people can do almost anything they set their mind to, the above suggestion sounds like a good idea, something new might be needed.
Perhaps if the Printers where more intelligent, they could skim through the commands they understand, a lookup table for the nozzle/filament size, ((bed placement/dim's) ignoring all the other code for alternate nozzles & paths, that didnt fit with the printers own config file
(or scale things on the fly, it's all relative).
But it sounds like the file would be huge, imagine it set for 100 permutations and you only need1% of the code...
If you wanted to encourage the spread of the VM Disc or Thumb, you could make it one of the first things they should do with the stick
Receive / Copy, that way you could have maybe 2 startups on the VM one which cant be changed and one that can, that way they could tailor things to their machines or way of doing it
"Shit just happens sometimes and when it happens we better know how to produce our stuff ourselves."
Did this line make it into the thesis
Edited 4 time(s). Last edit at 09/16/2016 02:27PM by MechaBits.
though, & slow, I've seen some very fast cablebots, I understand your idea for a suite of tools & an OS pre installed to a thumbdrive to function as class or off the shelf production factory,
I kinda did the same with my BeatSkool (10 years ago) I stopped short of a VM because it can be slow. and getting graphics card to work on the pass through is not an easy thing to do, but didn't take it quite as far as to write a thesis I dont have that formal training, so I can see your not the lazy type, and have a good reason for wanting another solution, I dont have programming skills so wouldnt say it cant be done, those clever people can do almost anything they set their mind to, the above suggestion sounds like a good idea, something new might be needed.
Perhaps if the Printers where more intelligent, they could skim through the commands they understand, a lookup table for the nozzle/filament size, ((bed placement/dim's) ignoring all the other code for alternate nozzles & paths, that didnt fit with the printers own config file
(or scale things on the fly, it's all relative).
But it sounds like the file would be huge, imagine it set for 100 permutations and you only need1% of the code...
If you wanted to encourage the spread of the VM Disc or Thumb, you could make it one of the first things they should do with the stick
Receive / Copy, that way you could have maybe 2 startups on the VM one which cant be changed and one that can, that way they could tailor things to their machines or way of doing it
"Shit just happens sometimes and when it happens we better know how to produce our stuff ourselves."
Did this line make it into the thesis
Edited 4 time(s). Last edit at 09/16/2016 02:27PM by MechaBits.
Sorry, only registered users may post in this forum.