usb->lpt - "machmaker" - is it fake or is it real?

hi *,does anyone have experience with it?

150kHz with an usb2lpt-port?
machmaker.pl/data/files/Instrukcja%20Obs...numeric-LPT%20v2.pdf



In my own tests some years ago with raw-eth instead
of usb I found the limit at about 5kHz.

I think, 150kHz with this usb-device is impossible.

regards

wicki








 

150 KHz is certainly possible since its done by the ucontroller.
There is/was a very similar device sold in the US.

Since it does not have a real time connection to the host
it requires some kind of internal motion buffering.

I never had a mesa-card in my hands - but maybe an friendly tester here
is able to send me the results of a mesa-test like this:

The time-span from toggling an input-pin until the acknowledge of
the changed pin inside the linux-pc.

And the time-span from setting an output-pin in the linux-pc
to change the real level of this in of the card.

A small test-prgram may look like this:

connect lpt-output-pin to mesa-input-pin

set 0378 to 0
read mesa-input-pin
repeat
read mesa-input-pin
until pin changes
set 0378 to 1
repeat
read mesa-input-pin
until pin changes

I think, stable response-time below 200 uSec is not possible.
even in an usb- or ether-connection.

A 100Mbit-ether may be able to realize 10uSec - but the linux-rt-kernel
is not able to handle this.

This are - how I think to remember - the results of my last tests towards the end of 2019.

I do not believe that the rt-kernel is faster now - or is it?

So it may be possible, to send a stable 150kHz-signal via usb. (if the signal is
generated inside the usb-hardware) - but is impossible, to read an input-signal
by usb with an nearly-RT-response (<200uSec).
Same limits as with raw-ethernet-connections.

Or has anyone here had other experiences?
If so: please let me know....



regards

wicki

Mesa update rate depends on servo thread rate, which usually is 1kHz.

AFAIK the problem with usb is not lack of bandwidth or "real time" capabilities, after all, "stable-enough" audio and even things like webcams are possible over USB -- the problem is a bunch of unreliable host controller interfaces, strange vendor dependent behaviour in case of transmission errors etc.., and nobody putting in the hours of debugging / troubleshooting to make that stuff stable.

I just found this in an old posting from andypugh:

"Every thread period it sets a step-rate and the FPGA holds that rate constant until the next thread cycle."

A good explanation which gives me an idea, how the mesa-cards are working.
I've tried to read and handle encoders and to write motor-steps in one
thread in realtime and failed because of to much jitter in the rasberry-timings.

When my milling machines are running again, I will give it another try in an
other way....
hoping to remember, what I have done there four years ago