GPIB users/experts/programmers, step in here please

A thread where the concepts, usage of and user experience with this signalling standard are discussed.

What's your favorite stand-alone controller? Interface card? PC-based software package?

As for me, I'm looking for details on programming the Tektronix TM5000-series mainframes and their related plug-ins. I don't feel like spending $3500 for LabVIEW and am seriously considering the development of an embedded, dedicated controller which will handle, say, a half-dozen devices simultaneously. Maybe two signal generators, a set of relays in an MI5010/50M40 setup...and a 50M30/50M10 card in same, along with a frequency counter or DMM for the sampling functions. The idea (one of many) is to develop an automated test suite for receiver or transceiver alignment.

Is GPIB even used these days? HP standard from wayback, as I recall, but that's about all I know.

I have been trying to find a macro that will read from a GPIB into an excel spreadsheet. No luck yet. But yeah. GPIB has been around for many decades.

I have a National Instruments PCI-based GPIB adapter that I bought off of Ebay, along with a USB-GPIB controller that I bought from Abdul Nizar, at his company: Prologix. I either use the tools provided by John Miles' KE5FX GPIB Toolkit, or I write the C-code myself to run under either Linux or Windows.

My interests have been in the control of some Hewlett Packard equipment that I have. Some of it doesn't have front panel user controls, so it has to be run over GPIB.

P.S., I forgot to mention a good GPIB overview page on Didier Juges' website: KO4BB. KO4BB is a current member of the same amateur radio club I joined way back when I was a long-haired, 15 year-old kid: The Playground Amateur Radio Club, W4ZBB, in Ft. Walton Beach, FL.

Quote:

---

Originally Posted by X-Rated

I have been trying to find a macro that will read from a GPIB into an excel spreadsheet. No luck yet. But yeah. GPIB has been around for many decades.

---

Here's an old 2003 document that might be interesting. I just skimmed through it, but it looks like they are doing what you are trying to do: http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA420445

I've never programmed an interface to GPIB. Believe it or not, I never ran into anything in a radio station that ever used it until three years ago, when a brand-new, fully VoIP-based broadcast audio console we bought used GPIB for remote starts and tallies.

I have written device drivers for parallel and serial ports though. Wish I could be more help.

I'm not so much looking for device drivers as the top-level application suites which actually control the attached peripherals. As pointed out above: NI, Prologix and a host of others offer a number of adapters along with device drivers that can be used in conjunction with a PC for device control.

It's the application side of the stack which is a little thin...

Just shot an e-mail off to John, 'FX inquiring as to the support of TM5000 peripherals and offered to write some middleware if they're not currently supported.

Here's a potential embedded solution:

http://forums.parallax.com/showthrea...er-speaks-GPIB

The cool thing about a Propeller is cost ($89 for the complete development kit) and the fact that it supports VGA/keyboard/mouse (via $13 add-on). The wheels: They're turning. :chin:

Ah, well if all you need to do is push some data to a hardware port.... Not too difficult. Documentation on what to send where to do what, is all you need to get started. Almost any programming platform will work. I did direct interfacing to hardware ports with VB for years. Truly easy if the device comes with its own drivers for your O/S.

As for embedded... Yeah, $89 is cheap for a programmer. I wonder if Arduino does GPIB.

Quote:

---

Originally Posted by wb5ydk

Here's an old 2003 document that might be interesting. I just skimmed through it, but it looks like they are doing what you are trying to do: http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA420445

---

WOW. Thanks. This is what I needed.

WHOOOSH!

That's the sound of this thread going WAY over my head.

Quote:

---

Originally Posted by WU9G

WHOOOSH!

That's the sound of this thread going WAY over my head.

---

GPIB is an acronym for "General Purpose Instrument Bus". It's IEEE 488.2, and specifies a data-transfer standard by which laboratory instrumentation can be controlled.

A lot of the test equipment produced in the pre-USB/Ethernet days has a GPIB connector to facilitate programmatic control or step execution...data gathering and so forth.

Control logic is state-driven, meaning one piece of gear can wait on another to acknowledge an operation before it proceeds with a task.

Example: I have a Tek 5000-series plugin with a 50M40 relay card. I'm going to use one of the lines to switch the PTT circuit of a transceiver under test. Immediately after the relay controller signals closure, the main controller program commands a signal generator to generate a single-tone (1KHz) sine wave of 2.5mV amplitude...which is applied to the rig's Mic In connector.

