gpib command order

[mrbean]

I inherited some code and I'm trying to figure out a GPIB Error I'm getting.  I'm using LabWindows/CVI and TestStand.  I have an Automated Test Stand (ATS) that's connected to a Unit Under Test known as the TSC.  The ATS is running the TestStand gui and is trying to test the TSC.  Both the ATS and TSC have the same controller that has an embedded GPIB card on it.  Through GPIB cables, both the ATS and TSC are connected to a signal generator and a spectrum analyzer.  Not having written this code, I'm trying to figure out why I'm getting an error saying that TSC has sent a "bad GPIB Send Interface Clear command status -99".  Hopefully from the code snippets attached you might see something wrong.  I also have a number of questions at the bottom of the attachment.

[Emilie S.]

Hi mrbean:

First, I can't tell why you are getting the error based upon the code you sent.  There may be a discrepancy in the board addressing which you can check in MAX (discussed later in this post.)  I assume the error is coming from "ibsic (gpibBoard);   /*send interface clear */ line, but since the previous two lines work I can't see why this one does not.  I've listed answers to the questions in your document below.  Hopefully they will help you debug your application, if not, just post again and we'll go from there.

1.  "gpib0" is the proper way to address the board with ibfind.

2.  The ATS (we'll call it the controller from here on out) does not technically know it is "gpib0".  If it is the only board in the system then it is likely this will be correct however, if there are more GPIB interfaces in the computer it could be "gpib1", "gpib2", etc.  You can check what number is assigned to the board in Measurment and Automation Explorer (MAX).  Also, if you right click on the board and select properties you can change the number associated.

3.&4.  The ibfind command was used for the controller to make it the controller in charge.  It is a board level command which is why it addresses "gpib0" (the board).  ibdev is configuring the device, it is a device level command.  In this case the signal generator is the device or instrument that the GPIB0 is going to control.  The first parameter in the command is the board index, which in the case of being connected to GPIB0 will be 0 and the second command is the primary address which is specific to the device.  If you bring up the function panel for ibdev you can see the viable options for these two parameters as well as the others in the command.

5.  I'm not really sure where this is declared but again you can bring up the function panel and right click to get information on the command.

6.  If you are using Windows XP you should go to Start->All Programs->National Instruments->NI-488.2->NI-488.2 Help to learn about these functions and possibly give you some idea of what order you are looking for.  Also, check the manual for the specific instrument you are trying to communicate with.

Regards,

Emilie S.
Applications Engineer
National Instruments
                  
       

[mrbean]

Emilie S.

One thing you said,

"The ibfind command was used for the controller to make it the controller in charge.  It is a board level command which is why it addresses "gpib0" (the board).  ibdev is configuring the device, it is a device level command.  In this case the signal generator is the device or instrument that the GPIB0 is going to control."

However, if you'll notice in the code I sent, every (TCP-IP) message to the TSC ultimately goes to the TSS_GPIB() function.  And, the first statement in the routine is the call to ibdev.  In most cases, it's called with the primary address set to the Signal Generator address.  However, in a couple of other cases, the TSS_GPIB() routine is called to setup the GPIB card in the TSC, and ibdev is called in those situations also.

Should it not be called when controlling the TSC's GPIB card.

[Emilie S.]

Hi mrbean:

I'm not really sure I understand what you mean by TSC or how everything fits into your system.  But in general you will have one controller in charge which I believe is ATS in your case.  From here everything connected to it is a device that should be configured with ibdev.  I'm unclear as to the relationship between the signal generator and TSC or the rest of the system for that matter, but to answer your question, yes it seems necessary to call ibdev for TSC.

Regards,

Emilie S.

[mrbean]

Recall, there are two controllers, each with a gpib card embedded on it.  Each of these cards is connected to the same signal generator.

The main controller does the following, then calls the secondary controller to do some things then returns and does a few more things

Main

gpibBoard = ibfind ("gpib0");

ibrsc (gpibBoard, 1);       /* ATS requests system control */
ibsic (gpibBoard);          /* send interface clear        */
ibsre (gpibBoard, 1);       /* set remote enable           */        
ibonl (gpibBoard, 0);       /* go to standby */

2nd Ctrl

         ibsic (rx_msg.test_data.gpib_data.address);  // controller 2 addr passed in

         device = ibdev (0, rx_msg.test_data.gpib_data.address, 0, T10s, 1, 0);
         ibwrt (device, rx_msg.test_data.gpib_data.gpib_string,  // sig-gen primary addr passed in
                strlen(rx_msg.test_data.gpib_data.gpib_string));

         device = ibdev (0, rx_msg.test_data.gpib_data.address, 0, T10s, 1, 0); // sig-gen primary addr passed in
         ibonl (device, 1);

Main

    /*
     *  Take our GPIB out of standby and tell it to become the active controller.
     */
    gpibBoard = ibfind ("gpib0");
    ibrsc (gpibBoard, 1); /* Get back GPIB System Control */
    ibsic (gpibBoard);
    ibsre (gpibBoard, 1);

1) It doesn't seem like enough is being done at the second gpib controller to prepare it for communication

