Re: GPIB ? HPIB ?

"Arne Chr. Jorgensen" wrote:

> 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.

Yes, what you say is partially true. I think there are some delays built
into the interfaces, but much of it is software overhead. Once you have
selected a device and function, you can shove data into that 'register'
pretty fast, if the device was set up to just accept data pushed into one
register, without handshaking. Most of the GPIB protocol requires
the handshaking, which slows everything down, because you have
to turn the bus around, and become a listener after sending every
byte of data.

> 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.

I made up my own personal control bus, that uses a printer port to
control up to 256 devices, with up to 256 registers per device. It
runs about 50 times faster than the GPIB hardware we have, but
doesn't have any handshaking. It can also read from up to 256
registers per device. The interface between my bus and the parallel
port is just about 4 chips and a couple resistor packs.

> 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.

Yeah, then the screen display has nothing to do with what is going
on with the machine, it shows where the machine will be in 10 minutes!
And, if you make a feed rate change or hit stop, it will keep going
for minutes before what you did has any effect. Not desirable!