The printout may be dead but that beast of a print queue lives on Just like an owner of a new puppy waking up to a scene of destruction, 3D printer users who leave long jobs running overnight may be appalled to see what they find in the morning. In some cases, your printer might even create a phantom model without being instructed, print on top of another model sitting in the in-tray, or …
> What's striking is how many of the fixes were either technically possible but not implemented, or implemented and disabled by default.
Wait until you hear about the cheap Chinese printers that deliberately removed the temperature safety code from the Marlin firmware. No idea why. It's something you have spend a lot of effort doing, as the firmware comes with all the safety code enabled, and a lot of it you can't disable just by setting a #define. You have to actually find and delete the code.
Quite a few of them caught fire. Google for "anet a8 fire"
Marlin monitors the hotend, heatbreak, and bed temperatures. Not only does it check limits, but it checks for a sudden rise in temperature. It also checks for stalled motors. Plus if the printer has been heating without actually printing for a period of time, it will shut off.
> The most telling fix is that the company will enhance LAN-only mode, where printers use local data, so that it will work if the cloud services are down
My Prusa MK4 is perfectly happy not connected to the cloud. It has a local connection where I can upload my gcode, select a file to print, and monitor progress and temperatures, all in a local web page hosted on the printer itself.
> But a 3D printer that tries to print a new job before the old one has been cleared off the plate?
Before I print something, I have to confirm that the bed is cleaned and clear.
> mandated standard documentation is a known and powerful regulatory tool.
Prusa uses the open-source Marlin firmware. All the standard gcode verbs are copiously documented at https://marlinfw.org/meta/gcode/ and Prusa's extensions at https://prusa3d.github.io/Prusa-Firmware-Doc/group__GCodes.html
Gcode itself is an open standard, going back to MIT in the '50s and standardized in the early '60s. It is mostly used for CNC machining, but the moves in a 3D printer are the same, so it fits well there too.
> Yet if you look at 3D printers not as sophisticated, precise robots, but as machines that have to control a mass of motors, heaters, and complex materials, the picture changes. They have incredibly powerful control code to translate model data to final output.
Wait a minute. Is that not the very definition of a "sophisticated, precise robot"? My printer is repeatably accurate to a few hundredths of a millimeter. The model I'm printing now is 736,966 lines of gcode, which translates to about 530,000 physical moves over a 13 hour period.
> Or we could buy cheap and shiny products and hope for the best.
Did I already say "don't buy cheap/proprietary shit"?
Bambu is already known to be an open-source-hostile closed proprietary company.
I bought an A8 not long after they came out and recommended it to a somewhat less technical friend, only after that did I discover the issue with the mangled marlin. I did do the right thing and helped him upgrade it.
But the idea of a print queue for 3d printer?? That is a BIG bucket of NOPE!
They all have temp sensors. The "thermal runaway protection" is removed for legalities in China. A lot of the certifications in China are rubber stamped but some Chinese manufacturers are still not brazen enough to take liability for a feature that is to "protect" the user, even if rubber stamped. Honestly, in this modern world, I'm surprised any company does, but many do.
Doesn't matter. Try starting a fire with a 3D printer that grows out of control, it's damn near impossible with modern printers.
"A lot of the certifications in China are rubber stamped
Almost all it seems. Having equipped a machine shop with Chinese tools (because they're affordable on small budgets) I didn't find a single "inspection report" that wasn't just a blurry photocopy, and the figures were identical in a replacement manual obtained for one machine a couple of years down the line. I guess they're reports of 'virtual inspection'. This correlates with a report a couple of years back that in one factory keyboards were being tested by swiping a finger once diagonally across the keys.
As if Prusa is any better... Selling a product based on features it doesn't have, that's the Prusa MK4 for you. That should be illegal. Also, it's 2023, put the bed slingers to bed.
I build all of my printers but the Bambu is the best pre-built 3d printer you can buy. That said, for the cost of the Carbon X1 you can have a much nicer DiY printer, but probably not if it's your first printer, well not unless it's a Voron or some other guide based setup.
As a fundamental engineering principle (and courtesy of Murphy), hazardous processes need to be supervised because one day they'll do something unexpected. I designed an educational laboratory instrumentation controller, much of such gear being controlled over TCP/IP. One of the first requirements of its specification was that it could communicate only over a local network with a single network address (no routing capability) so that unsupervised experiments would be discouraged. However quite a lot of comparable but more 'sophisticated' applications not only allow but actively promote remote (out of sight) control, despite misconfiguration or systems failure potentially causing fires, electrocuting folks or blowing up expensive kit.
Health and safety seem to be less important than convenience, but this is not a new phenomenon. Indeed in the decade or so I spent automating academic research (many moons ago) I frequently got quite unpopular by insisting that systems were built to be safe and tested to prove it.
About the first thing I investigate with new gear is failure modes, like what happens if it loses its LAN connection.
In the case of the printers, there is no way on Earth I'll ever buy a printer that needs a cloudy service to work. *WAY* too many things that can go wrong there.
At a demonstration of some kit the vendor asked about wifi access to looks of amazement. He was told there isn’t any he can use (a lie), but why does it need wifi when it has a physical link to the control device i.e. the computer.
“Oh well the computer isn’t connected to the internet.”
“No it’s the test rig we don’t connect it to any network. Why would that be a problem?”
“It can’t continue without connecting to our webserver.”
“Is this a security thing to check it’s genuine kit or that there’s been no tampering?”
“Nope it allows use of the cloud for……”
At this point the big tech boss walks away talking to the finance director. They come back and thank the rep for his time but there was no mention of ‘internet required’ on the website. It did say a network connection was required (we assumed LAN) but not internet. As we’re not looking for something that communicates externally. “Someone will show you out!”
One of the problems with 3D printers is the long print jobs. For me, a typical print is 6-8 hours, and my current record is just over 23 hours.
Ain't no way you're gonna be sitting there watching it that whole time.
So yes, I do worry when I go to sleep or head out for dinner with the printer running. Not so much over a fire, but over the print coming loose from the bed and banging around, or a "globification" where the plastic decides to coalesce around the hotend in an extruder-destroying blob, or a "spaghettification" where it ends up printing in mid-air, resulting in a mass of plastic string. None of these has happened to me yet, but I've seen pictures on the innernetz.
There was a "what if 3D printing was 100x faster" TED talk. I'd settle for 10x faster, but I also realize it forces me to spend extra time on my OpenSCAD scripts and measure half a dozen times, kind of like the old times when you had to queue up to submit your card deck and then wander by occasionally to see if your printout was in your tray, or when a build took several hours.
We had a prusa at my last job and one of the guy would bring in his own filament and print stuff to go with his warhammer collection. One morning he comes over with a sheepish look and asks if I can have a look at the printer. The hotend, heatbreak and half the heatsink is all encased in a blob of yellow PLA about the size of a large plum and it is SOLID! Ended up ordering a new hotend as we could not get the wiring out of the blob without breaking.
Is this just another part of the gneral "enshittification" of IT?
Removing, or not bothering to include, stuff that the customers actually need, cutting corners, just to discretely hive a few pence/cents off the costs of providing the product
It's just another example of the prioritisation of venture capital over engineering. Get to market first rather than build a solid product that will then gain a reputation for reliability. Whether it's hardware, software or online services, being late is seen as a worse outcome than being a shoddy disaster.
This is all standard history for technology. The problem is that the mechanism whereby the cheap and nasty fails and the solid, reliable product eventually wins seems to have been broken by a universal obsession with continual change and novelty to try and stay ahead of the game, and a resigned acceptance of the resulting unreliability by customers
This is why I even design beta tests as solid and capable as the final product. Yes, it costs more, but the reason they get me involved is because I deliver stuff that works and I don't do shortcuts.
Heck, in one of the bigger things I built I had to fight to even get a service window when it was still in beta, and it ran pretty much unmodified for 15 years thereafter other than adding capacity here and there to cope with growth.
And it's still working.
... like so many modern devices, relied on Bambu cloud services. And Bambu's cloud services had apparently gone haywire.
Cloud services you say?
Gone haywire?
No!!!
Incredible. 8^O !!!
"A cloud is nothing but a mass of water drops or ice crystals suspended in the atmosphere.
Clouds form when water condenses in the sky.
But it is a two way process: condensation <=> evaporation.
Condensation lets us see the water vapor and evaporation makes it dissapear."
Get the gist?
Wouldn't be caught dead relying on a cloud based anything.
.
Print queues go back way beyond PCs. They go back to mainframe line printers and those were terrifying machines when you consider what could and sometimes did go wrong. But like all queues they're necessary to match progress through some fixed speed process and the arbitrary creating of work for it. But the old mainframe printer would have had a human in attendance as part of a larger job - mounting and unmounting tapes, running punched card stacks and so on. Its queue would be fed by batch jobs so duplicate submissions would be unlikely unless the operator had determined a print job was irretrievably lost. If a shared printer/print queue combination is giving rise to multiple job submissions it isn't the fault of the print queue, it's the fault of the users, lack of their training or general organisation which assumes looking after the printer is everybody's job. It's a well established principle that if something is everybody's job it ends up as nobody's job.
None of which is relevant to the stupidity of relying on somebody else's computer when it's not necessary of of leaving a potentially hazardous machine to its own devices howwever inconvenient that might be.
How many helpdesk calls involve getting the toner hoover out to clean up after an ill-advised yank of the wrong part of the innards of a laser printer?
In a former job that I left in 2003, the little office I used to run helpdesk for with maybe 200 users and 20-odd chonky HP LaserJets I would deliberately make a sweep of the office in the morning to clear out any printers in need of a change.
In current experience, lucky to have a field engineer on site let alone someone sweep the floors pre-emptively.
I cannot, for one moment, imagine any possible user benefit to holding details of what to print on your printer on a remote machine that might be in a different country.
This isn't a print queue. This isn't even remotely similar. A standalone computer in another room connected to the printer? That's a print queue machine.
All this cloud crap? It's a massive data grab, primarily because everybody accepts it being that way.
It doesn't have to be.
It shouldn't be.
We don't need regulation, we need more discerning customers who'll say "cloud? nope".
What? You mean some 3D printers *don't* have SD slots to let them work without a PC permanently attached? (Probably ought to add a /s here but wish it wasn't needed).
That is definitely a sign of things going backwards, as it is *simpler* to run an SD off a simple MCU, like an AVR (which is all you really need[1]) to drive the printer than it is to have USB (for serial over USB or storage).
You shouldn't ever need to have a full-fat PC involved for 3D printing, once the model has been copied across (over the LAN if you don't like removable media - via USB just seems stoopid, having to carry one or the other close enough evey time).
[1] yes, you can add features like cameras, which can be useful for a quick check from the living room, but do that with a R'Pi (model 3 is overkill), still no need for your PC to be used.
Why the headline mention of "regulation"?
> Regulation only happens after something goes badly wrong, and a few messed-up 3D prints and broken printers is nowhere near wrong enough.
The only examples that the article prattles on about are printer queues (and, as has already been pointed out, can't be bothered to do basic research about how old they are) and the recent stupidity with Bambu.
Oh, look, the Bambu thing - that storm in a tea cup that mostly generated Register comments about how stupid the idea was and how they would never, ever, use a cloud-connected printer. That was it. Nothing much else happened. Prints were trashed, filament wasted, that was the end of it. No doubt someone will try to big it up by making a class action law suit, but those are a dime a dozen, where they are actually even a thing. But not to worry, bring it up again and see if we can't stoke up the same level of ire, ridicule and general "engagement" from the commentards on your piece.
Even better, start the article but by bemoaning a lack of regulation.
For what? Got any actual realistic examples where that would be useful, let alone necessary?
For life-threatening scenarios? Pretty sure you will find a lot of regs already in place where there are potential threats to life or limb.
For queues that go wrong? Or even, shock, queues on "cloud" computers that go wrong?
Oh noes, only today I found that I had a bunch of duplicate emails because a queue in a cloud computer had gone wrong (and don't try to weasel out and day email servers are not in the cloud!). The horror. I demand regulation to prevent this happening again!
There possibly are some cases where regulation may be important - but if you are going to write a Register article about it, at least *try* to come up with some viable examples - or have the intellectual honesty to day that you can't.
Just riffing - badly - on printer queues and *one* recent article barely counts as a thought had on the loo, let alone a well thought out and articulated "opinion'.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
