programs work with ISA GPIB board but not PCI board

[sbvande]

I had the question below posted in the GPIB message board and it was suggested that I post it here as well.  Additional information:  the old projects are being run in the CVI 8 environment with the run:debug program method.  Any help will be appreciated.

I am replacing a 10 year old Win95-based data acquisition system with all new hardware and software.  The old system used LabWindows CVI 5 and an ISA AT-GPIB/TNT plug and play board, with ver. 1.6 of the NI-488.2 software.  Everything worked fine.  The new system is WinXP SP2, with the newest CVI 8, the newest NI-488.2 (ver2.46) and Measurement and Automation Explorer, and a brand new PCI-GPIB board.  After installing all the new stuff, I ran some of my old programs to control instruments over the GPIB.  Things sort of worked, but there seemed to be some timing issues, with the code thinking it was getting return values from the instruments before they were actually sending the values.  None of the termination or any other settings for the board in MAX had any effect.  I tried putting in an older PCI-GPIB board, of almost the same vintage as the ISA board.  This made no difference to how the programs ran.  I finally put in my original ISA board.  (All three boards were using the same v2.46 of NI-488.2, and all were configured as GPIB0 in MAX.)  With all the same default settings in MAX as for the PCI boards, all of my old programs worked with the ISA board.  I wrote the code a while back so I may be a little foggy on it, but I don’t recall needing to put in anything identifying the board as ISA.  Can anyone suggest why this is happening?  I’d really like to be able to use a PCI version of the GPIB board, but I’d also like things to work.  I haven’t written any new-from-scratch code yet with all the new hardware and software, only tried to run the old stuff.

Thanks in advance.

Stuart Van Deusen

[J.Harv]

Stuart--

     I have seen this before.  The PCI standard is much faster than the ISA standard.  So with the new card, it will issue the write to your instrument much faster.  Your instrument is still the same speed though.  So it will return the data in the same time as usual, but becuase your write took a little less time, the read will happen a little quicker and could be missing data. Which will give you a timeout error or just wierd behavior.  This speed difference is why the program still works fine with the ISA card, you must have a well-written finely tuned program there and the speed difference is an issue.

   The fix is to increase the time between reads and writes, or the timeout value.  Try that and let me know if you have any questions.

Regards

John H.

Applications Engineer

National Instruments

[MJF]

Is this actual bus timing between signals or is it simply the speed with which messages are put on the bus?

Is there some way to slow the operations down?

[J.Harv]

There is no way to change the speed of the bus.  I'd focus on the timing within your application.

John H.

Applications Engineer

National Instruments

[sbvande]

I'm going to paste in some LabWindows CVI code, then I'll explain what the program does.

float read_position (void)
{
 fillnaf (2,0,0);      
 pos_counts = camac_read(crate, naf);   

 position = (pos_counts + 32768) / 314.0;
 SetCtrlVal (panelHandle, PANEL_CURRENT_POSITION, position);
 if (!slewFlag) SetCtrlVal (panelHandle, PANEL_SLEWPOSITION, position);
 ProcessDrawEvents ();
 
 return position;
} 

int move_it (int delta)
{
 moveFlag = 0;
 fillnaf (7,0,16);
 camac_write (crate, naf, delta);
 fillnaf (7,12,1);
 SetCtrlAttribute (panelHandle, PANEL_STEPMSG, ATTR_VISIBLE, 1);
 while (moveFlag == 0) {
       moveFlag = camac_read (crate, naf);
       ProcessSystemEvents ();
       }
 SetCtrlAttribute (panelHandle, PANEL_STEPMSG, ATTR_VISIBLE, 0);
 if (moveFlag > 1)  end_limit (moveFlag);
 read_position ();
 
 return moveFlag;
}

void camac_command(int crate, char naf[])
{
 ibwrt(crate, naf, 3);
     if (ibsta & 0x8000) {
         iberr_msg = gpib_error ();  
         on_error (iberr_msg);
         }
} 

void camac_write(int crate, char naf[], int instruct)
{
 unsigned char message[3];
 char *ip;
 
 ip = (char *) &instruct;
 
 message[0] = *(ip+2);
 message[1] = *(ip+1);
 message[2] = *ip;
 
 camac_command(crate, naf);
 ibwrt(crate, message, 3); 
  if (ibsta & 0x8000) {
        iberr_msg = gpib_error ();  
        on_error (iberr_msg);
        }
}

int camac_read(int crate, char naf[])
{
 int answer = 0 ; 
 unsigned char message[3];
 char *ip;
 
 camac_command(crate, naf);
 ibrd(crate, message, 3);
  if (ibsta & 0x8000) {
        iberr_msg = gpib_error ();  
        on_error (iberr_msg);
        }
 
 ip = (char *) &answer;
 
 *(ip+2)=message[0];
 *(ip+1)=message[1];
 *ip    =message[2];
 
 return(answer);
}

The purpose of this code is to operate a stepper motor and read its position.  The stepper motor controller and the counter are modules in a CAMAC crate.  The naf commands tell the crate which module is to be addressed, and what the specific command to that module is.  The camac_write in the move_it function starts the motor moving.  The stepper motor controller has a status byte which is then read by the camac_read in the loop.  The returned byte can be zero, meaning the motor is still moving; 1, which means the move is complete; or 2 or 4, which mean the motor has hit either end of its travel limits.  The problem I'm having with the PCI-GPIB card (which doesn't happen with the ISA AT-GPIB/TNT card) is that during the move the card will intermittently pick up a garbage value (typically a seven digit integer) which kicks out of the loop and causes the position to be read before the end of the move.  This happens during any iteration of the loop (I can watch with NISpy to see how many times the status byte is read before the loop is exited).  I don't claim that this code is the most elegant way to perform these operations, but the question is, why does this happen with the PCI card and not the ISA?  In both cases, the GPIB is simply reading a status byte.  It doesn't seem that timing should be an issue.

Thank you for your help.

Stuart Van Deusen

[MJF]

I have no idea why you would get a garbage value, but one thing I would suggest is checking the returned data for a valid value before deciding what to do with it. I know this does not address the underlying issue but it could be a workaround that helps you get the problem under control.

The only other thing I can think of is to maybe try slowing down the speed at which you are polling things. Try putting in a delay of a few milliseconds to see if that helps.