Another instrument is then commanded to make power readings and yet another is commanded to study the RF output waveform. Should said waveform show signs of distortion (or other 'fail' criteria) the signal generator cuts its output and the relay card opens the PTT circuit, putting the device under test back into receive mode.

You've used an ATM before, right? They're all state-driven.

Quote:

---

Originally Posted by N8YX

...

You've used an ATM before, right? They're all state-driven.

---

Wow. I didn't know many people around here have worked much with Asynchronous Transfer Mode.

http://en.wikipedia.org/wiki/Asynchronous_Transfer_Mode

Quote:

---

Originally Posted by N2KKM

I wonder if Arduino does GPIB.

---

Looks possible. Some thoughts on that here: http://arduino.cc/forum/index.php/topic,21821.0.html

Quote:

---

Originally Posted by X-Rated

Wow. I didn't know many people around here have worked much with Asynchronous Transfer Mode.

http://en.wikipedia.org/wiki/Asynchronous_Transfer_Mode

---

Different ATM. ;)

Quote:

---

Originally Posted by N8YX

Different ATM. ;)

---

D'oh. (_8(|)

GPIB is going extinct. It is basically an obsolete protocol. Most forward thinking hardware designers are using in-system reprogrammable devices, and replacing buses, like VME, GPIB, etc, with Ethernet. Ethernet as a bus essentially allows hardware independence. I good communications specifications using UDP/Multicast will be the direction to look in. At the local hardware level, intercopnnects using high speed SPI serial, which can move large words quickly with only 4 lines. Saves on board layout and complexity. Make hardware designs as generic as possible, digitizing inputs and recover outputs from digital sources, and make designs modular, high on reuse.

- In system reprogrammable FPGA's
- Programmable I/O devices, as Fred brought up, from Parallax
- Embedded processors, PIC's by Microchip.
--- PICs uses networks
--- PICs have hardware support for serial and USB
- Network as your system backplane
--- UDP for fast data transfer
--- Multicast, a variant of UDP, do not require live connections, and can be used by multiple devices simultaneously

I have seen, but not used, controllers that are built into RJ45 connectors, with I/O and built in web server. I really need to check these out.

Links:


http://www.lantronix.com/device-netw...ers/xport.html
http://www.lantronix.com/device-netw...servers/?tab=1 <<== Wireless network
http://www.embeddedarm.com/products/...ct=TS-7520-BOX
http://www.mosaic-industries.com/emb...icrocontroller

Nice.

Lordy. I used to program a lot of stuff via the ole trusty HP 9845...seems like a lifetime ago.

The problem with "going extinct" is that there's a hell of a lot of (now affordable) test gear on the market that's GPIB programmable.

Most of this stuff is much better quality than comparable, late-model "hobby-grade" test equipment. Thus, it behooves the experimenter to extract the full potential of such.

Scariest thing I've seen in a long time? An Ethernet-connected, $200K DSO running embedded Windows XP. With nothing more than a running copy of BackTrack or a similar hacker's toolkit, I can destroy that instrument with little difficulty.

I'll take the older stuff, thank you very much.

Quote:

---

Originally Posted by N8YX

The problem with "going extinct" is that there's a hell of a lot of (now affordable) test gear on the market that's GPIB programmable.

Most of this stuff is much better quality than comparable, late-model "hobby-grade" test equipment. Thus, it behooves the experimenter to extract the full potential of such.

Scariest thing I've seen in a long time? An Ethernet-connected, $200K DSO running embedded Windows XP. With nothing more than a running copy of BackTrack or a similar hacker's toolkit, I can destroy that instrument with little difficulty.

I'll take the older stuff, thank you very much.

---

I know what you mean. The newer stuff, you don't know what they do with it anymore. Like with older frequency measurement, there are so many specifications out there defining what the measurement parameters are and now it's like a blackbox and they don't tell you anything. It is all locked up in a little FPGA and they ain't tellin' ya a damned thing about how they come up with their results. I know because I have made FPGA products. LAF Paul knows as well. When you are in the know, you know. When you aren't, you don't know squat about it. Nowadays, they smooth things out with DSP or something so they get rid of one issue, but what does that do to your result? Will it slant it high in instances and low in others? Where are their cutoffs and band edges? What about NCO's and how they control those? I see little about that.

Sorry for the rant.

Quote:

---

Originally Posted by N8YX

The problem with "going extinct" is that there's a hell of a lot of (now affordable) test gear on the market that's GPIB programmable.

Most of this stuff is much better quality than comparable, late-model "hobby-grade" test equipment. Thus, it behooves the experimenter to extract the full potential of such.

