I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I send the test document from CUPS, no amount of fiddling with the USB cable will cause it to print.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to date.
On 12/14/15 11:23, Geoffrey Leach wrote:
I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I send the test document from CUPS, no amount of fiddling with the USB cable will cause it to print.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to date.
Have you examined /var/log/cups/error_log ?
On 12/13/2015 09:56:40 PM, Ed Greshko wrote:
On 12/14/15 11:23, Geoffrey Leach wrote:
I have a LaserJet 1300 printer that connects via a Belkin parallel
port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using
ehci-pci
[80926.472738] usb 4-1.1: New USB device found, idVendor=050d,
idProduct=0002
[80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer
dev 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I
send the test document from CUPS, no amount of fiddling with the USB cable will cause it to print.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to
date.
Have you examined /var/log/cups/error_log ?
That file does not exist. This despite printing the test page displayed "Unable to send data to printer" after a few minutes. CUPS does see the printer and does see changes in status when printer is powered on.
On Mon, 2015-12-14 at 11:38 -0800, Geoffrey Leach wrote:
On 12/13/2015 09:56:40 PM, Ed Greshko wrote:
Have you examined /var/log/cups/error_log ?
That file does not exist. This despite printing the test page displayed "Unable to send data to printer" after a few minutes. CUPS does see the printer and does see changes in status when printer is powered on.
Since recently Cups logs go to journald by default. You can look at cups logs using 'journalctl -u cups'.
If there's no debug info, browse to "http://localhost:631", choose the 'Administration' menu at the top, and tick 'Save debugging' bottom right.
On 12/15/2015 12:04:48 AM, Berend De Schouwer wrote:
On Mon, 2015-12-14 at 11:38 -0800, Geoffrey Leach wrote:
On 12/13/2015 09:56:40 PM, Ed Greshko wrote:
Have you examined /var/log/cups/error_log ?
That file does not exist. This despite printing the test page displayed "Unable to send data to printer" after a few minutes. CUPS does see the printer and does see changes in status when printer is powered on.
Since recently Cups logs go to journald by default. You can look at cups logs using 'journalctl -u cups'.
If there's no debug info, browse to "http://localhost:631", choose the 'Administration' menu at the top, and tick 'Save debugging' bottom right.
The output from merely sending a test page to the printer is considerable. I've attached the file.
On Sun, 2015-12-13 at 19:23 -0800, Geoffrey Leach wrote:
I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
I've had some devices do that when they didn't get enough power over USB. Have you tried another USB port? Do you have a powered USB hub?
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
The serial number shouldn't be zero. Cups uses different serial numbers do differentiate between printers. It shouldn't be, but it can be.
What's the cups device? Are you using parallel://dev/lp0 or usb:// ? Might be something like "usb://EPSON/Stylus%20Photo%20R200?serial=M02P20502230111234"
[80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I send the test document from CUPS, no amount of fiddling with the USB cable will cause it to print.
Will "echo -en 'hello world\n\f' > /dev/usb/lp0" print? This should print the text, with a form feed. I assume it will block (wait forever)
The device might be /dev/usblp0 or /dev/usb/lp0. There might be a symbolic link /dev/lp0 -> /dev/usb/lp0.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to date.
On 12/13/2015 10:40:10 PM, Berend De Schouwer wrote:
On Sun, 2015-12-13 at 19:23 -0800, Geoffrey Leach wrote:
I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
I've had some devices do that when they didn't get enough power over USB. Have you tried another USB port? Do you have a powered USB hub?
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
The serial number shouldn't be zero. Cups uses different serial numbers do differentiate between printers. It shouldn't be, but it can be.
What's the cups device? Are you using parallel://dev/lp0 or usb:// ? Might be something like "usb://EPSON/Stylus%20Photo%20R200?serial=M02P20502230111234"
[80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer
dev
5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I
send
the test document from CUPS, no amount of fiddling with the USB
cable
will cause it to print.
Will "echo -en 'hello world\n\f' > /dev/usb/lp0" print? This should print the text, with a form feed. I assume it will block (wait forever)
Submitted by root, the command prints fine. dev/usb/lp0 is character special (180/0)
The device might be /dev/usblp0 or /dev/usb/lp0. There might be a symbolic link /dev/lp0 -> /dev/usb/lp0.
On Mon, 2015-12-14 at 11:46 -0800, Geoffrey Leach wrote:
On 12/13/2015 10:40:10 PM, Berend De Schouwer wrote:
Will "echo -en 'hello world\n\f' > /dev/usb/lp0" print? This should print the text, with a form feed. I assume it will block (wait forever)
Submitted by root, the command prints fine. dev/usb/lp0 is character special (180/0)
OK, so does Cups print to usb://, parallel:// or file:// ? What's the device URI?
You can get the device URI using 'lpstat -t' or using 'http://localhost :631/'
On 12/14/2015 11:58:53 PM, Berend De Schouwer wrote:
On Mon, 2015-12-14 at 11:46 -0800, Geoffrey Leach wrote:
On 12/13/2015 10:40:10 PM, Berend De Schouwer wrote:
Will "echo -en 'hello world\n\f' > /dev/usb/lp0" print? This should print the text, with a form feed. I assume it will block (wait forever)
Submitted by root, the command prints fine. dev/usb/lp0 is character special (180/0)
OK, so does Cups print to usb://, parallel:// or file:// ? What's the device URI?
You can get the device URI using 'lpstat -t' or using 'http://localhost :631/'
% lpstat -t scheduler is running system default destination: HP_LaserJet_1300 device for HP_LaserJet_1300: usb://HP/LaserJet%201300
On Tue, 2015-12-15 at 16:14 -0800, Geoffrey Leach wrote:
On 12/14/2015 11:58:53 PM, Berend De Schouwer wrote:
On Mon, 2015-12-14 at 11:46 -0800, Geoffrey Leach wrote:
On 12/13/2015 10:40:10 PM, Berend De Schouwer wrote:
Will "echo -en 'hello world\n\f' > /dev/usb/lp0" print? This should print the text, with a form feed. I assume it will block (wait forever)
Submitted by root, the command prints fine. dev/usb/lp0 is character special (180/0)
OK, so does Cups print to usb://, parallel:// or file:// ? What's the device URI?
You can get the device URI using 'lpstat -t' or using 'http://localhost :631/'
% lpstat -t scheduler is running system default destination: HP_LaserJet_1300 device for HP_LaserJet_1300: usb://HP/LaserJet%201300
You should note if Cups ever disables your printer automatically. In that case you want to set the option ErrorPolicy to retry-job. It means that if the printer times out (bad cable) cups will try again, instead of just halting permanently. You should see 'enabled' or 'disabled' somewhere in 'lpstat -t'
If you have tried a different cable, you can try a different URI: 'lpadmin -p HP_LaserJet_1300 -v parallel://dev/usb/lp0'. The point is to just try a different protocol, and hopefully different error tolerances.
Don't use parallel: or file: if you have more than one USB printer. The print jobs can end up on the wrong printer.
On 12/16/2015 01:31:55 AM, Berend De Schouwer wrote:
On Tue, 2015-12-15 at 16:14 -0800, Geoffrey Leach wrote:
On 12/14/2015 11:58:53 PM, Berend De Schouwer wrote:
On Mon, 2015-12-14 at 11:46 -0800, Geoffrey Leach wrote:
On 12/13/2015 10:40:10 PM, Berend De Schouwer wrote:
Will "echo -en 'hello world\n\f' > /dev/usb/lp0" print? This should print the text, with a form feed. I assume it will block
(wait
forever)
Submitted by root, the command prints fine. dev/usb/lp0 is character special (180/0)
OK, so does Cups print to usb://, parallel:// or file:// ? What's the device URI?
You can get the device URI using 'lpstat -t' or using 'http://localhost :631/'
% lpstat -t scheduler is running system default destination: HP_LaserJet_1300 device for HP_LaserJet_1300: usb://HP/LaserJet%201300
You should note if Cups ever disables your printer automatically. In that case you want to set the option ErrorPolicy to retry-job. It means that if the printer times out (bad cable) cups will try again, instead of just halting permanently. You should see 'enabled' or 'disabled' somewhere in 'lpstat -t'
If you have tried a different cable, you can try a different URI: 'lpadmin -p HP_LaserJet_1300 -v parallel://dev/usb/lp0'. The point is to just try a different protocol, and hopefully different error tolerances.
Don't use parallel: or file: if you have more than one USB printer. The print jobs can end up on the wrong printer.
I changed the error policy in CUPS and the test page printed, so that's progress. As I don't have the option of replacing the USB cable, I'm thinking of a hub. TBD there.
Thanks.
Op Mon, 14 Dec 2015 04:23:47 +0100 schreef Geoffrey Leach geoff@hughes.net:
I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I send the test document from CUPS, no amount of fiddling with the USB cable will cause it to print.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to date.
I once did have the same problem with a HP4620 Officejet : You won't believe it : After some weeks of investigation and discus with HP the USB cable was to long ! Instead of 1,5 meter 2,5 meter.
Maybe this can help , although it seems rediculous.
On 12/14/2015 12:22:24 AM, Ger van Dijck wrote:
Op Mon, 14 Dec 2015 04:23:47 +0100 schreef Geoffrey Leach geoff@hughes.net:
I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half
the
time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what
dmesg reports:
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0 [80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer
dev 5
if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I
send
the test document from CUPS, no amount of fiddling with the USB
cable
will cause it to print.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to
date.
I once did have the same problem with a HP4620 Officejet : You won't believe it : After some weeks of investigation and discus with HP the USB cable was to long ! Instead of 1,5 meter 2,5 meter.
Maybe this can help , although it seems rediculous.
Hey, I'll try anything :-) Regretably, however, the USB cord is part of the Belkin. I did rattle everything, but no change.
On 12/14/15 03:22, Ger van Dijck wrote:
Op Mon, 14 Dec 2015 04:23:47 +0100 schreef Geoffrey Leach geoff@hughes.net:
I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I send the test document from CUPS, no amount of fiddling with the USB cable will cause it to print.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to date.
I once did have the same problem with a HP4620 Officejet : You won't believe it : After some weeks of investigation and discus with HP the USB cable was to long ! Instead of 1,5 meter 2,5 meter.
Cables can be a problem. Once upon a time I worked for a major super-minicomputer manufacturer here in New England. We were adding X-Terminals to our office equipment. They all ran on ethernet that was then called "thick-net". Most ran well, but, a select few had cabling problems. Most of the failures could be fixed by adding or removing 1 meter segments of the ethernet cabling. Drove us nuts. We finally got the thicknet repeater manufacturer together with the X-terminal manufacturer together. Each blamed the other. Turns out both were at fault. While the specification allows a 10% signal variance, both implemented a +/- 5% from their own signal variance. The result was that one manufacturer was -6% off the base frequency and the other was +6% off. That resulted in a 12% variance, which sometimes changed depending on how many cables were used between the devices. What a pain in the butt! We were able to convince both of them to change their implementations so that their equipment would inter-operate, regardless of how many drop cables were used.
Maybe this can help , although it seems rediculous.
Ridiculous or not, its a reality in the hardware world.
On Tue, Dec 15, 2015 at 05:30:10PM -0500, Kevin Cummings wrote:
On 12/14/15 03:22, Ger van Dijck wrote:
Op Mon, 14 Dec 2015 04:23:47 +0100 schreef Geoffrey Leach geoff@hughes.net:
I have a LaserJet 1300 printer that connects via a Belkin parallel port-to-USB connector. When I send a document to the printer, half the time it prints without hesitation; other times it stalls until I disconnect and re-connect the USB cable. When I do that, here's what dmesg reports:
[80924.737154] usb 4-1.1: USB disconnect, device number 4 [80924.737587] usblp0: removed [80926.381095] usb 4-1.1: new full-speed USB device number 5 using ehci-pci [80926.472738] usb 4-1.1: New USB device found, idVendor=050d, idProduct=0002 [80926.472749] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [80926.472755] usb 4-1.1: Product: IEEE-1284 Controller [80926.472759] usb 4-1.1: Manufacturer: Belk USB Printing Support [80926.497804] usblp 4-1.1:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 1 proto 2 vid 0x050D pid 0x0002
CUPS discovers the printer without any problems. However, when I send the test document from CUPS, no amount of fiddling with the USB cable will cause it to print.
Any insights will be greatly appreciated.
Firefox 23; kernel 4.2.6-301.fc23.x86_64 #1 SMP, everything up to date.
I once did have the same problem with a HP4620 Officejet : You won't believe it : After some weeks of investigation and discus with HP the USB cable was to long ! Instead of 1,5 meter 2,5 meter.
Cables can be a problem. Once upon a time I worked for a major super-minicomputer manufacturer here in New England. We were adding X-Terminals to our office equipment. They all ran on ethernet that was then called "thick-net". Most ran well, but, a select few had cabling problems. Most of the failures could be fixed by adding or removing 1 meter segments of the ethernet cabling. Drove us nuts. We finally got the thicknet repeater manufacturer together with the X-terminal manufacturer together. Each blamed the other. Turns out both were at fault. While the specification allows a 10% signal variance, both implemented a +/- 5% from their own signal variance. The result was that one manufacturer was -6% off the base frequency and the other was +6% off. That resulted in a 12% variance, which sometimes changed depending on how many cables were used between the devices. What a pain in the butt! We were able to convince both of them to change their implementations so that their equipment would inter-operate, regardless of how many drop cables were used.
Maybe this can help , although it seems rediculous.
Ridiculous or not, its a reality in the hardware world.
there is definitely a limit on USB cable length, and for some devices its very strict. I have a Canon LIDE 210 USB scanner here. I had originally put together cables long enough to reach from the shelf by my desk to the computer, and it totally failed to work when using that cabling. it works only if I hold it on my lap (no room on the desk) so that the USB cable is no more than 4-5 feet long.
I've used much longer USB cables with a Brother laser printer, but I was probably pushing my luck there, since the standard does specify rigid cable length limits.
Allegedly, on or about 15 December 2015, Fred Smith sent:
there is definitely a limit on USB cable length, and for some devices its very strict. I have a Canon LIDE 210 USB scanner here. I had originally put together cables long enough to reach from the shelf by my desk to the computer, and it totally failed to work when using that cabling. it works only if I hold it on my lap (no room on the desk) so that the USB cable is no more than 4-5 feet long.
I've used much longer USB cables with a Brother laser printer, but I was probably pushing my luck there, since the standard does specify rigid cable length limits.
There's specifications for 1.5 megabit/sec (low-speed) of 3 metres, and 12 megabit/sec (full-speed) of 5 metres for USB 1.1. And USB 2.0 specifies 480 megabits/sec (hi-speed) of 5 metres. Apparently USB 3.0 doesn't specify a maximum cable length, but the practicality of signalling (*) parameters places it at 3 metres.
* It's not just data going down a wire, there's handshaking, as well. The timing of data and handshaking response is critical. Introduce too much delay (due to cabling length, or its electrical characteristics), and every transmission becomes mistimed.
Those are the full end-to-end cabling lengths, including the wiring inside the device from one device's electronic circuits to the other device's circuitry. Hence a 5 metre connecting cable actually exceeds the specifications.
There are ways to correctly exceed these lengths between equipment that's placed too far apart, and that's to have cables with electronics inside them (probably in the connectors). It may be possible to simply use a hub in the middle, but I haven't researched that.
It's worth noting that some cabling will be horribly inferior. If you split apart cheap cabling (perhaps the one supplied with your equipment), you may find very thin wiring that simply runs in parallel to each other inside the sheath. The data pair of wires should be twisted around each other, to minimise the effects of outside interference to the data signals. So replacing cabling *may* be enough to resolve a problem.
You may find that the header cabling in some desktop PCs (from motherboard to front-panel connectors) is inferior. I had one that just used ribbon cable.
On 12/14/15 03:22, Ger van Dijck wrote:
... snip ...
Cables can be a problem.
... snip ...
Here's my USB cable story:
My sister-in-law's USB disk drive stopped working for her. I tried it on my Linux laptop, and it worked just fine. I took it to work and tried it on three different Windows machines (desktops and a laptop) they ALL refused to see the drive. I then booted a Linux Live CD on one of those Windows machines, and the drive WORKED!
Thinking it was a flakey drive with some weird Windows interaction, I suggested we replaced the drive/enclosure. . When I brought the new drive/enclosure to her, I plugged it into her Windows machine (with her old cable just because I didn't want to undo the twist tie on the new cable, and besides... the old cable worked just fine when running Linux.) the new (tested on Linux) drive still would NOT work on her Windows machine!
On a whim, I tried the new cable. The drive then miraculously started working on her Windows machine.
To this day, I don't know what happened to that cable that made it 'no longer' work with Windows, but would work just fine with Linux.
Allegedly, on or about 15 December 2015, Kevin Cummings sent:
We finally got the thicknet repeater manufacturer together with the X-terminal manufacturer together. Each blamed the other. Turns out both were at fault. While the specification allows a 10% signal variance, both implemented a +/- 5% from their own signal variance. The result was that one manufacturer was -6% off the base frequency and the other was +6% off. That resulted in a 12% variance, which sometimes changed depending on how many cables were used between the devices.
Used to get that sort of compatibility issues with floppy disc drives; most machines could read the mass produced discs that were bought with software on them, but interoperability between machines was poor, even when buying the best discs that you could get.
Likewise with VHS VCRs, playing store bought movies was rarely a problem, but playing a tape recording on one home VCR on another home VCR often had problems.
-
Berend De Schouwer -
Ed Greshko -
Fred Smith -
Fulko Hew -
Geoffrey Leach -
Ger van Dijck -
Joe Zeff -
Kevin Cummings -
Tim