GPIB Analyzer data analysis

[tboydva]

I am trying to "reverse-engineer" an antiquated piece of equipment (ion trap mass spectrometer).  The device is at least 12 years old and the custom-written software that drives it runs on a 25 MHz PC (no faster due to the timings).  I have read through the NI-488.2 GPIB Analyzer user manual and an HP tutorial on GPIB (or HPIB).  I hooked my GPIB+ card onto the bus and set the analyzer to monitor the data over the bus.  My plan was to do some of the simple tasks with the computer (set the temperatures, monitor the turbo pump speed, etc) individually, then observe the "talk", catalog it, and put together a rudimentary program that keeps this instrument running after the PC (running for the past 13 years straight) gives up and dies!  I set my GPIB+ device number to 15 and I can see what I believe to be the computer and instrument "talking" - TA1 followed by LA2, then TA2, then LA1.  The problem is, I don't really see anything else that "looks" like data being passed back and forth?  Generally it's only one or two characters followed by 00000000 on the data lines.  I thought perhaps the data are being sent binary?  From what I can tell, there should be a # in the beginning of a data stream to annotate binary transfer?  Perhaps I'm capturing with incorrect settings? 

It appears that many of the members here really understand what the control and data bits mean (better than I can hope to acheive).  I've been spinning wheels now for a couple of weeks trying to determine what I should do next (or what I'm doing wrong).  Anyone able to give me a shove in the right direction?  I can post one of my capture files if it's helpful.  Thank you in advance.

[Collin M]

The GPIB commands TA1, LA2 and so forth are encoded on the same physical 8 data lines that carry the instrument specific data between the PC and instrument. That tells me that the analyzer seems to be correctly interpreting the activity on the GPIB.

Maybe the data you are seeing is actually correct. Have you tried to duplicate the exchanges in ibic?

Do you have the original source code for the program or a programming manual for the instrument?

Also, when you see the couple of characters followed by 00000000 in the analyzer capture, does the instrument behave as expected?

Posting some analyzer captures may be helpful.

[tboydva]

dittohead, thanks for the rapid response!  I got the impression that the computer and instrument are communicating to as there seems to be regular "talk" (i.e. the TA and LA coming through).  If I look at the detailed information from the capture, there are usually 10 lines of "return" data from the instrument to the computer.  When the computer talks to the instrument it is either 10 lines or 20 lines.  It's unclear to me at this point if the instrument is "asked" to report back everything (and the pertinent info has to be teased out), or if it is only asked to report back specific information.

Unfortunately, the programmers, source code and any other information has been "lost" for this product.  The main problem is that the MS is part of a custom-assembled instrument which has a number of interfaces - essentially it isn't replaceable (at least not without $$$$). 

Right now, I'm afraid to "send" any codes to either the computer or MS for fear of causing catastrophe!  I really just wanted to try and understand the "language" being communicated before sending anything to trash the system!

The instrument behaves exactly as intended when controlled by the original system.  Again, I'm trying to snoop on the bus and figure out what the two devices (computer and MS) are saying to each other - so that I can write some code to do it using Measurement Studio (i.e. the GPIB tasks). 

I am attaching the capture file for the MS shutdown.  This should contain information relevant to the compuer telling the instrument to reset 4 different temperatures and shut down a turbo pump.  The four temperatures and the status (speed) of the turbo pump should be sent back to the computer (which displays this information to the user).  As far as I can tell, the instrument is "saying" only about 4 things: R.v.......       R.u.......        R.0........       and          R./.......              (had to separate using lots of spaces - the dots are all zeros on the data lines).  It just seems that there must be something missing as each temperature is a 3-digit number and the turbo speed is 2 digits.  Doesn't seem like enough information??

OK, here's the file - hopefully I'm interpreting or capturing incorrectly!  Thanks again.  BTW, it won't allow me to upload a *.cap file, so I'm changing the extension to *.txt

[Collin M]

I agree there doesn't seem to be lots of unique data being transferred.

Is it possible to do a simpler sequence? By that I mean just trying to do one thing (clear a temp or shut down a pump), and nothing else?

Also, do you see a lot of GPIB activity when no command has been issued from the PC? You might just be seeing periodic polling and not the actual instrument commands.

[tboydva]

