Compatibility of GPIB-1014-EH-D and GPIB-PCI

[Andy2358]

I have a legacy system that has a dual ported GPIB-1014-EH.  The instrument it has talked to for 20 years needs to be retired.  The new device does not have a GPIB interface and the lagacy system does not have anything but the old GPIB interface available... so we have purchased a new PCI GPIB card from NI and built up a computer to translate between the GPIB bus and the new device.

When we hook the legacy system up to the new device, the system will run for a short while and then the old system goes out to lunch.  It appears that the kernel on the legacy system starts consuming all of the CPU time starving all other processes.  This suggests a device driver is consuming the CPU.  When we switch back to the original device, the problems go away.

We currently suspect some kind of incompatiblity between the new card and the old one that are trying to communicate over the bus. 

In case it isn't obvious, the old card supports 488, but the new card supports 488.2.  I imagine this could be a problem, and could be a software or a hardware problem.

I should also note that the device has two GPIB ports and that each of the two ports is on a dedicated GPIB bus.  In other words, there are two GPIB busses and we have two PCI GPIB cards in the same computer, one on each bus.

The legacy system is running HP-RT 3.0.  The driver on that side is a custom driver that has worked flawlessly for 20 years.  The new PCI 488.2 GPIB card is installed in a new computer running SUSE linux and we are using the NI driver and library.  I don't have the version handy, but we selected the OS from your supported list.

Thanks for any help,

Andy

[TBirkulosis]

Have you tried updating the legacy system with 488.2 drivers? It may be a good idea to back up the legacy system and make changes to a copy. What version of LabVIEW are you using? What driver are you using with the new card and what verions is it (e.g. NI 488.2 3.1.2)?

[TBirkulosis]

Do you know if certain VIs or functions are causing the program to hang, freeze, or crash?

[Andy1357]

Upgrading the legacy system is not an option.  The new device is required to meet the original interface. But I do have a question regarding this: you only suggest upgrading the driver (not the hardware) to 488.2 on the legacy system.  Do you mean to suggest the old board would support 488.2 if it had the right software and that there is no difference in the hardware required?  What is the difference between 488 and 488.2?

I believe we are using the NI-488.2-beta-2.5.1b0 on the new side.  We are not using labview.  This is one nstrument being controlled by a large realtime embedded control system.  Not sure what a VI is.  The communication protocol is a simple command-response with the messaging defined by the manufacturer of the original device we are replacing.

Does 488.2, or the driver or ni library we are using impact the messaging? Is there different or addional handshking?  Has the specification of messages (such as termination character) changed or been refined since the original 488 spec?  Have there been any changes to the 488 standard that might impact electrical characteristics of the bus?

Andy

[TBirkulosis]

The new device should be backwards compatible with 488.1 messages, but I don't believe the old device will be able to use 488.2 messages. You can see what devices are compatible with NI-488.2 2.5 Beta on the driver website. PCI-GPIB is compatible, but GPIB-1014-EH is not.

Upon searching for differences between 488.1 and 488.2, I found this discussion forum thread. This may have information you are searching about the communication between the old and new device. It appears that 488.2 expanded on 488.1:
http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/A-list-of-differences-between-IEEE-488-1-and-...

We also have a Real-Time Measurement and Control board in discussion forums. They may have more insight about real-time instrument control. Personally, I have experience with LabVIEW and some Visual Studio for instrument control. Just thought this may be useful in the future:
http://forums.ni.com/t5/Real-Time-Measurement-and/bd-p/280