3 ms·

They were using a ThinkPad from 2000, therefore I was guessing RS232 and not RS-424 or other industrial ports. A laptop for that age would also have a parallel

by jalk 4y ago

They were using a ThinkPad from 2000, therefore I was guessing RS232 and not RS-424 or other industrial ports. A laptop for that age would also have a parallel port, so in theory it could be some bespoke parallel protocol, but pretty unlikely. > It's easy to assume that this would be a simple rewrite, but real engineering I said - "If all they are using the DOS software for, is to get a log-file from the train, then its probably easy". The system is from the 70'ies so its very possible that they originally hooked up dumb terminals. Those are even harder to come by today and had no real way of getting data out of (hard-copy of what was on the screen to line-printer perhaps). Old terminal are also very clunky to haul around compared to even an old laptop. So the DOS program could very well just be a VT05 emulator, without any actual program logic built into it. So no I was not suggesting a rewrite but rather hack something together like some of us old greybeards here on hackernews like to do.

akiselev 4y ago
A lot of old industrial equipment used PCs with parallel ports in place of custom controllers. Parallel ports that were on the motherboard and hooked into the southbridge chipset could be accessed by DMA and driven in hard real time which is otherwise practically impossible to achieve on a speculative processor running Windows. The drivers could convert some gcode to digital signals in a ring buffer driven by an interrupt and just let the parallel port output the 5V logic signals to amplifiers, motor drivers, and so on. This was especially important for a lot of machinery because only mass market CPUs were fast enough to i.e. run computer vision to calibrate and then interpolate tool paths for a pick and place machine that placed thousands of components a minute. MachCNC was a popular CNC controller among hobbyists that exploited this feature, for example. It wasn’t until the explosion in the popularity of 3D printers that open source CNC controllers that could run on a cheap MCU became widely available (Klipper, Marlin, etc) The manufacturers saved a lot in NRE and manufacturing costs because a driver is a lot cheaper to write than a low volume controller design - with the parallel port they just had to design a board with a parallel port input that fanned out to a bunch of connectors going to off the shelf motor drivers and stuff. It also meant a much better user experience for users and devs alike but starting with Windows 8 drivers could no longer access LPT via DMA for security reasons (everything on the southbridge was exposed including USB iirc). I suspect theres some proprietary component for which the driver source code was lost so they can’t adapt it to run off a PCI parallel port card (my memory is fuzzy but DMA to southbridge works differently enough from PCI DMA that it’s not as simple as changing the port number) and USB adapters can’t provide the timing guarantees. They could use an off the shelf PCI FPGA card but parallel ports were extremely common all over industry especially with offices printers so it’s very battle tested hardware. Replacing that is just too risky because redundant safety systems are far better at covering for failures than making sure new bugs don’t slip through.
- azalemeth 4y ago
  I once used libparport -- a Linux library with hooks into kernel modules -- to obtain sub microsecond timing on custom hardware on a ~2008 Xeon pc. The parallel port has, by modern standards, terrible bandwidth but excellent latency: I waited for an interrupt and then "did a thing" once it was sent. I remember testing the timing with a 500 MHz scope and realising that I couldn't actually measure the timing error or delay accurately once I'd calibrated the whole system. The parallel port was basically wired as a general purpose ADC and DAC accessible by DMA, as the parent here says. Amazing kit at the time, and free in the context of expensive ADCs requiring custom hardware and difficulty interfacing in comparison.

by jalk 4y ago

akiselev 4y ago

A lot of old industrial equipment used PCs with parallel ports in place of custom controllers. Parallel ports that were on the motherboard and hooked into the southbridge chipset could be accessed by DMA and driven in hard real time which is otherwise practically impossible to achieve on a speculative processor running Windows. The drivers could convert some gcode to digital signals in a ring buffer driven by an interrupt and just let the parallel port output the 5V logic signals to amplifiers, motor drivers, and so on. This was especially important for a lot of machinery because only mass market CPUs were fast enough to i.e. run computer vision to calibrate and then interpolate tool paths for a pick and place machine that placed thousands of components a minute. MachCNC was a popular CNC controller among hobbyists that exploited this feature, for example. It wasn’t until the explosion in the popularity of 3D printers that open source CNC controllers that could run on a cheap MCU became widely available (Klipper, Marlin, etc) The manufacturers saved a lot in NRE and manufacturing costs because a driver is a lot cheaper to write than a low volume controller design - with the parallel port they just had to design a board with a parallel port input that fanned out to a bunch of connectors going to off the shelf motor drivers and stuff. It also meant a much better user experience for users and devs alike but starting with Windows 8 drivers could no longer access LPT via DMA for security reasons (everything on the southbridge was exposed including USB iirc). I suspect theres some proprietary component for which the driver source code was lost so they can’t adapt it to run off a PCI parallel port card (my memory is fuzzy but DMA to southbridge works differently enough from PCI DMA that it’s not as simple as changing the port number) and USB adapters can’t provide the timing guarantees. They could use an off the shelf PCI FPGA card but parallel ports were extremely common all over industry especially with offices printers so it’s very battle tested hardware. Replacing that is just too risky because redundant safety systems are far better at covering for failures than making sure new bugs don’t slip through.

azalemeth 4y ago
I once used libparport -- a Linux library with hooks into kernel modules -- to obtain sub microsecond timing on custom hardware on a ~2008 Xeon pc. The parallel port has, by modern standards, terrible bandwidth but excellent latency: I waited for an interrupt and then "did a thing" once it was sent. I remember testing the timing with a 500 MHz scope and realising that I couldn't actually measure the timing error or delay accurately once I'd calibrated the whole system. The parallel port was basically wired as a general purpose ADC and DAC accessible by DMA, as the parent here says. Amazing kit at the time, and free in the context of expensive ADCs requiring custom hardware and difficulty interfacing in comparison.