4 ms·

So why do those "cheap USB to parallel port converters" only work with printers?

by Aqwis 10y ago

simcop2387 10y ago
Timing mostly. These kinds of devices are using the parallel port to "bitbang" everything. Because of that they need rather precise control of timing in order for things to happen when they expect. The USB devices usually just let you send a stream of bytes and they go out without much control over how fast they change. There's apparently some people making usb devices for things like Mach3 and they have some links to them: http://www.cncrouterparts.com/my-computer-doesnt-have-a-parallel-port-can-i-just-get-a-usb-p-154.html http://www.cncrouterparts.com/my-computer-doesnt-have-a-para...
- nitrogen 10y ago
  Another reason a long time ago was that you could control the built-in port's I/O lines directly by writing to a legacy IO port with a single assembly instruction. Any code written that way would not work with the USB adapters.
- toomuchtodo 10y ago
  I used a Geckodrive controller to connect via USB to the interface I needed to drive three stepper motors (and speed control for the drill motor) for the CNC mill I built. Works natively with Mach3. The timing is then offloaded to the microcontroller (in this case, the Geckodrive). http://www.geckodrive.com/geckodrive-step-motor-drives/g540.html http://www.geckodrive.com/geckodrive-step-motor-drives/g540....
  - nictinkers 10y ago
    That Geckodrive product appears to connect via a standard parallel port. I don't believe Geckodrive has a USB breakout board. You're possibly using the SmoothStepper from Warp9, the KFLOP board from Dynomotion, or one of a couple of Chinese products of widely varying quality. Once upon a time, the upper end of the market used expensive dedicated hardware for CNC motion control. The low end of the market used commodity PCs ruining the signals out the parallel port. Nowadays, the high end of the market is using PCs to do complex motion control (with computer vision etc) and the low end is using variants of Arduino boards with firmware like GRBL. With GRBL, the G-code itself is fed out the USB in a serial stream and the hardware does the motion calculations. Having the motion control in dedicated hardware is much nicer than having it on a PC with an operating system that can interrupt the fast timing loops and as hobby electronics gets more capable, you're going to see this set up more and more.
    - digi_owl 10y ago
      > having it on a PC with an operating system that can interrupt the fast timing loops I wonder if this is also the case for old lab equipment that keep running one some dusty DOS box because replacing the equipment is expensive and time consuming.
- StillBored 10y ago
  Its more than that, most of the things that utilize the parallel port talked to the IO ports directly for the bit banging. The USB->parallel ones hide the parallel interface behind the windows/etc parallel port driver so that provides an additional roadblock for the old software which otherwise might work.
