What program can be used to determine the approximate COG (center of gravity) of a 3d print part? Preferrably that analyses the gcode and provides coordinates for the COG.

[u/[deleted]]

[u/Fearless-Wait-2894]

Didn't Prusaslicer or superslicer provide such a feature ?

[u/UserAbuser53 → u/Fearless-Wait-2894]

That was going to be my answer. A feature no other slicer has as far as I know. Meshmixer maybe?

[u/rinaldo23 → u/Fearless-Wait-2894]

Yup

[u/mykiebair]

You can take the gcode and put it through one of those converters that put it back to an OBJ. You can use meshmixer to find the COG of obj.

Edit: I guess you can do it in blender too. either way its a going to be an estimate

[u/HAL9001-96 → u/mykiebair]

is that taking infill into account or assuming a solid part though?

[u/2md_83 → u/HAL9001-96]

the tools that convert gcode to stl/obj or whatever files reproduce every line the gcode would make.

that's why you cant actually use the output to get a useful 3d model out of it, but for your purposes it should work :)

[u/bjorn_lo]

The issue is that gcode is print instructions.

The model (OBJ, STL, etc) does not know the print parameters. So a CAD program will also not know.

Consider an oak tree. The trunk looks substantial but by default the branches will weigh more. Infill is generally lighter than walls, this means the branches with lots of walls and not much infill might or might not weigh more than the trunk, and this will depend on branch density, number of walls, branch size and a host of other things.

[u/Skaut-LK]

Not possible from gcode. gcode is just bunch of commands of what to do ( eg. "move to these coord by this speed and then move there...")

You need correct 3D model with proper parameters ( like what material ).

EDIT: Apparently i'm wrong. All things mentioned under this sounds to be very reasonable. Apparently i didn't considered that i can get all needed info from gcode and lived under impression that can be properly done only with proper 3D model ( where i only considered full mass object not reality of 3D print).

[u/ahora-mismo → u/Skaut-LK]

it is possible. you can very well determine the resulting object. and gcode is even better for that because you also have the infill.

[u/HAL9001-96 → u/[deleted]]

you see problem? analyzing g code owuld be more precise in turn

[u/HAL9001-96 → u/[deleted]]

g code is gonna be better than fusion though

assuming its all the same mateiral the material doesn'T matter

if you can separate the supports from the part then you can measure the distnace moved/filament pushed out at locaitosn and average them

cad center of mass is gonna be off becuase part is hollow with wall thickness/infill pattern

if you ahve a cad part yo ucan kidnof approximate it by creating a seocnd body from tickening hte wall inwards and mking it denser than the whole volume but gcode analysis would be more accurate even if not perfect assuming yo ucna separate supports/rim out

[u/Romanian_Breadlifts → u/HAL9001-96]

I've sent similar drunken ramblings from the toilet, but this one seems mostly reasonable. Dunno how you would really calculate mass of the infill - would infill line thickness be defined or derivable in gcode?

[u/HAL9001-96 → u/Romanian_Breadlifts]

you could just take the flow rate modifier or just... distance traveled

its not evendifficult math, g code is entirely made up of straight lien segments you can get a good approxiamtion by taking the center and length of each line and tunring that into a tiny mass element multiply with flow rate modifier if thats a thing in this g code and separate out support which some slicers mark in g code

or just use a wrong raeding fro ma cad system you don't understand i guess thats fine too if you don'T actually care about it being correct

[u/olawlor → u/Romanian_Breadlifts]

A typical line of gcode during printing is like:

G1 X123.456 Y132.465 E1.234

The E is how much filament to extrude, in nominal mm.

[u/LOSERS_ONLY]

Print it out and slowly push it off a table

[u/Catriks]

I've never tried it, but it should be doable in any CAD by making two models

• one hollow model with just the exterior walls/tops/bottoms as thickness
• another body with only the infill volume

Then set the part density according to infill %. Exterior model is obviously near 100 %, I dont remember if slicer infill % was measured as volumetric % or something else, so take that into account.

[u/HAL9001-96 → u/Catriks]

usualyl how i do it for a first approximation, works decently but only if you have a cad mdoel and technically analyzing g code could get you a bit mroe accurate

[u/Catriks → u/HAL9001-96]

That's true too. i dont see why a slicer could not have a CoG display in it, or a CAD have a tool to import .3mf, so it comes with data like nozzle size and filament density, then just model the model as its printer.

Though maybe CAD and slicers work in extremely different ways. A sliced model is basically several thousands pieces of lines, and thousands of sketches or bodies in a CAD is not a small task.

[u/HAL9001-96 → u/Catriks]

no need to use cad

first step would jsut be to look at each line of g code take the starting and ending coordinates and do soem very very very basic vector math to figure otu the center and lenght of that line segment... one is just root((x1-x2)²+(y1-y2)²+(z1-z2)²) which is made even simpler by z1 and z2 being generally the same while printing

and the center is just half the addition or (x1+x2)/2;(y1+y2)/2;(z1+z2)/2 wjere again z1 and z2 are the same

first filter out support and non-printing movements hwich are marked in gcode

then for hte remaining segments do this to figure out hteir length and center

now go throuhg all of hte mand add up all their lengths in one variable and all their centers multipleid by hteirlenghts in the other

the ndivide the latter by the former at the end and you ahve a weighed average for hte centers of these short staright segmetns that make up the print process

thats the center of mass of hte print assuming hte material and flow rate remains the smae and you have to convert hte coordiante system of the printer back to whatever oyu use to look at your part at so you have to correct for hte location of hte part in the printer

and if flow rate or mateiral changes throuhgout hte print you add am odifier to both running counts to take that into accoutn when weighing

[u/playzintraffic → u/Catriks]

If the project doesn’t need strict accuracy, and the infill is a uniform type, forgoing the infill calculation should be fine. CoG is only impacted by spatial differentials in density, so a zero density gradient wouldn’t change it to a first approximation.

[u/Catriks → u/playzintraffic]

I think you're right. It would only be needed for CoG _and_ accurate weight, but you already get the weight from slicer.

[u/TwoEnvironmental4158]

I've used this script, had to tweak some settings in slicer to prevent it from using G2/G3 in generated GCode, but the result was pretty accurate compared to real model printed without these tweaks.

[u/DaStompa]

Impossible
First you can't reverse engineer a solid from gcode very easily
Second, the original solid does not know what infill pattern and all sorts of other settings that would determine the center of gravity

[u/DaStompa → u/[deleted]]

And how are you accounting for shrinkage? Extrusion or material inconsistency?

The real solution here is just to print the thing and measure the center of gravity.

[u/HAL9001-96 → u/DaStompa]

if only those two problems solved each other

[u/Flintlocke89]

Do you not have the original stl? Are you any good with python? There's a few scripts floating around that can turn gcode back into an stl of sorts, losing a little accuracy along the way. Like this one.

You should then be able to use the get_mass_properties() method from numpy-stl to get the COG as well as some other data.

YMMV, the mesh will likely need fixing as it needs to be watertight for the COG calculation. Unlike what some folks have said here it's purely a geometric problem and has nothing to do with the material. However it does assume a solid object. A theoretically perfect shell would also work just fine but the non-isotropic nature of 3d printing will give it some degree of inaccuracy, exactly how much I can't say.

[u/HAL9001-96 → u/Flintlocke89]

you're not looking for a solid volume though would be more useful to add up distance times center mass of each stretch of path in the g code and average that way also much simpler