2) The code reports an error right away during the Send Interface Clear (attempt) by the second controller

[Emilie S.]

Hi mrbean:

ibsic is a board level command, therefore you have to pass the board descriptor and not the device descriptor.  Please have a look at the 488.2 Help manual for help with this and all other functions.  It looks as if you are actually passing the primary address of the device, which is the device descriptor which would likely cause this function to error out.  ibsic should allow the board addressed to take control, as noted in the 488.2 Help.  In the event that you need to use the device descriptor you can use ibpct which is a device level command to Pass GPIB Control.  From the code after ibsic it looks like you are still using gpib0, and the primary address "rx_msg.test_data.gpib_data.address" is the same for ibsic which should be the second controller and the other commands which I assume are referencing the signal generator.  I can't tell how the second controller is being addressed at all or for that matter what it is doing in the code.

Have a look at the knowledgebase I linked above and possibly try the ibpct command and let me know how it goes.

Regards,

Emilie S.

[mrbean]

To borrow the terminology used in the knowledgebase article you sent me, I'll call my main controller the SC (System Controller). If (from the SC) I use the ibpct (int ud) command to talk to the second controller (to make it the CIC) requires the ud (Device Descriptor) of the second controller. 

This is where I'm a little confused.  At the SG, one of the first things I do is a gpibBoard = ibfind ("gpib0");  However, at the second controller, I never do a similar thing.  How does SC know what device descriptor to pass into the call to ibpct.  Currently, I've just been passing in a zero (0).  Somehow the two controllers have to have a different Device Descriptor, right?

[Emilie S.]

Hi mrbean:

ibdev returns the device descriptor.  Therefore, my initial thought is that you should try commenting out the ibsic command, then call ibdev followed by ibpct.  It will look something like this:

second controller = ibdev (board index, primary address of second controller...

ibpct (second controller);

Let me know if this answers your question and helps out.

Regards,

Emilie S.

[mrbean]

I read in the NI-488.2 reference manual, in the IBFIND section, "New applications should use ibdev instead of ibfind.  ibdev is more flexible, easier to use, and frees the application from unnecessary device name requirements."

I'm wondering how to  determine/assign a board index for each of the controllers.  Is this value important, or is the key difference the primary address?

first controller       = ibdev (board index, primary address of first controller...

second controller = ibdev (board index, primary address of second controller...

[Emilie S.]

You won't have two different board indices.  For the first controller you should send ibfind (board index) which you can find in MAX but it is likely 0 if it is the only board in the computer.  At this point this can be the only controller, the second controller is just an instrument with a primary address, this is where you should use ibdev.

ibfind (gpib0);

ibdev (gpib0, primary address of "second controller"...

Ultimately, the answer to your question though, is you can view and change the board index in MAX under devices and interfaces.  The board index is important and necessary to communicate with any instrument.

Regards,

Emilie S.