Well, I've been trying to think of a way to "see" simpler commands.  The stuff you're seeing is exactly as you suggest (I think) - constant polling.  This happens if the instrument is just "sitting."  I've been trying to figure out if there is a way to not capture the polling and capture "real" events or returning data.  I tried doing a more specific task, but the data still seemed pretty minimal (I got the following ...@...).  Are there any settings on the control lines that will only allow certain "events" to be captured?  As far as I can tell, the NDAC and DAV lines are high all of the time in my capture files?  Are there any capture settings that would be best for this application?  I didn't mention, but this instrument is 488 - not 488.2 (I think).  In the capture settings I have it only set for Data Transfers and Command Transfers.  Triggering and all other settings I have left as default. 

Do you think it would be worthwhile to let the instrument sit and capture background polling information, then try to tweak the settings to make sure that doesn't get captured (although the TA and LA would get lost too?)?  I'll try shortening my capture duration and see if I can time it with sending single commands to the instrument. 

I should have known this would be harder than it seemed!

Thanks.

[Collin M]

In the Settings controls you can set the analyzer to trigger only on a certain data byte. It seems that the polling only uses a very small number of distinct data bytes. It looks like there is never an ASCII number sent across GPIB during polling. You could try triggering simply on the ASCII digit 0, for example (not the hex value 0, but the ASCII code for 0 which is 0x30). Or you could trigger on some other digit the instrument returns and is displayed on the PC. Remeber to use the hex value of the ASCII encoding, not the actual number in the trigger settings. So if you want to trigger on the number 7, you would enter the 0x37 in the trigger condition settings. Of course this assumes the data being sent by the instrument is ASCII.

[tboydva]

OK, had some leaks and had to shut down the instrument and fix it!  I was going to try your suggestion but I'm a bit confused.  To trigger on a particular number, you indicate I should put the ASCII value in as the trigger condition.  I am attaching a jpg of the aquisition conditions.  Would this be correct? The settings window only allows binary numbers in each of the data lines (i.e. 0, 1 or x which I guess means either). 

I tried the conditions in the settings window attached and I still get mostly polling streams.  Sorry to be so obtuse!  I think if/when I achieve a breakthrough this will be much easier.

[Collin M]

The configuration in the screen capture is correct for the data, but you also need to add the trigger condition of DAV (data valid) being a logic 1. A byte will only be transferred when DAV is asserted. This will cause the analyzer to trigger when it detects the byte '0' being sent over GPIB.

After the trigger, the analyzer buffer should be full of data. The trigger point is set up for midway through the buffer, so the transfer of byte '0' will be in the middle of the capture.

Are you able to find the particlaur byte you captured? If not, you could try reducing the 400,000 capture events to 10 or 20 to make interpreting the data easier.

[tboydva]

Dittohead, I think I got the capture settings in order.  It looks like I'm capturing the same information under these settings, but I did play around a bit and at some point, I was getting a much larger transfer from the instrument to the computer (about 100 lines or so).  Almost all of it was nothing (i.e. 00000000 or a "." in summary view).  Perhaps this is the instrument response to a request for data?  It also seems as though the instrument always responds with an ASCII R.  Is it possible that the R and any following characters tells the computer what information is to follow?

Right now I have the computers on a switch box and I think it'll be necessary to get the listening system onto a new monitor and keyboard so I can press capture, perform an operation (on the control computer), then stop capture.  I hope that'll allow me to capture just the events I'm interested in - instead of pressing capture, then switching over, performing an operation, then switching back and stopping the capture.  It seems that there is relatively constant polling between instrument and computer.

Now that I've been "working" on this, I'm going to try reading the GPIB analyzer documentation again - there are some examples that didn't mean much to me before I started this.

Here's an opinion question - given what you've seen of the capture file and my limited abilities - is there any hope?  Seems like most who work on these issues (in this forum) develop the skills.  I'm a soft-money researcher with limited time and resources.  If this computer (running for 12 years straight) dies, my mainstay analytical tool will be sidelined.  I've pieced together another 386, but for whatever reason, I can't get it to work with the GPIB card and serial communications.  In my experience with programming and electronics, once you get a feel for how things work, you can learn rapidly.  Perhaps the lights will come on!

THanks again for all the help.

[Collin M]

It sounds like you are on the right path and making progress. I think the key is going to be finding the trigger conditions for the various messages to and from the instrument.

One thing I should point out is that the trigger position by default is set to the middle of the capture. This means that the byte you trigger on will be halfway through the capture. You can change this in the analyzer settings.

I'm not sure what the significance of the R is. Since the analyzer correctly determines the listen and talk addresses I would assume it is set up correctly and the data you are seeing is the actual data on the bus.

Is the only reason you are doing this to move the GPIB controller to a different PC? If so, it may be less effort to get that setup working than to reverse engineer the software.