Towards printer-independent GCode January 03, 2018 08:41AM |
Registered: 10 years ago Posts: 14,672 |
Re: Towards printer-independent GCode January 03, 2018 09:08AM |
Registered: 7 years ago Posts: 507 |
Re: Towards printer-independent GCode January 03, 2018 09:09AM |
Registered: 8 years ago Posts: 601 |
Re: Towards printer-independent GCode January 03, 2018 09:18AM |
Registered: 10 years ago Posts: 14,672 |
Re: Towards printer-independent GCode January 03, 2018 09:28AM |
Registered: 10 years ago Posts: 14,672 |
Quote
Origamib
How about making gcode post processors to modify settings? As we step into more elaborate printing, these post processors are quite useful anyway.
Quote
Origamib
Personally, I'm not sure i see the need for gcode rather then .stl files. If settings are a problem then shouldn't we be looking to make hardware advances that eliminate settings? Eg, bed levelling to eliminate z Offsets and other first layer settings.
Quote
Origamib
What does gcode solve, other then to make a set of problems across many machines? Well dialed in machines don't require us to change many settings before slicing anyway.
Quote
Origamib
Further to this, we actually have to set up our machines to accept gcode files (eg, changing the xy co ords to be at the center). Alot of faff for something that is *almost *equivalent to an stl file, but actually more limiting (can't edit gcode easily to add new parts, but an stl can imported into mesh mixer etc)
Re: Towards printer-independent GCode January 03, 2018 09:59AM |
Registered: 9 years ago Posts: 383 |
Re: Towards printer-independent GCode January 03, 2018 10:30AM |
Registered: 7 years ago Posts: 363 |
Re: Towards printer-independent GCode January 03, 2018 11:26AM |
Registered: 8 years ago Posts: 5,232 |
Re: Towards printer-independent GCode January 03, 2018 11:54AM |
Registered: 9 years ago Posts: 383 |
Re: Towards printer-independent GCode January 03, 2018 12:36PM |
Registered: 8 years ago Posts: 601 |
Quote
dc42
Quote
Origamib
Personally, I'm not sure i see the need for gcode rather then .stl files. If settings are a problem then shouldn't we be looking to make hardware advances that eliminate settings? Eg, bed levelling to eliminate z Offsets and other first layer settings.
Many settings - in particular, appropriate speeds - are very dependent on the machine.
Quote
Origamib
What does gcode solve, other then to make a set of problems across many machines? Well dialed in machines don't require us to change many settings before slicing anyway.
That's only true if you already have the slicer settings dialled in for your machine and the filament type you are using. You may still have to configure support, and perhaps have one or two failed prints before you get it right.
Quote
Origamib
Further to this, we actually have to set up our machines to accept gcode files (eg, changing the xy co ords to be at the center). Alot of faff for something that is *almost *equivalent to an stl file, but actually more limiting (can't edit gcode easily to add new parts, but an stl can imported into mesh mixer etc)
Sure, if you want to modify the model, you will need to start from the STL model or whatever it was created from. But for a new user who doesn't yet understand slicing very well and just wants to print something, it would be easier if he/she could just download a GCode file which already has the support in the right places, and isn't tied to that particular make/model of 3D printer.
Re: Towards printer-independent GCode January 03, 2018 03:22PM |
Registered: 8 years ago Posts: 622 |
Quote
dc42
Have I missed any important information that the slicer currently needs to know about the printer?
Re: Towards printer-independent GCode January 03, 2018 04:15PM |
Registered: 8 years ago Posts: 601 |
Re: Towards printer-independent GCode January 03, 2018 05:14PM |
Registered: 9 years ago Posts: 383 |
Quote
Origamib
I have to say, am I missing something? Is slicing something people don't like doing? I find it is not an excessively annoying part of my tool chain.
Re: Towards printer-independent GCode January 04, 2018 12:43AM |
Registered: 9 years ago Posts: 383 |
Re: Towards printer-independent GCode January 04, 2018 05:54AM |
Registered: 8 years ago Posts: 622 |
Quote
Origamib
I have to say, am I missing something? Is slicing something people don't like doing? I find it is not an excessively annoying part of my tool chain.............
Re: Towards printer-independent GCode January 04, 2018 06:01AM |
Registered: 8 years ago Posts: 601 |
Quote
deckingman
Quote
Origamib
I have to say, am I missing something? Is slicing something people don't like doing? I find it is not an excessively annoying part of my tool chain.............
All true. The only thing I can say is that with the multiple hot end options that I have (3 colour, 5 colour, 0.5mm, 0.9mm etc), I end up with a lot of duplicated gcode files which were generated from the same stl, and that I have to add an identifier to the file name so that if I want to repeat a print some time later, I pick the hot end for the gcode file that I want to use. So in a way it would be useful not to have to do this but as you say, it's not a huge issue. Sometimes I have forgotten to add an identifier to the file name so don't know which hot end configuration I used when I sliced the object. But it's no big deal to load the stl and slice it again while the bed is heating up.
Re: Towards printer-independent GCode January 04, 2018 10:00AM |
Registered: 8 years ago Posts: 622 |
Quote
Origamib
It seems to me that this and multiple machines are the only legitimate use for gcode files. This only affects a tiny proportion of the market though, and if we are really after changes to make first time printing easier there is other low hanging fruit to consider
Re: Towards printer-independent GCode January 04, 2018 02:40PM |
Registered: 10 years ago Posts: 14,672 |
Re: Towards printer-independent GCode January 04, 2018 03:21PM |
Registered: 8 years ago Posts: 622 |
Quote
dc42
........................ And then the firmware will turn it back into line segments anyway. So unless you can find a compelling reason for making gcode files smaller, it's hard to see what the benefits would be........................
Re: Towards printer-independent GCode January 04, 2018 04:18PM |
Registered: 7 years ago Posts: 363 |
Quote
deckingman
Oh. I thought G2 and G3 were for doing true arcs as single moves. If the firmware chops these G2\G3 single arc move commands back into multiple small segmented moves, then yes it's pointless. I was rather hoping that doing an arc as a single move would get around the jerky movement problem pressure advance causes with small segmented moves and prevents me from being able to use it.
Re: Towards printer-independent GCode January 04, 2018 04:27PM |
Registered: 9 years ago Posts: 383 |
Quote
obelisk79
The benefit is just to make the g code more concise and as a bonus the files would become much smaller.
Re: Towards printer-independent GCode January 04, 2018 04:50PM |
Registered: 8 years ago Posts: 622 |
Quote
obelisk79
Also, what firmware are you using?
Re: Towards printer-independent GCode January 04, 2018 04:54PM |
Registered: 10 years ago Posts: 14,672 |
Quote
deckingman
Quote
obelisk79
Also, what firmware are you using?
Duet - latest version. The issue I have with pressure advance is that it cleans up prints nicely when running at high speed but makes arcs jerky and curves become faceted. It's because I run a mixing hot end and use 3 or 5 extruders concurrently. Something to do with the gcode processor not being able to fill the movement queue as fast as the motion system empties it apparently.
Re: Towards printer-independent GCode January 04, 2018 05:43PM |
Registered: 8 years ago Posts: 622 |
Quote
dc42
Quote
deckingman
Quote
obelisk79
Also, what firmware are you using?
Duet - latest version. The issue I have with pressure advance is that it cleans up prints nicely when running at high speed but makes arcs jerky and curves become faceted. It's because I run a mixing hot end and use 3 or 5 extruders concurrently. Something to do with the gcode processor not being able to fill the movement queue as fast as the motion system empties it apparently.
It's much more likely to be because there are too few facets, so the angle between adjacent segments is too great to permit speed to be maintained without violating the jerk limits.
Re: Towards printer-independent GCode January 04, 2018 09:04PM |
Registered: 11 years ago Posts: 1,049 |
Re: Towards printer-independent GCode January 05, 2018 03:20AM |
Registered: 9 years ago Posts: 383 |
Quote
cozmicray
the 3D printing world needs a type of language to move forward
Re: Towards printer-independent GCode January 05, 2018 03:38AM |
Registered: 8 years ago Posts: 622 |
Quote
cozmicray
The progression in ink printing was
dot-matrix
Ink-jet
Laser
and greater and greater resolution
Printing at the resolution of the printer not the display device
Postscript was developed to provide the language for this.
(first device-independent Page Description Language (PDL),)
the 3D printing world needs a type of language to move forward
Re: Towards printer-independent GCode January 05, 2018 10:17AM |
Registered: 7 years ago Posts: 363 |
Quote
deckingman
But in each step in the progression, different technologies were employed too. To move forward, we need more than just language. Personally I think out robot controlled hot melt glue guns have just about reached the limits and are rapidly approaching the end of their life cycle.
Re: Towards printer-independent GCode January 05, 2018 12:13PM |
Registered: 8 years ago Posts: 622 |
Quote
obelisk79
Quote
deckingman
But in each step in the progression, different technologies were employed too. To move forward, we need more than just language. Personally I think out robot controlled hot melt glue guns have just about reached the limits and are rapidly approaching the end of their life cycle.
What will take it's place?
.......................................
Re: Towards printer-independent GCode January 05, 2018 12:23PM |
Registered: 9 years ago Posts: 383 |