Posts: 178
Joined: Mon Mar 02, 2015 1:23 pm

Re: reduce resolution

Tue Apr 28, 2020 12:57 pm

Most likely it's my 'Old Man' ignorance as I was born in the 1940's. But, having been an Engineer, Rocket Scientist and Programmer - including writing Gcode for milling machines (and Manager of many departments) for so long (and remembering when I used .STL for the purpose it was created - Stereo Lithography (SLA) printing, I have a particular jaded interest in what people 'think they know'...

In nearly the time spent in these posts, a User could have learned how to use a CAD program, including the free one's (my favorite it FreeCAD, though it does have problems, as do all OpenSource app's).

Knowing how to make your own model and getting away from the stuff posted online, will free the User to Export, Tweak, etc, etc, etc.
Regardless of what the needs are, many export formats are available/typical.
Here's an export list from FreeCAD...
Screen Shot 2020-04-28 at 9.44.01 AM.png
3D Print Parts

Posts: 447
Joined: Thu Oct 06, 2016 5:13 pm

Re: reduce resolution

Tue Apr 28, 2020 5:50 pm

I am certainly not saying STL is a good format. Even if one does one will change ones mind first time one need to do dual material print, or dual color print... Just saying MESH modeling is far from gone, and will never be gone. It's just convenient for many use cases. While you can embed a lot of other useful info in the MESH format (3mf, amf, obj, ply...) it is still a mesh.

What I'm saying is that G-Code is not flawed. You need to "finalize" the movement of the axes somehow whatever magic you do before it, the nozzle will still need to be heated and temperature measured, maybe you will add a pressure sensor in the nozzle and control extruder by constant pressure and not by mm3 of extruder material, you still need to move the axes, 2, 3, 5, 55 axes irrelevant .. and for that it is totally irrelevant if you will use gcode or some other intermediary format between slicer and the actual motors... everything machine can physically do can be done trough g-code, it's up to slicer to write the proper one.

Now how the slicer will do it
- by guessing the features of our object from incomplete input we are providing, as is today
- by using the file format that allows us to embed this data properly, as will someday maybe be

is irrelevant, it still goes down to moving motors, heating heaters, reading sensors .. and g-code is more than adequate to execute that.

What is not adequate is the firmware executing that g-code, ignoring the bugs, so many things are not working as we'd like (pressure of the filament for start and the approximation and hacks trough linear advance, pressure advance .. oozing .. ringing ..) but that's again not the lacking of the g-code ..

You may want to be in the "I do not want to see intermediate files ever, I don't care", so like on 2D printers you don't care how EPS or PCL or whatever file sent to printer actually looks like, you click print and you get the paper out and you could not care less who created the EPS/PCL/Whatever nor how printer rendered that EPS/PCL/Whatever, but even in the world of 2D printers, if you dig just a little bit deeper that genpop you know that you want EPS or you want PCL and you want your printer to have more ram in order to xyz and to be able to interpret X 'cause Y etc etc ..
gcodestat integrates with Simplify3D and allow you to
Calculate print time accurately (acceleration, max speed, junction deviation all taken into consideration)
Embed M117 codes into G-Code
Upload your G-Code directly to Octoprint
open source and unlicence

Return to “Feature Requests”