On 03/19/2013 06:24 PM, John Miles wrote:
And BTW, the OS isn't watching the hardware lines, the device driver is
through the adapter.
If it's running on the CPU, it's running on the CPU. At GPIB service rates, the benefits of doing so at ring 0 are either nonexistent, or arise from suboptimal architectural decisions at the application level.
We're not exactly talking gigabit Ethernet here...
My tennis court must be an airport tarmac then, cause I'm talking to 15
devices, not counting the 42 relays and 10 buttons through the 6 50M30s
on the routing box
And your goal in attempting to control all of that with a low-end $150 GPIB adapter intended for plotter emulation and basic instrument scripting was what? To save money?
-- john, KE5FX
I'm trying to help others from thinking it's a real GPIB controller that
will grow with their system. Same price and you can get a real NI
PCI-GPIB card off eBay.
The fact that it uses a tcp socket or an emulated serial port doesn't
matter to me. The command/response nature of their app layer protocol
as spoken over either duplex link layer was a limiting design decision.
The features of IEEE-488.1-1987, that more than likely can/will be used
by the devices you'll have to talk to, just don't fit inside their
protocol. Tek's "RQS ON" command for their 5000 plugins is a great
example of SOL with the Prologix. Out-of-band announcements of RQS with
status bits would bring that controller up at least a few more notches
in value and usability.
