GPIB communication issue with multiple instruments

[Jpdas06]

We have an old program written using Modula 2 running on a windows 98 computer. I am working on rewriting the software in LabView to get rid of the old hardware, specially the ISA slot cards and win98 computer. The Modula program controls a mass spectrometer (MS) through GPIB interface. The MS control  rack has a multiple interface unit that is connected to computer via GPIB. The primary address is '3'. There are three other units that are connected to multiple interface unit. The Modula 2 program controls these units via multiple interface unit using different GPIB commands. For example one unit is controlled using $OMWxxx... (Array of 8 characters) while other unit is controlled using $OFJx....(Array of 13 characters) In LabView, when I use $OMW command it works as expected but $OFJ command does not work. Accidently I was once able to execute a $OFJ command after resetting units and computers, but now i am not able to reproduce that path. Also, reseting instruments all the time is not the solution. Am I facing the issue because I am not using secondary addressing? The manual says that the unit controlled by $OMW has secondary address: 1101011 while $OFJ has SAD: 0110101. Modula use following command structure: WriteStringGPIB(3,13,EOI,OfjString); or WriteStringGPIB(3,8,EOI,OmwString). I understand that EOI is end of interaction and suppose to reset GPIB communication everytime it is run? I don't see any secondary address part in Modula code. It only uses '3' as address. I don't have to use these instruments in parallel. I only need to use them in certain sequence to get the work done. Thanks in advance for your time and suggestions. 

[Blokk]

Huh, looks complicated, and I do not have any experiance with Modula. However, I was in "similar shoes" a few years ago. We had an old calorimeter with two Keithley units connected to a PC with an old GPIB ISA interface, as you have. We had a closed-source app running under DOS, and we had some idea how it controls the system, but there were still some unclear parts.

What I did, I purchased a GPIB+ interface from NI, the "+" symbol means it is not only a controller, but also an analyzer (I have got a PCI version, but you can get the same with USB: http://sine.ni.com/nips/cds/view/p/lang/en/nid/212429 ).

I just hooked up another PC with this GPIB+ analyzer card to the old existing and running system. I was able to capture the live GPIB commands, so we were able to figure out some important things how that DOS program controlled the calorimeter, thus we were able to recreate the whole thing using modern PC and LabVIEW...

So you migh try to "listen into" the communication using the NI GPIB Analyzer: http://digital.ni.com/public.nsf/allkb/848F027883BD6429862571B8001DFEDC

Edit: so the idea of such GPIB+ analyzer interface is that, you can connect it to an existing GPIB network, without disturbing its communication. Practically you can "spy" into a running GPIB network...

[Jpdas06]

Thank you so much for the reply. Your idea is execellent. I made a mistake when I purchased GPIB-USB-HS. I shoud have gone with +, but thought that since I have source code I will not need analyzer!!! 

[Blokk]

Well, if you have the source code, it should be easier, but I migh imagine there are things in that old Modula code which are not really clear. Or, there is some special timing which is not clear from that source code. Whenever it is possible, it is really recommended to use official GPIB higher level drivers, and not the low level ones. But I understand you do not have such drivers with this old MS...

So keep in mind, timing can be an important point when you have to create a low level GPIB driver! Try to insert certain waits between GPIB Write/Read commands, etc... I am not really sure how easy or hard to see GPIB command timing info with that NI Analyzer software, I used it many years ago...

[Jpdas06]

Thanks again Blokk.

I would like to add that the PAD for GPIB-USB-US controller is '0' and the multiple interface unit has a PAD of '3'. This multiple interface has different cards in the slots that are used for controlling 'system analyzer (SA)' and 'magnet supply (MagS)'. The GPIB command that starts with $OMW is meant for SA and $OFJ is meant for MagS. As I mentioned the binary address for SA is 1101011, and for MagS, it is: 0110101. I have attached a diagram explaining above.

I used interactive control from MAX, and when I find for listeners, I get 2 listeners at PAD 0 and PAD 3. 

The binary addresses for the SA and MagS are not used by me as i dont understand what it means, I thought them as secondary address but why in binary? The souce code at open place mention MYGPIBAddr = 21; defined as constant, but not used while writing a string to gpib.

[Blokk]

I feel this might be a very involved "detective work", and I do not feel smart enough to help from distance. Someone might jump into this post, and give further hints... With that analyzer card you could figure out what kind of formats are sent and to which addresses. But I only know the very basics of GPIB protocol, so I cannot be a good help here... If I got into a similar situation I would start some serious readings about how GPIB works in more depths, and then going forward. I am pretty sure you already know more about GPIB than me...

[Jpdas06 · Accepted solution]

I have a solution. I used NI 488.2 GPIB functions instead of VISA. What was missing is triggering the GPIB instrument. I put simple sequence of clear - trigger - write and then commands started working!!! Thank you Blokk for your suggestions and I hope that the discussion here will help others in future.