Don’t worry, your choice of words was absolutely fine
I agree that any solution is a good one at this point but what I mean is going forward I’d like us to find the right solution. Any solution would be good to get us there, but we should be careful to try and avoid reliance and lock-in now that we’ve seen how it can go bad.
That would be my perfect solution and one I definitely want to persue
It would be great to have some form of web applet to compute in real time the volume, the infill and the support material of the file, convert that to price and then this company would basically intermediate the payment between the customer and the 3D printing service.
1 Like
Interesting.
I utterly agree with you about the STL volume/infill/material/price calculation stuff and unfortunately I think getting something like that right and reliable is going to be the most challenging part.
In terms of payment though, my thoughts are that each hub (we need another name, but you know what I mean) would do their own. I.e. I could have my ‘hub’ site process payments through Paypal or Stripe or whatever. Then they could have their own processes etc and handle their own business and not have any weird rules about VAT or whether you’ve got the right kind of company…
Maybe we need both options, with it up to each hub to choose if they handle their own payments or if the central authority does it, or if they’re happy to handle either case. Customers could use that as part of their decision as to who to choose if they feel strongly one way or another.
Yeah, this is a really good idea!
Or if 3D Hubs bequeathed a solution to us as suggested on Twitter . Frankly I think it’s unlikely but I’d happily take a version of their algorithm from a couple of years back gifted to the open source community. It would take the sting out a bit for sure.
Does it actually have to slice? I mean the 3dhubs one doesn’t. Or at least doesn’t allow for producing gcode. I suppose it has to slice somewhat to calculate price tho. But it would only need to be very simple(or perhaps go all the way with it, to make your offering that much better).
Well, Speed would depend on quite a lot of variables. I don’t think that would be accurate unless the ‘hub’ can input their print speeds, acceleration etc.
Also, I think the current model of cost per volume of plastic isn’t ideal. It doesn’t take into account time spent printing etc.
If there was someway to maybe make octoprint plugin that keeps track of time of a print, then connect that to user account/hub. Then could charge by time spent on the print, and not just volume.
I think letting the hubs input time spent could lead to dishonesty. And customers may not trust that either. I think if there was some sort of time tracking tool it would be much better, and more accurate. Also would allow for gathering actual data that could in turn be used for something.
Well. I was thinking maybe you have the slicer calculate volume, and make a charge based on that. And let customers know that there will be additional charge at the end for time. And that once they put in their CC, they will be charged time at the end. And maybe give some sort of estimate.
Then only allow customers to dispute, or request refund for part. But they agreed to pay a rate for time at the beginning and are given an estimate then to. Just like any sort of hourly contact work.
Hi
calculating volume would work (calculate volume and estimate it to be with infill of 30% example or 40%) it would be doable I believe. (oh and this volume slicing can be done with python at least)
cobnut
September 12, 2018, 4:28pm
54
Folks, at the risk of being shouted down, I do think that if you continue to use this thread to only discuss your own plans for building another platform, 3DHubs would be within their rights to delete/lock it. Given that the thread was provided specifically to talk about the 3DHubs change after complaints of threads being deleted, it’d be kinda silly to get it restricted because of your own actions.
Personally, if you are thinking of building your own Hub, then this thread would be a useful place to talk about/consider why 3DHubs are making these changes. Putting aside accusations, it’s entirely possible that what 3DHubs have learned from trying to operate as a local/small Hub provision service could be very important learning if you’re thinking of starting down that route.
I wonder what would happen if a friend made several orders to you this month that you responded instantly and filled them. That could get you to the qualifying scores.
I am convinced there are Hubs that did just this thing in the past to get their numbers up with easy prints and low balled rates. Just saying this IMHO. I think the response time grade was silly. Some small businesses and even large ones do not respond to orders at night and on weekends.
I just think it is a strange and unfair way to close a service for people that have a 26min response time and let hubs with a 25min response time the possibility to continue the hub. For the customer it is no difference and a hub with a slightly longer response time might be much more popular and successful than a hub with a short response time
Totally agree. Their metrics made no sense to me. I was annoyed by the poor communications from the company.
I thought they were already pretty greedy with the fee structure. 1.7 million parts in 5 years doesn’t seem like much to me.
And you were an ambassador and they still cut you out?
Not one of the customers I had cared at all about response times.
My guess is they have the Netfabb engine integrated into their system.
cobnut
September 12, 2018, 5:30pm
60
To be fair, if you manage when your hub is online, 25 minutes is a really easy target. Mine is currently 6 minutes & I think the worst it’s been is 11 minutes
Just turn your hub of when you know you can’t respond. Ok, you might miss some potential orders, but if you’re not able to respond, you’re eating into your production time as well.
I’ve actually had quite a few “urgent” orders where the customer has said response time was a factor in their choice of hub.
