GPIB ? HPIB ?

Hi,

Jon Elson wrote:

>It is SLOW, WAY too slow, for motion control. With a CPU at each
>end, you are lucky to get a couple hundred commands a second across

>the GPIB. With physical hardware at each end, it does a little

better,

>but still too slow for what you are talking about. When sending

long

>blocks of data, it works pretty well, but when sending a small bit

of

>data to several devices, the protocol gets in the way.

I just don't find the data I am looking for, right now. But You say
it is WAY too slow. I am not convinced. I think it will "talk" as
fast as the "slowest" device on the bus. This does not have to
imply that the bus standard in it self is way too slow.
You have a transfer rate of 8Mb/s today, and I don't think this is
WAY too slow. We could skip some of the transfer protocol, but use
the physical io interface. Making intelligent IO devices, to do
the things we would like, could be done. It is the most widely used
bus for instrumentation, and there is a lot of application
notes/data, software, chips set, etc.

There is also all kinds of cards, and interface to all kinds of
networks. There is also some high speed systems. I do believe we
could do a lot with this. The thing is, there is a lot of
functions we would like to have, that is not that time critical, so
it could be very useful in any case.

Wake up guys ! Come with comments. We just might have something
that could give us a good solution to a lot of applications.

Here is a crazy idea:

If you have something time critical, let say stepper control.
Well, what you have is a big file, or buffer, - and you output it
on the printer port. Well, you could send a lot of bytes and
buffer them on the IO device, then just use a clk line controlled
by RTLinux, - what I mean, there is possible other ways to do
something. The thing is, don't abandon this bus idea right away.
It could be a much better way, than doing things with IDE interface,
USB or what ever.

//ARNE