Scariest thing I've seen in a long time? An Ethernet-connected, $200K DSO running embedded Windows XP. With nothing more than a running copy of BackTrack or a similar hacker's toolkit, I can destroy that instrument with little difficulty.

I'll take the older stuff, thank you very much.

---

Ayup. I've got a $20K Tek logic analyzer at work. Runs Win 95! (And probably sells for under a grand on eBay these days.)

Quote:

---

Originally Posted by kf0rt

Ayup. I've got a $20K Tek logic analyzer at work. Runs Win 95! (And probably sells for under a grand on eBay these days.)

---

Scary Pt.2: Tek won't support the older equipment. I.E., if you have a disk crash, it's time to buy another analyzer.

Contrast that to the two logic analyzer/word recognizer plugins I bought from eBay recently: All socketed ICs and transistors, the types which hardly ever fail. Most are off-the-shelf; the plugins are so cheap and readily available that it's almost unnecessary to even worry about repairing them should they fail.

One was for the 7000 series mainframe. New cost - $12k+. My cost - $65 including shipping.

Another, for the 500 series mainframe. $75 including shipping, though I had to buy a pull knob/latch for the thing as the one on it was broken. New, it was $4k+.

Probes...if I can find the WR501 for the LA501 I can use the same set of probes with either unit. As it stands, I'm limited to 4 channels on the LA501 unless a P6450 probe happens to turn up.

Got another unit - "digital video probe" - for $50 and a set of 3 probes plus accessories for $28. This stuff works just fine for debugging most amateur and commercial radio equipment whose CPUs or display drivers I can actually get a probe clip attached to.

Quote:

---

Originally Posted by N8YX

The problem with "going extinct" is that there's a hell of a lot of (now affordable) test gear on the market that's GPIB programmable.

Most of this stuff is much better quality than comparable, late-model "hobby-grade" test equipment. Thus, it behooves the experimenter to extract the full potential of such.

Scariest thing I've seen in a long time? An Ethernet-connected, $200K DSO running embedded Windows XP. With nothing more than a running copy of BackTrack or a similar hacker's toolkit, I can destroy that instrument with little difficulty.

I'll take the older stuff, thank you very much.

---

And I will take the newer stuff.. which lot of it is microprocessor controlled, such as what we used to call Oscilloscopes. The devices now not only works like an oscilloscope, it also provides screen capture, freeze, spit raw data out to memory stick for graphing on paper, spectrum analysis, frequency readout, voltage measurements, and on and on, in a single piece of equipment.

If you are concerned about hackers and equipment, run an isolated network, or isolate the network when equipment is in use. And like mobile devices, most equipment is either custom or runs a variant of Linux.

If the equipment can harm itself, from a 'hacker', then the equipment doesn't have protection features, blame the equipment manufacturer for poor programming and lack of interlocks.

Just my thoughts...

I developed a LabVIEW application using a rack of IOTech equipment (they were bought out by National Instruments) interconnected by GPIB. I still have my GPIB drivers.

What I would do/look out for is developing a Java application that uses JNI to talk with the hardware, and convert the Read/Write/Control via Multicast messages. Use an ini file to change IP address, port, TTL, and hardware parameters, so you can change configuration and machines without reprogramming the software. Multicast provides a common network interface that can be used by other programming languages. Even a small page server can be used with web browser access for monitoring and settings change. TTL is Time To Live, which controls the extent/reach of multicast messages at router/switch count. You can limit the multicast to within the computer, never going out or accepting messages outside of the resident system.

National Instruments are a little pricey...

NI GPIB-ENET/1000
High-Performance Ethernet-to-GPIB Controller
$ 1,183

NI GPIB-USB-HS
GPIB Controller for Hi-Speed USB
$ 565

Quote:

---

Originally Posted by N1LAF

And I will take the newer stuff.. which lot of it is microprocessor controlled, such as what we used to call Oscilloscopes.

---

You go right ahead - on your employer's budget.

Most hobbyists or smaller commercial outfits simply cannot afford the so-called bleeding edge. I have ready access to both. For signals below 1GHz, there's nothing I can't observe or do with a properly set up Tek 7104 or 7934...maybe a 24xx if I need more than two channels...that I can with a late model DSO from Agilent, Tek or the rest.

Quote:

---

If you are concerned about hackers and equipment, run an isolated network, or isolate the network when equipment is in use.

---

This defeats the purpose of state-driven remote control, no?

Quote:

---

And like mobile devices, most equipment is either custom or runs a variant of Linux.

---

Look very closely. Do you see what I see?

http://www.ebay.com/itm/Tektronix-TD...item519f28b360

