Retro-Printer Module
retroprinter.com
retroprinter.com
It was for medical washing machines that are used to clean/sterilize endoscopes. After each run, the machine would print a report containing temperatures, etc, that would have to be analyzed by the medical staff to assess if the endoscopes were safe to use on patients.
I designed and build an interface board for LPT to an ARM SBC (Raspberry Pi didn't exist yet, IIRC). And wrote some C code that would convert the line levels to characters, and output it to a TCP connection. On the other end of the connection there was a server which would store and parse the output of the washing machine. This allowed us to develop a simple green/red indicator via a web interface, so all staff could see it, without having to physically get the piece of paper that would have been printed.
Pretty neat experience as a first-ever project for an employer. And even getting paid for it! I just checked the website of the company I build that interface for, and they still sell it! :-)
All in all, I'd guess that it took less than 1 week (40 hours) to develop.
If there was one, everybody in the planet would buy and recommend that one, over the tyranny which are proprietary printers.
RMS started GNU over a fight with a printer, and we STILL haven't progressed.
(The same with a lot of hardware: lots of people say having an open version is very important ... until it comes to making any compromise when actually buying one)
Home printing is mostly driven by:
- children asking for coloring pages to their parents
- quickly copying/printing documents for admin stuff
Both do not need color.
Any time a professionnal and colored output is needed, most people turn to professionnal copy/printing services.
It doesn't have to be cheap. It needs to be durable and easy to repair (e.g. by being modular, and largely 3d-printable).
It needs to use standards (IPP, postscript and so on) and thus not require specialized drivers.
It needs to be able to run on cheap and easy to refill/replace cartridges, be it ink or toner. Hell, I'd even take ink tape and dot pin. Just no DRM bullshit to deal with.
You made me imagine a pan-Unicode daisywheel set the size of a bookshelf, and a printer that swaps them while printing, like a CNC machine.
If only one had enough time and money...
https://hips.hearstapps.com/pop.h-cdn.co/assets/16/19/146289...
Another issue is that printers are bulky, which means either a lot of very expensive plastic modeling tooling or a lot of equally expensive, questionably accurate and time-consuming 3D prints for the frame, and they are high-precision machines with very VERY low tolerances, further complicating manufacture.
There are only so few but so large printer manufacturers because designing a printer is a lot of upfront work that can only be recouped by sheer mass of sold units.
But those things were beasts and ate power accordingly. When mine warmed up you could almost hear the local nuclear plant groan.
Many inkjets use combination cartridge-printheads and you can buy ink cartridges freely (even if they're overpriced.) https://spritesmods.com/?art=inker&page=2
I'm fine with open firmware, since it can be adapted to whatever existing hardware is available.
The cheap printers are "good enough" now -- there are plenty of brands which do not care about reported ink/toner levels, nor about whether the cartridges are genuine or not. Get one of those, and it is good enough for you home. (As for RMS's specific problem with printers -- "report paper jam status" -- this has been solved long time ago). So what would be your motivation on new firmware for the home printers?
As for large office models, those are definitely more complex and their firmware could be buggy and could use a fix or two. But there are so many models, and each one is so expensive, it is simply unlikely to get enough users to develop an open source firmware. And even if we get open firmware for one of those, how many users will it get?
But back then it took serious effort to find it, a needle in a stack of cursed printers.
And, today, I couldn't get the same printer anymore, as it was a Samsung, and their printer division ended up being sold to HP, which is infamous for nasty practices with printers and DRM.
https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/lpt...
https://www-user.tu-chemnitz.de/~heha/basteln/PC/LptCap/inde...
We felt it was better to have a HAT which sat on a Raspberry Pi (or other SBC), so we can offer an all in one solution which is portable, rather than sending the data to another PC via USB.
Ideal for extending the working life of older equipment, particularly where the existing printer is no long made, or there is a need to move to electronic paperwork.
We're almost starting to reach a point where Pi is being decoupled from Raspberry, in much the same way PC was decoupled from IBM. We don't need to lose the Pi ecosystem just because the RPF won't sell us theirs.
Also, as said by previous answer, many alternatives have the same gpio.
We managed to secure a bulk supply of Pi 3B+, so that suits our market.
Yes, these are older boards (4+ years), so maybe this has changed recently, I don't know
So for something that is facing the Internet I would be very reluctant to use them. For something internal, they're probably fine though
That said, I'm quite sure there could be a small market for products like this, especially if it could come with professional support. Good luck!
Some things use very precisely timed signals, as short as a few microseconds, and that simply can't be recreated by software over USB without hardware support.
Edit: s/port/printing/
Devices that do that often have very tight timing requirements - since original 1990's era computers could respond to a change in a pin change in as little as a few clock cycles.
CNCs with MachCNC software and lots of old industrial equipment operated this way since it saved money on custom PCB designs. BART [1] still buys older motherboards with parallel ports wired to the south bridge because USB adaptors can’t guarantee timing and swapping to a PCIe card would require rewriting some old stuff.
However it has to be done at the driver level, it wasn’t Postscript or GCode or something like that, so I doubt this piece of gear will be anywhere as useful as parallel ports used to be.
What you're describing sounds more relevant for something that's adding a parallel port to a modern computer?
It was quite a bit later in the history of the printer, when equipment started to expect 2-way communication with printers - obtaining information about the model, ink levels, paper status etc - generally that type of equipment had printer drivers for each model of printer.
We would have liked to implement something along those lines, but there is very little information (if any) about the status messages passed from the printer back to the equipment (it is not covered in the ESC/P2 documentation for example as that was last updated in 1990).