Hello there,
It would be super handy if the cost value of Bambu filaments could be pulled via an api, so that region specific pricing is used, for example, I’d like the cost to automatically be the AUD price of the filaments, so that I could see a more accurate estimate in the estimated cost of a print
I think this is exactly what @MichaelR0 is suggesting, that the cost is retrieved automatically instead of entering the price manually…
I do not see how automatic price entry could account for all users preferences and pricing variables and still provide accurate data.
Actual purchase price, replacement price, temporary sale price, single spool price, bulk purchase price, refill price, complete spool price, shipping, sales tax…
By the time all options are accounted for, it would be easier to just continue entering the price manually.
And is that price for what it is today or for what you paid for it last month? Would it keep the price that you paid, or update it? What if you have two spools purchased at different prices? So many variations.
I sort of had the same idea. If you added the cost you paid for each filament, you could slice based on performance, cheapest or convenience. With cheapest it would use the cheapest for infill, supports etc.
You could do all of this yourself, but some sort of intelligence along these lines makes sense.
Once the cheapest ran out, goes to the next cheapest…
Basically to answer other questions here, yes, I’m suggesting live pricing updates, sure you can’t account for sales, bundles etc and in those cases manual pricing is the way, but if it was a toggled option, I think that would be acceptable, live/dynamic pricing for what it would cost right now for a single spool, or manual pricing for when you want to enter the price that you paid
I love APIs, I need to get that out of the way.
I have designed them, written them, used other people’s, they are great.
The problem here is the source of the data.
Given you are asking for an accurate value as you have stated the manual entry for guesstimates is unsuitable, how do you gain that information.
An example.
I buy 4 rolls of filament made by eSun and sold by Amazon for £32 (as it was the other day). I print with that filament, but today the same filament is £42, which value does it choose?
How does it know I bought from Amazon, which seller and which deal at which time? Did it know I bought it in a four pack?
Now say I buy another spool, same filament in every way, this time as a single and that cost me £14.
How does it know I am using that one or one of the two sets of four I had previously?
Let’s assume I am using Bambu Lab filament p, easier, right?
Nope.
Did I buy it as a single or as part of a 4+ or 6+ or other price reduction?
Did I get it as a result of a gift card making it free or partially free?
Too many factors.
Keep in mind, the spools are not uniquely identifiable in anyway.
No need for complicated logic, current price from bambu store
To quote myself, there are still far too many factors.
I know we haven’t introduced the cost of electricity, imagine how that would make things easier, I mean harder.
Yeah third party is a problem, which is why I only said “Bambu filaments”, for which Bambu could get the data from their own sites.
For simplicity sake, the live price feature would be single spool, full cost.
Where the option is via a toggle, otherwise for all other cases manual pricing is the way to go
I accounted for both as I like to add details for the author and readers.
If we use the current price, which one, the with spool or refill?
In the U.K. the current price is £18 for a refill or £21 for with a spool. As stocks are usually very fluctuating in availability across the board, today I could have bought a refill in white and print tomorrow with it only available with a spool, a deviation of £4.
So, for accuracy sack, I could be £18 or £21 if we discount all the potential discounts available which is when most order them and no accounting for gift cards which people do whenever they can.
Yet your question had this as a requirement.
You can’t have both, you can be accurate while not being accurate.
I have been lucky enough to earn sufficient points to purchase filament at no cost. This makes the accuracy exactly 100% out.
Granted I could opt out, but then for me, the energy cost is the thing I want as it is the only cost of printing when using BL filaments.
My point is, you can’t require accuracy and ignore all the factors.
The most accurate answer for you would be to manually type and average purchase price you manually add to a spreadsheet each time you purchase.
Just a list of each filament purchased with a quantity and price per unit in each row and a rolling average of all rows counted divided by the sum of those row totals.
You enter that average cost in the box as that is your most accurate estimate.
Not ideal, unless you love spreadsheets, but the most accurate way of getting filament.
I’ll admit my phrasing hasn’t been ideal.
When I said “more accurate estimate”, what I mean is that because I can only assume the price is in USD and I’m in the land of dollarydoos, which makes the estimate wildly wrong.
I’m not looking for 100% accuracy and neither should anyone else via such an automated method, I’m just suggesting that there be an option to have the price to be somewhat reflective of what it might actually cost for the material in a specific region, even if its out by a few dollars on a full spool, its still way better than it thinking that for me a Bambu Basic PLA is $24.99 USD, when its actually more like $35.99 AUD (for a complete spool). As it stands, yes I can update the price manually, but that requires making a new filament preset for every option and if it is only the price I’m updating, id rather not need a new preset (so that I could continue to get any parameter changes that Bambu might make to their presets in future), I also don’t have an AMS so I don’t know how that works, but wouldn’t the RFID identification override a selection of custom filament preset and thus revert the price back to USD?
You can type 35.99 into the box.
There are no currency signs (at least for me).
This shows 24.99 (wrong, but I do not use it). No currency sign.
No currency sign.
No currency sign.
Even if there were currency signs, both USD and AUD use the $ symbol.
It would be more annoying for me as we use the £ symbol.
Yep, I have created presets for the pricing here.
However, I assume this now means that any improvements or corrections to the base preset in Bambu Studio “PLA Basic” for example, will not update my custom preset, which had I made other changes to, I’d be okay with, but because I have only created the preset to enter a more localized price, then I’d be happy for Bambu to push future updates to the other parameters of the preset.
What you have now is a valid feature request as you have (wittingly or unwittingly) highlighted a much bigger issue.
Assuming your point is true, I have no idea, that would need testing, but it is likely, there should be a merge function.
Imagine a preset update comes out as you just suggested and you have your own preset created, it would be great to be able to decide which if any tweaked values are then passed into your own presets. This would be far more useful as it affects so many values.
If we focussed on your specific need, the price, the actual solution is to decouple it from the filament settings. As, it being there has inherent issues as you have potentially highlighted (assuming as we are that it is true, which I agree with).
A simple interface that knows that BL PLA is Bambu PLA irrespective of the filament profile as that is also BL PLA.
There you could set the price per kilogram of each material and whichever filament profile was being used, if it matches one in the costs feature, it is used.
This would mean you could have 20 different BL PLA filament profiles and it would not affect your price guide value as each one would reference BL PLA as the filament type.
I do not like the idea of Bambu Studio becoming burdened by unnecessary features, but this is both minor and useful to the task. It is also difficult to externalise without far more work.
A simple list of all filaments you have loaded with a box next to each one where you enter a value. The software cross references when it provides the estimate.
It is a trivial task, no external API, barely touching whatever internal DB they have and the cross reference code is a very simple lookup. It would take me less than an hour to code if this was one of my apps.
Ideally the price would be tied to the spool RFID so that each spool is tracked individually. The AMS should then calculate if you have enough filament and if a second spool is used adjust the cost.
Imagine the headache for BBL to try to set the selling price for each individual spool of filament ever made. And, the pacing does change based upon quantities etc.
Way too silly to use this level of detail.
However, it would be useful to be able to point to a specific API and use not the actual cost but a REPLACEMENT cost. This way you have an idea of the cost to replace the filament used which then becomes the real cost at the time printing.
Are you thinking each RFID tag has a unique identification beyond which unique category and colour?
That would be a very specific and extremely expensive process to write each tag.
I do nit think they did that.
If it has a unique ID, and has the type and color, then yes, it can be used to track all of that data.
My understanding, and I could be wrong, is that the RFID tag does have a unique identifier embedded in the section that cannot be copied.
