Add weight/cost output to gcode. On the way to #647 #3669
Conversation
lordofhyphens
added
Feature request
|
The parameters default to 0, which turns off the extra output. Cost is defined as per-kg and as such you need the material density to make it work. |
|
Congratulations, that is a thing that everybody I know eagerly awaits for in Slic3r. Little question: from the code it seems that the price is set by extruder, wouldn't it be best if it was set by filament? |
|
It is, but you assign filament to extruders. The code is grabbing all of
the filament used by each extruder.
I need a better spot to put those statistics. Right now they are being
appended to the status bar message when you do an export. I think that area
could do with a refactor anyway, as it takes a full gcode export presently
to populate the information. What I think people want is for that
information to be present in the preview tab only.
|
|
Status bar message? Why not the "Info" area? Or is that the area you are referring to? |
|
The info area is refreshed per object, not for the entire thing.
It would take a lot more work to count used filament per object.
|
|
And about rename that one to "object info" to make it more specific and a
new one below that named "job info" with total filament and cost info?
…On 16 Jan 2017 13:32, "Joseph Lenox" ***@***.***> wrote:
The info area is refreshed per object, not for the entire thing.
It would take a lot more work to count used filament per object.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3669 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJcNm1EBiU6tUsMT4nuZMA3eS3Pv0HGGks5rS42jgaJpZM4LkNAS>
.
|
|
@RafaelEstevamReis Fair point there; I really should ask a friend of mine who is good at UX to take a once-over of Slic3r's UI. |
|
I tried to make some UI changes but I have never seen PERL neither wx.
You helped me a lot by IRC (display total filament), but my free time
vanishes and I have to stop.
…On 20 Jan 2017 19:07, "Joseph Lenox" ***@***.***> wrote:
@RafaelEstevamReis <https://github.com/RafaelEstevamReis> Fair point
there; I really should ask a friend of mine who is good at UX to take a
once-over of Slic3r's UI.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3669 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJcNm6aKrp0hmRnkn9VMKEGUu7textQ4ks5rUSH6gaJpZM4LkNAS>
.
|
|
There's a box now with the sliced statistics, generated post slice. I think I have the math wrong for cost, but I'm kinda spacing out on the unit conversions. |
|
Build should show up at https://bintray.com/lordofhyphens/Slic3r/Slic3r_Branches |
|
Win32 build: https://bintray.com/lordofhyphens/Slic3r/download_file?file_path=slic3r-slice_statistics.2017.01.21.337.716806e.zip I don't know what's up with Travis. I think I have the weight calculated properly from the volume. |
|
I've done some rudimentary testing, this looks feature-complete. I'd appreciate other people giving it a whirl. |
|
I tried it, configured one filament accordingly, saved it, imported one object, no deal. Two objects, no deal. It does not seem to be populating the "Sliced Info" frame. |
|
Got it to populate the frame after saving the G-Code. I understand the reason why this is this way, but it might be confusing to users. |
|
Just to report some additional tests with material with cost defined and cost not defined: the algorithm worked as intended, in this case I set the bigger object to be "ABS_rosa_175mm" which has no cost or density defined. The Slic3r Info frame considered only the filament with density and cost to perform the calculation.
|
|
Really Nice! |
|
I just noticed that the calculations seem to be three orders of magnitude off. I used 1.24 g/mm³ for the filament (which is the actual density of PLA) but it said in the Sliced Info that the tiny smiling bishop would weight 4,5 kg. |
|
Are you sure you didn't derp and use the value in units of g/cm^3 ? I know
I did that at least once myself.
1.24g/cm^3 = 1.24x10^-3 g/mm^3.
|
|
my apologies. PLA's density is 1.24 g/cm³, not mm³. That means it is 0.00124 g/mm³. In slicers that have a field for cost I am used to input it in g/cm³, so I entered that into slic3r without even thinking about units. Now the calculation is working |
|
@forReason I don't see any value added in putting static costs into the interface, especially since it has very little practical use for most people and is yet another option to clutter the interface (and we are trying to limit those). (Aka you need to convince me) @Patola regarding the frame not populating until after gcode export, that is something I might add a tooltip to the box to cover. While I would love to have that information available on preview, I think it would require a lot of refactoring to get it. So what to do about user error in the case of mixed settings? It should be treating the weight for the part without settings as 0. |
|
Yeah, I have the unit there for that reason ;)
I have considered entering it as g/cm^3. Currently weighing the pros and
cons.
I probably will change it to avoid that particular bit of confusion, but
there is no conversion necessary if you are directly calculating from
weight/volume as the tooltip indicates.
|
|
I also don't much care for the (money) placeholder. I think that it's okay for now, but should be replaced with the correct locale symbol when we have that working correctly. |
|
@lordofhyphens You are probably right the static value is unnessesary. BUT I really would consider energy costs. by Print-time |
|
@lordofhyphens not refactoring is better then. There's things that are much more important right now, I don't think it is a great hassle to wait for the G-Code export to have this data. |
|
If I add a print time estimate, three hours later someone will complain
about it being inaccurate, no matter how much documentation I throw in for
it being wildly optimistic. And it will be. I am not going to clutter the
interface with all of the minutae required to even approximate printing
times.
That is the source of me not wanting to deal with print times: it never
works anyway and it is really complicated. Very much not worth it to me.
|
|
I've taken a cue from @bubnikv and the box now hides itself if you don't have gcode exported. It goes away if you move the model in such away that invalidates things. |
|
@alexrj I would like to merge this unless you have an objection. |
|
Tested and works so far. Two remarks / suggestions: Downside: even more clutter |
… status bar change.
… sliced statistics.
…calculation methods.
lordofhyphens
force-pushed
the
slice_statistics
branch
from
dfd7e56
to
05e9991
Compare
|
Added the filament length (which was already exposed) and ensured that the box is hidden on config change or if invalidation happens for background processing. |
|
I feel it is better to return something that is obviously wrong so the user can set the appropriate values for their filament (since density of PLA and ABS differ significantly) than provide some "default" which is generally always wrong (and basically silently wrong). |
|
Ok, lenght works now, empty defaults is fine. But I noticed 3 other issues:
|
|
Odd, on my system it re-updated as it should. Might need to call something
else explicitly.
The density unit was originally in g/mm^3 and was changed to let people
plug in values from Wikipedia (which I think is a good thing). I don't see
how this "inconsistency" is a problem, though. All of the outputs are
consistent with each other. The volume isn't *that* critical of a item
(leaving it out of the display wouldn't hurt anything).
|
…correctly on different platforms. Changed output units to cm/cm^3 Conflicts: lib/Slic3r/GUI/Plater.pm
|
The issue with the box doing weird things should be gone now, and I've changed the display units to cm and cm^3. If someone else wants it to be mm/mm^3, too bad for them. ;p |
|
Here it is after I changed a configuration option: |
|
Nice feature! Some things about it:
|
Parking PR here to get feedback, this has been asked for a couple times.
Fixes #647
Fixes #2250
#1766