My first project ever after completing my embedded engineering degree was building an interface like this.
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.
I very much doubt it would be very popular, unless it also somehow would manage to be extremely cheap. If it's not extremely cheap, there is enough proprietary competition that also works just fine in general, and a usefully open design (i.e. one that's indeed reproducible etc) would probably be even more expensive.
(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)
The trick is that an open hardware printer would likely have much cheaper cartridges, and typically people spend much much more on the ink than the printer. So even if the printer comes out as more expensive they can price gouge less on ink and still come out as the economical choice
People that buy printers for printing a lot already optimize for that though, and thus buy printers with cheap ink/toner. And inks and their formulation are a big hurdle for a good open design: Either you pick some off-the-shelf vendor ink at whatever that costs, or you now also need to specify and enable ink production.
Most people would save money by sending they print to a nearby store and paying $.20/page. Sure in theory the printer they have at home is much cheaper, but for the amount they print vs the life of a printer in reality their printer is much more expensive. Plus they can choose color (extra cost), photo quality (much higher cost, but quality they can't get at home) when they want it.
>unless it also somehow would manage to be extremely cheap.
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.
If it's solely printing ASCII text, an open source daisy wheel printer would be mechanically easy to build. You could even make the daisy wheels swappable to allow different character sets.
Most of modern printer and scanner technology will still be under patents, and a lot of the components used (e.g. nozzles) won't be available for third parties. In contrast, e.g. in the camera industry, the situation is different - you can at least integrate commonly available sensors e.g. from Sony into your designs.
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.
The problem is that there are many kinds of printers...
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?
I use a monochrome laser. It was really cheap (<$100, over 10 years of service now).
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.
Brother probably has a similarly priced option with similar reliability (I've got an HL-2270dw that was apparently released in 2012). I likely had the same Samsung you're referring to for years and years... ultimately the rollers wore out and, well, trying to replace the rollers on a $100 printer seemed like a wasted effort.
Yes I am aware of those projects - you then need to write the software to emulate the printer itself, which interprets the control codes.
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.
Launch of a small Raspberry Pi HAT which captures data from centronics ports, and emulates an older dot matrix printer to allow for e-printing and printing on modern USB / network printers.
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.
Marvellous, but why raspberry pi? I suppose this project was started before 2021. Today there is little sense to be using them for anything new (unless you're doing it just for yourself and you already have few lying around). Basic functionality such as gpio, networking etc is well documented on rockchip based alternatives (made by pine, radxa, orange etc) I haven't played with allwinner boards, but I hear they are similar. The only thing I woukd choose rpi for today is perhaps for its hdmi/composite video out and camera interface(that too can be had on alternative boards today).
A lot of those alternatives have adopted the pi's form-factor as a loose standard, so there's a reasonable chance this is going to work on many of those alternatives.
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.
I have several other "RaspberryPi-like" SBCs. Rockchip, Pine, Orange, you name it. While all of them still work fine and some are indeed more powerful than the RPi (or have more features), my biggest complaint with them is Linux support by the manufacturer. Many of them run a custom 4.x kernel that requires vendor patches that were never upstreamed, and sometimes the Websites / Downloads for these special kernels don't even work anymore.
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
Yes, we have also tested the HAT and software on Odroid C1 and Banana Pi. The problem is that you need to have one of each SBC to compile the software and test it - some of the GPIO pins do not match the Pi scheme, so have to be remapped.
We managed to secure a bulk supply of Pi 3B+, so that suits our market.
Bear in mind that this will work for many bits of parallel port equipment, but won't work for everything.
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.
Doesn't this device work the other way around? It's pretending to be a printer, which you can connect to an old computer that expects to see a printer on its parallel port.
What you're describing sounds more relevant for something that's adding a parallel port to a modern computer?
From looking at the comments on here it seems many people are missing the point of this device and are thinking of it as something more than what it is--which is an adapter from an old device to a modern printer. It is not a general replacement for 2-way parallel port communication.
True - it is not designed for 2 way parallel port communication - it just captures the data sent to a parallel port and emulates an old printer (Epson ESC/P, ESC/P2, HP PCL, PostScript, Printronix, Tandy, IBM ProPrinter) - converting the output to PDF which can then be printed or stored.
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).
It’s synchronous but it was offloaded on to the southbridge in Intel/AMD CPUs so you could fill a ring buffer and it’d DMA everything to the peripheral without interrupting the CPU. Drivers could just leisurely fill up those ring buffers and never have to worry about kernel scheduling inhibiting hard realtime. As an input the interrupt could also drop into a driver much faster than userland software.
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.
But not everything uses that. Some software simply connects a pin of the port to a motor and another to a sensor, then uses software in the computer to turn the motor off as soon as it sees the sensor be activated.
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.
I remember trying to interface a PCs Limited (original Dell) parallel port to a Slo Syn paper tape reader on Excellon PCB drills and routers around 1995.
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.