scottbez1

Or color matched. Hadn’t even thought of that to be honest

It’s maybe plausible to gently wash it with the filaments still attached? I did actually use connectors so the shirt could be detached from the drive electronics, though I’d be a bit worried whether the stitches would survive and corrosion on the solder joints. Adhesive/waterproof heat shrink could maybe help?

The other option is maybe attach the filaments to an embroidery style patch instead of the shirt itself and then attach it with Velcro to the shirt?

Author here, happy to answer any questions!

Heh, I just got a waveshare RLCD to play with sunlight visible higher refresh rate, but then I compared it side by side with the exact e-paper display for this project and I felt buyer’s remorse; the contrast is soooo much worse on the LCD.

Maybe it would have fared better if I was out in sunlight viewing them, but seeing this thing in person sold me on e-paper for this use case

Gas tax has always been a proxy metric for mileage in order to implement usage based costs to help offset the many billions of dollars California spends maintaining roads every year.

Gas as a proxy for mileage breaks down with widespread EV usage, so even though they are a benefit for many reasons with incentivizing, they still require expensive road upkeep so should not be immune from usage taxation.

I think the big question here is how effective can you make training and monitoring across a widespread population in practice?

In aviation, commercial pilots have very strict and extensive training and monitoring and as a result are generally able to utilize automation effectively while keeping up their manual skills. There are very rarely CFIT incidents in major commercial airlines.

The opposite is true in general aviation (small private Cessnas, etc), where it’s extremely common for pilots to buy more plane than they can handle and then rely on automation to bridge their skill gap. CFIT is much more common in general aviation, along with incorrect actions in response to real system failures that should have been recoverable. Automation complacency regularly kills in general aviation.

A key thing to notice is that automation isn’t outright prohibited in either commercial or general aviation, but there are distinct regulatory frameworks based on potential impact.

We accept looser rules for general aviation because the failures are societally less severe and because the population is much larger so effective training and enforcement would be significantly harder. In commercial airliners where failures are catastrophic, we have much stricter policies and require training and testing regularly to avoid automation complacency.

Will we start to see this practice in software? Probably, but only if/when the societal cost of NOT doing it becomes more clear. We regulated aviation because crashing planes are obviously bad. We license structural engineers because collapsing bridges are obviously bad. Will automation-induced software failures hit a similar tipping point?

More strictly than firearms, in fact.

Some of the proposed 3d printer laws will require printers being sold to be capable of evaluating what you are using them for and blocking “bad” usages. I’m not aware of any such legislation around firearms.

You are conflating two things: appeasement and actual change in principles. Externally it can be hard to distinguish these, but it is easier to get a sense of it with more signals.

From Bambu’s historical and continued actions, specifically including the orca slicer actions that this blog post was about, there is additional signal that LAN mode backpedaling was more likely an appeasement action than a shift in principles to embrace a more open ecosystem.

What you’ve said is true but also misses the point. Licenses have never been about stopping bad actions because a bit of text can’t prevent someone from buying materials and building things, just like a speed limit sign has never stopped someone from speeding (unless they crash into it).

They ARE however deterrents to bad actions from less-than-scrupulous entities, and enforcement mechanisms against fully-unscrupulous entities.

I suspect (but will admit I am just guessing here) that Prusa would prefer not to get to the enforcement stage because it is both costly and annoying, but having that in your back pocket is, sadly, necessary in a litigious society with some number of unscrupulous actors, and the deterrent effect alone is likely enough to achieve most of their goals.

It’s rough but I understand it.

You can be entirely in favor of the open source ethos, even as a commercial entity, but then certain actors can take advantage of that ethos and just directly commercialize your R&D investment and take all the proceeds of your investment, whether or not they comply with attribution or share-alike requirements.

It’s tough seeing an open source project you’ve poured tons of care and effort into (and WANT people to share and remix and build cool things) get more or less “extracted” for profit without contributing back (code or money).

At the end of the day, none of it really matters unless you’ve got money and time to actually try to enforce your licenses, or have enough customer mindshare to effectively change the behavior of bad actors without needing legal action.

I’ll probably use licenses like Prusas in the future for similar reasons, even though I generally prefer to use less restrictive ones. Bad actors, or even just non-benevolent actors, can really sour the open source ethos, and it sucks but there’s no way to legally enforce “don’t be a jerk” without restricting a legal document in slightly unpalatable ways.

Correction is one of many signals, and it’s better than ignoring pushback, but it’s still usually worse than not needing the correction in the first place.

Sure, a manufacturer that didn’t need to course correct yet doesn’t mean they won’t change their stance in the future, but the same is true for one that already course-corrected.

We see this with privacy eroding laws continually - legislators will “listen” and course correct if there’s pushback, only to reintroduce the bill in the next legislative session, repeatedly, until it gets passed.

I’d prefer the one that hasn’t yet signaled a desire to do something negative in the past to one that has, even if they walked it back later.

I have the original CC. It’s a fine budget machine for single color - plenty fast and good quality prints.

They rubbed people the wrong way launching the CC2 with multi-color support before they developed the multi-color add-on that was promised for the original CC. I didn’t plan on multi-color with the CC, so that didn’t personally bother me too much.

I recently got a Snapmaker U1 for multi-toolhead prints and love it so far - much less waste than a filament changer and I’m using it for more exotic prints like a mix of conductive and regular PLA in a single part that wouldn’t work well in a filament changer single toolhead printer.

And I still use my CC for occasional single color prints (recently it’s been dedicated to TPU but I’m probably going to move that over to the U1 so I can do “over molded” TPU+PLA prints).

In short, if you’re willing to spend more I’d highly recommend the U1 if you know you’d benefit from the toolchanger. CC is probably a fine budget machine but there are a lot of other similar budget corexy machines to consider these days as well (I got CC when it was groundbreaking for features at its price but competition has caught up by now).