Linumeric-LPT V3 - Ethernet to LPT controller for LinuxCNC

Hi. I would like to show you a device I built. It's called Linumeric-LPT V3 and it's an Ethernet-LPT adapter/controller for linuxCNC. The device works similarly to Linumeric-LPT V1 and V2, only instead of communicating via USB, it communicates via LPT. Reduced delays, increased time determinism. The device is even suitable for controlling a CNC lathe and performing synchronous movements. More details on my website:
www.machmaker.pl/linumeric-lpt-v3


 

Some of us already know, we had some discussions about it but can no find the topic.
Looks nice, it should also work, but i really do not like you not posting the prices, again.
I do like that you have pictures of it's insides, though, utmost respect for that.

Prices will not be a secret. I am preparing an online store on my website, there will be products with given prices. The store opens in January.
I looked through the topics on this forum regarding linumeric - I want to clarify that this device should not be compared to mesa cards. This device works completely differently, it is an LPT port and all control is still done in LinuxCNC on the base thread. The device should be treated as an LPT port with all its advantages and disadvantages.

I'm really very much interested how you achieved 100 kHz speed over Ethernet, it requires round-trip-time over network less than 10 microseconds. From the description, I made a (erratic) conclusion that any arbitrary sequence could be output with 100 kHz frequency, that yields even a better value, 5 microsecond maximum.

It is crucial to comprehend the functioning of this device. This device does not impair the functionality of LinuxCNC; it serves solely as a parallel interface communicating via Ethernet. All control occurs within the computer, akin to the conventional LPT port. The maximum signal frequency supported by the controller is 100 kHz, implying that the base thread in LinuxCNC must operate at this frequency. Personally, I lack a computer capable of handling this frequency due to jitter, and I also lack a machine necessitating such capabilities. I own a laser plotter, two trailing knife plotters, a large milling plotter, and a 3-axis milling machine, none of which require anything beyond the capabilities of a linumeric device to operate. Although all control is buffered, the buffer is limited to the essential minimum. The total loop delay is calculated in real time and is accessible as a signal in the hall.
 
On my laptops, I can achieve a delay below 1 ms, which is roughly equivalent to the (typical) period of the servo thread. While any delay is not ideal, it can be quantified. If the delay doesn't introduce a significant error, it is deemed acceptable. Take, for instance, homing, material, or tool measurement. Sampling is initially done coarsely and then refined at low speed. Assuming an approach speed to the limit switch of 100 mm/min, a 1 ms delay results in a measurement error of about 1 μm. This error exceeds the expectations and accuracy of most amateur or even semi-amateur machines.In the case of threading, this delay is crucial only for rigid threading, not for regular threading. For example, when cutting a rigid thread with a pitch of 2 mm at a rotational speed of 300 rpm, a 1 ms delay yields a thread position error of approximately 0.01 mm in both directions. I believe that, for a significant number of users, this error is smaller than the accuracy of their machine and is deemed acceptable.I am transparent about the advantages and disadvantages of this solution, and I don't withhold any information. Regarding communication via Ethernet, I have created a special distribution of Debian 12 that comes with everything installed to support linumeric-LPT V1/V2/V3, and the system is optimized for Ethernet communication. You can run the system in live mode, and everything functions immediately.

 

Does it mean that Linumeric-LPT receives every 1 ms a packet from PC that is enough to output some number of bits with 5 us resolution? Thus, 1ms/5us=200 samples, multiply by number of bits in LPT, say, 16, yields 1ms/5us*16bits/8bits per byte=400 bytes every period? (litexcnc yet hasn't fifo mode but there are some examples of udp stream receiver in litex to provide control for something like laser galvanic scanner - and there is the same obvious application for Linumeric-LPT too)