deleted 10y ago
[deleted]
yuubi 10y ago
They have ieee1284 printer-port protocol baked into them, so you do an OUT transaction of several bytes and the adapter does the per-byte handshaking. The old parallel ports were just a collection of gpio lines (originally some input-only and some output-only, later some turned bidirectional) connected to some io addresses.
SFJulie 10y ago
because USB is serial, and parallel is parallel. So every bytes has to be sent in parallel after you made sure you signal correctly they are ready the direction of communication... So, it makes a lot of trouble. USB is still one of the biggest mistake of computer hardware where a supposed simplicity for the user comes at the price of an clumsy complex unsecure spaghetti layer of abstractions in order to prevent small hardware makers to compete. A bus should not care of the class of the device on the bus. A simple handshaking protocol with a simple fixed size identifier handled by something like IANA could be enough. It could also be just declarative avoiding bad surprises (well I still don't understand why my computer sees 3 USB keyboard at bootup and what my devices can do). You have 1 device on the bus, you load explicitly the driver, avoiding functionalities you don't wish to work. USB is hardly auditable, while a multi input oscilloscope is enough to see what happens on a // bus and debug analyze... The certification process is a pain. The HW manufacturers do what they want and patch the protocol in ways that are wtf. And just look at the dozens of cable to convince yourself the U in USB is not for Universal anymore, but rather Unconsistent. USB is almost DRM by obfuscation for the profit of shitty hardware manufacturers. Long live to USB-C, long live to the future of computer where obsolescence is programmed every 5 years, while some electronic have a life expectancy of decades (industry, aeronautic, medical systems, expensive labs systems, weapon systems, traffic signalisation, nuclear/energy equipment)...

So why do those "cheap USB to parallel port converters" only work with printers?

by Aqwis 10y ago

So why do those "cheap USB to parallel port converters" only work with printers?

Timing mostly. These kinds of devices are using the parallel port to "bitbang" everything. Because of that they need rather precise control of timing in order for things to happen when they expect. The USB devices usually just let you send a stream of bytes and they go out without much control over how fast they change. There's apparently some people making usb devices for things like Mach3 and they have some links to them: http://www.cncrouterparts.com/my-computer-doesnt-have-a-parallel-port-can-i-just-get-a-usb-p-154.html http://www.cncrouterparts.com/my-computer-doesnt-have-a-para...

nitrogen 10y ago
Another reason a long time ago was that you could control the built-in port's I/O lines directly by writing to a legacy IO port with a single assembly instruction. Any code written that way would not work with the USB adapters.
toomuchtodo 10y ago
I used a Geckodrive controller to connect via USB to the interface I needed to drive three stepper motors (and speed control for the drill motor) for the CNC mill I built. Works natively with Mach3. The timing is then offloaded to the microcontroller (in this case, the Geckodrive). http://www.geckodrive.com/geckodrive-step-motor-drives/g540.html http://www.geckodrive.com/geckodrive-step-motor-drives/g540....
- nictinkers 10y ago
  That Geckodrive product appears to connect via a standard parallel port. I don't believe Geckodrive has a USB breakout board. You're possibly using the SmoothStepper from Warp9, the KFLOP board from Dynomotion, or one of a couple of Chinese products of widely varying quality. Once upon a time, the upper end of the market used expensive dedicated hardware for CNC motion control. The low end of the market used commodity PCs ruining the signals out the parallel port. Nowadays, the high end of the market is using PCs to do complex motion control (with computer vision etc) and the low end is using variants of Arduino boards with firmware like GRBL. With GRBL, the G-code itself is fed out the USB in a serial stream and the hardware does the motion calculations. Having the motion control in dedicated hardware is much nicer than having it on a PC with an operating system that can interrupt the fast timing loops and as hobby electronics gets more capable, you're going to see this set up more and more.
  - digi_owl 10y ago
    > having it on a PC with an operating system that can interrupt the fast timing loops I wonder if this is also the case for old lab equipment that keep running one some dusty DOS box because replacing the equipment is expensive and time consuming.
StillBored 10y ago
Its more than that, most of the things that utilize the parallel port talked to the IO ports directly for the bit banging. The USB->parallel ones hide the parallel interface behind the windows/etc parallel port driver so that provides an additional roadblock for the old software which otherwise might work.

deleted 10y ago

[deleted]

yuubi 10y ago

They have ieee1284 printer-port protocol baked into them, so you do an OUT transaction of several bytes and the adapter does the per-byte handshaking. The old parallel ports were just a collection of gpio lines (originally some input-only and some output-only, later some turned bidirectional) connected to some io addresses.

SFJulie 10y ago

because USB is serial, and parallel is parallel. So every bytes has to be sent in parallel after you made sure you signal correctly they are ready the direction of communication... So, it makes a lot of trouble. USB is still one of the biggest mistake of computer hardware where a supposed simplicity for the user comes at the price of an clumsy complex unsecure spaghetti layer of abstractions in order to prevent small hardware makers to compete. A bus should not care of the class of the device on the bus. A simple handshaking protocol with a simple fixed size identifier handled by something like IANA could be enough. It could also be just declarative avoiding bad surprises (well I still don't understand why my computer sees 3 USB keyboard at bootup and what my devices can do). You have 1 device on the bus, you load explicitly the driver, avoiding functionalities you don't wish to work. USB is hardly auditable, while a multi input oscilloscope is enough to see what happens on a // bus and debug analyze... The certification process is a pain. The HW manufacturers do what they want and patch the protocol in ways that are wtf. And just look at the dozens of cable to convince yourself the U in USB is not for Universal anymore, but rather Unconsistent. USB is almost DRM by obfuscation for the profit of shitty hardware manufacturers. Long live to USB-C, long live to the future of computer where obsolescence is programmed every 5 years, while some electronic have a life expectancy of decades (industry, aeronautic, medical systems, expensive labs systems, weapon systems, traffic signalisation, nuclear/energy equipment)...