I don't care if the scope runs Windows, HP-UX, BeOS, Linux, whatever...if its OS is contained in volatile (non-ROM) storage and there are inherent kernel flaws, it's game over...often right through the instrument's front keyboard.

Quote:

---

If the equipment can harm itself, from a 'hacker', then the equipment doesn't have protection features, blame the equipment manufacturer for poor programming and lack of interlocks.

---

Which brings us right back to the original premise of the thread: Discussing how to control the older, bullet-proof equipment.

For anyone still following that, I'm waiting to hear from KE5FX regarding the Tek 5000 stuff.

Well, the controllers are still available for PC's: http://www.ni.com/gpib/

So, it sounds like it would be pretty easy to write interface software. Looks like there is built in support in the Linux Kernel too, so embedded projects should be too difficult, either: http://linux-gpib.sourceforge.net/

A couple guys 'round the Interwebs have supposedly written some GPIB control routines in Python, so there's another potential solution.

Quote:

---

Originally Posted by KC2UGV

Well, the controllers are still available for PC's: http://www.ni.com/gpib/

So, it sounds like it would be pretty easy to write interface software. Looks like there is built in support in the Linux Kernel too, so embedded projects should be too difficult, either: http://linux-gpib.sourceforge.net/

---

The Linux GPIB drivers work well for me. I have noticed that the Ebay prices of the used NI and HP GPIB controllers, which use the PCI bus, have really fallen over recent years. These days, it is getting harder and harder to find new PCs that still have PCI slots. But, if you still have a slightly older PC, you can have GPIB capability for a very reasonable price. The USB and PCIe offerings from National Instruments still command a high price.

By the way, I have noticed a lot of USB-to-GPIB controllers showing up on Ebay from sellers in China. Some look like the "real deal" Agilent 82357B product; but who knows if they are genuine or a pirated copy. Other Chinese Ebay controllers are are packaged differently and claim to be 82357B compatible: 82357B clone. I haven't read any reviews that say how well these work.

Quote:

---

Originally Posted by N8YX

You go right ahead - on your employer's budget.

Most hobbyists or smaller commercial outfits simply cannot afford the so-called bleeding edge. I have ready access to both. For signals below 1GHz, there's nothing I can't observe or do with a properly set up Tek 7104 or 7934...maybe a 24xx if I need more than two channels...that I can with a late model DSO from Agilent, Tek or the rest.

---

Let's say that the new high tech scope is $2500, - $500 for equivalent, older equipment. Man-hour costs $50/hr. When the new tech stuff saves 40 hours in labor, the equipment would have paid for itself. So on a small company level, you have to gauge the usage, estimate the savings of one over the other per hour, and determine when the unit will pay for itself, and after that, the savings become a profit(over the old equipment)... how about that.

Quote:

---

Originally Posted by KC2UGV

Well, the controllers are still available for PC's: http://www.ni.com/gpib/

So, it sounds like it would be pretty easy to write interface software. Looks like there is built in support in the Linux Kernel too, so embedded projects should be too difficult, either: http://linux-gpib.sourceforge.net/

---

And costs from $550 to $1400... or so See my post...

Quote:

---

Originally Posted by N1LAF

And costs from $550 to $1400... or so See my post...

---

The controllers appear to be the most expensive part of this equation, and I don't see a way around that. However, if the equipment is inexpensive enough, it can still offset the costs of newer gear.

Quote:

---

Originally Posted by N1LAF

Let's say that the new high tech scope is $2500, - $500 for equivalent, older equipment.

---

Did you look at the eBay link I provided?

That $40K is the "used" price. New approaches $200K, depending on the options selected.

$2500 won't buy a high-end instrument of commercial quality and durability. If companies could get by with such cheap investitures they would gladly do it...but...there's simply no replacement for displacement. Or in this case, robustness and careful design.

I treat any instrument I use with the delicacy it deserves. Care to guess how many others don't?

The older Tek and HP stuff was often built to MIL-2000D right out of the box. Today's imported equipment? Riiight. Drop one of those with a spinning hard drive inside and it's gone.

And there's that entire "hard drive" concept in an instrument. Let's also factor in planned obsolescence and an absolute lack of factory support, especially where the newer imports are concerned.

Big business can claim capital expenditures (in whole or in part) as tax write-offs, and can purchase new equipment as it becomes needed. I, on the other hand, cannot.

But we're here to talk about GPIB, not running a business. The thread with graphs and such is somewhere over this way, I believe. ===============>

Quote:

---

Originally Posted by N8YX

