Slic3r: Volume has no units

[TTN-]

What are the units on the plater tab for volume? Size is in mm presumably?

[alranel]

STL files and G-code have no units as well. So the volume is expressed in units^3, whatever the model units are (usually millimeters).

[NeonHorizon]

G-Code may not have the units specified but the model shown on the screen is absolutely of a known size since it has to be sliced for a nozzle diameter in mm and to a layer height in mm and to a speed in mm per second. ...and unless I missed something; although the software doesn't state that the bed dimensions are in mm, they have to be otherwise the nozzle and layer heights will all be wrong?

Combine this with a brief bit of testing and we can also see that the value shown on the tab is directly related to the model displayed on screen (you can prove this by re-scaling the model, cutting it, etc). That means we can pretty much say for definite that the volume displayed on that tab is in mm squared.

Sure if we load a gcode model which is say a 1" cube and the units are in inches in the gcode it will say 1 as the volume and you could say "well thats wrong as it should be 1 inch". But is it actually wrong? The model in the scale displayed on the screen and the scale you will be printing at will only be 1mm squared not 1" squared so its correct.

[mrvn]

My nozzel has a size of 0.3 potatoes and all my STL files are designed in potatoes too. Slic3r correctly shows the model in units of potatoes when I load it and slices it and everything works out fine. But I think in the GUI it says "mm" in some places where it should be saying "potatoes". Unfortunate side effect of nearly everyone using mm for their setup.

Note: while potatoes are a silly unit you might have a machine that works in inch by default. There is a G-code to switch between metric and imperial unit for systems aimed at global markets. But if you have firmware that only works with inch then you input all parameters in inch, inch/s, inch/s² and it will work out fine. Slic3r doesn't care what the unit for length is as long as all values use the same.

[NeonHorizon]

Yeah but the fact is the GUI definitely does say mm, so the horse has already bolted. We need to finish the job off and add mm2 on the volume, at the moment its inconsistent and confusing.

As for machines using inches, at the moment those users will be even more confused as it asks for the nozzle in mm and if they actually enter it in mm their prints will be massively under extruded.

One of two things need to happen here;

we either need to stop kidding ourselves that slic3r is unit independent and just write mm everywhere and have a note during the install for the very few people who want to use inches or metres, they can do so but they have to use inches/metres absolutely everywhere.

...or we need to have an option in the setup wizard to select the unit and display that unit everywhere.

At the moment we have the crazy situation that slic3r doesn't consistently display units for users who use mm and doesn't work at all for people that use inches.

[stanier]

@mrvn you really shouldn't use such esoteric units of measurement when talking about precision instruments. Instead, consider using a more standardized unit, like chicken feet. And you really don't need that big of a nozzle either. A 0.03 imperial chicken feet nozzle will do you fine.

Side note: For all of those confused about the standard base of a chicken foot, it's roughly 0.14 Pinocchio Noses. Would be really helpful if they added that conversion in the editor, considering the lack of millimeters.

[mrvn]

@NeonHorizon +1 for making it consistent

[TTN-]

Bottom line is, units are not specified, its confusing. Perhaps its good to have a 'machine units: mm/inch/chicken feet' parameter which will place unit_string behind volume numbers and others. Now I realize this is a personal project that has just one very talented programmer and features are not simply made to order.

My original question has been answered which is great. :-)