Did you look at the eBay link I provided?

That $40K is the "used" price. New approaches $200K, depending on the options selected.

$2500 won't buy a high-end instrument of commercial quality and durability. If companies could get by with such cheap investitures they would gladly do it...but...there's simply no replacement for displacement. Or in this case, robustness and careful design.

I treat any instrument I use with the delicacy it deserves. Care to guess how many others don't?

The older Tek and HP stuff was often built to MIL-2000D right out of the box. Today's imported equipment? Riiight. Drop one of those with a spinning hard drive inside and it's gone.

And there's that entire "hard drive" concept in an instrument. Let's also factor in planned obsolescence and an absolute lack of factory support, especially where the newer imports are concerned.

Big business can claim capital expenditures (in whole or in part) as tax write-offs, and can purchase new equipment as it becomes needed. I, on the other hand, cannot.

But we're here to talk about GPIB, not running a business. The thread with graphs and such is somewhere over this way, I believe. ===============>

---

You might want to check these out...
http://www.tek.com/oscilloscope/mso2000-dpo2000
4 channel, $2400 price range. Does everything that I need to do.
2 channel for $1200

And stuff like this is used at shipyards....

Like I said, GPIB is going extinct. Network aware devices and net appliances is where everything is going, sooner or later. Phone companies know this, so do cable companies.

For the hobbyist, use a PIC microcontroller with serial interface, works fine. Easy to work with. Analog and digital I/O available. AND there is support/devices for network communications and USB interfaces.


Check these out - really cool, easy to use. They really do work well
http://www.pctestinstruments.com/

I think the point is to use a lot of great (and now inexpensive) surplus stuff in a hobby setting where one can have schedule-less fun and learn a bunch without shelling out much coinage.

It does look like there are a pile of options on the GPIB stuff (never studied the protocol m'self, but I bet the hardware interface is butt-simple). Everything from the popcorn processor homebrew solutions (PIC, Arduino) to commercial GPIB-Ethernet adapters like the Prologix (https://www.sparkfun.com/products/8841) are possible from the looks of it. $199 seems pricey for the Prologix. It looks like there are a few experimenters dabbling in this, but not as many as I would have thought.

Do like the Ethernet approach to what you're doing Fred -- adapter on each instrument "bussed" via Ethernet hub/switch. Uh, but not real attractive at $200 per instrument.

Reminds me of my recent pursuit concerning IPX support in Ubuntu.

Start adding up all the cable costs, I expect they will be $35 per cable per device.

Anyways, why not a GPIB to Ethernet using PIC processors? May be cheaper than the cable.....

;)

Quote:

---

Originally Posted by kf0rt

I think the point is to use a lot of great (and now inexpensive) surplus stuff in a hobby setting where one can have schedule-less fun and learn a bunch without shelling out much coinage.

---

Good point.

There is a lot of inexpensive used equipment on the market that one would have found only in top-end design labs of the 80's, 90's and early 2000's. The new equipment is great, but the old stuff does much of what the new stuff does. A few decades ago, it was a big evolutionary step when microprocessors and GPIB interfaces were added to test equipment. The developments that have followed since (such as more sophisticated networking, Internet awareness, Ethernet/USB ports, internal high capacity storage devices, etc.) are important, but in a hobbyist world, they can be addressed in older test equipment by adding external devices connected to the GPIB port. An exception would be cases where large data sets need to be transferred rapidly. The GPIB port is plenty fast for many/most applications, but it's not Gigabit Ethernet!

My old Hewlett Packard 8753C VNA (3GHz, w/time domain option), combined with a 2-port S-parameter testset, cables and calibration kit cost me less than $3K on today's used market (note: I did have to repair a few issues with the equipment). To buy comparable new products, from Agilent, would probably run in the $45K to $50K range. Of course if the thing breaks, I've got to fix it. But, operations manuals, calibration manuals, service manuals and schematics for a lot of old Hewlett Packard, Tektronix and other test equipment are freely available for download on the Internet. Hewlett Packard, now Agilent, has been remarkably open to providing free documentation for their discontinued and obsolete products.

Quote:

---

Originally Posted by N1LAF

Start adding up all the cable costs, I expect they will be $35 per cable per device.

Anyways, why not a GPIB to Ethernet using PIC processors? May be cheaper than the cable.....

;)

---

Needs to be open sourced and nearly free. My impression was that the goal was to do some instrumentin' on the cheap, not become a GPIB egg-spurt. Yeah, it could be done (design and program your own interface), but I didn't get the impression that was Fred's goal.