TNT 5002 EABO ERRORS

[palatini]

Hi guys..I hope that you can provide some insight into this:

I have a TNT5002 interfaced with a microcontroller and am experiencing some erratic behavior

from this device.

I am using a NI GPIB card and get an EABO error approx 50% of the time when I perform a

scan for instruments via the NI software.

When I communicate with the device directly I get the following:

         If I perform queries to the device (an ibwrt followed by an ibrd) I get 100% success and no errors.

         I can successfully write only one command as the second ibwrt gets an EABO error.

I have attached NI spy images.

I am interfacing to the device as follows:

The micro checks the ADSR register and actions on the Listener Active & Talker Active bits

For Listening the 5002 is configured for:

  CFG register:  rcv and 8 bit 

  CNT1 and CNT0 registers are loaded with FF and 01   (2's comp of 255 bytes)

  EOSR register is set to CR
  AUXRA register is 0x0006   (holdoff & End On EOS)
  AUXMR register is 0x0003   (release holdoff)
  CMDR register is 0x0010     (reset FIFO)
  CMDR register is 0x0004     (GO)

  The system then loops and reads the FIFO while the STOP bit is 0 and NEF is 1

   IO Cleanup is done by:

   CMDR register is set to 0x0008 (STOP)
   AUXMR register is set to 0x0055 (CLR_END)
   AUXMR register is set to 0x0057  (CLR_ERR)

For Talking the 5002 is configured for:

  CFG register:  xmt and 8 bit 

  CNT1 and CNT0 registers are loaded with the 2's comp of the string length

  CMDR register is 0x0010     (reset FIFO)
  CMDR register is 0x0004     (GO)

  The system then loops and copies bytes into the FIFO then waits for the DONE bit to be set

   to ensure all the bytes were transferred

   IO Cleanup is done by:

   CMDR register is set to 0x0008 (STOP)
   AUXMR register is set to 0x0055 (CLR_END)
   AUXMR register is set to 0x0057  (CLR_ERR)

any ideas or help would be greatly appreciated

[Meghan R]

Hi palatini,

Your issue would be better handled by emailing National Instruments support via Request Support. 

Thanks!

Meghan
Applications Engineer

[Steven_T]

palatini,

Can you tell what your instrument is doing when these transfers occure?  It looks like your instrument is detected (address 10 in one of the captures), but it does not respond to the *idn? querry.  Can you tell if the data transfer of "*IDN?\n" ever makes it to your instrument and out of the FIFOs? 

If you have an analyzer card (PCI-GPIB+) for analyzing the commands, bus control lines, and handshaking lines, we could tell if the *IDN? data ever makes it onto the bus.

You should probably add debug lines into your instrument firmware so that you can tell what is happening on the instrument.

I hope this helps,
Steven T.

[palatini]

Steven,

I've been banging at this for a few days now.   I added flags to my firmware to see what is happening and switched from

polling the ADSR register to using interrupts on address state changes.  I can trap the *IDN? on an ibwrt and confirm that

it is getting read correctly by my device.  However responding to the subsequent ibrd seems to be quite a mystery.

Lance 

[palatini]

still working on this...my gosh I practically have the manual memorized by now

i switched to polling on the LA and DO signal based on a thread that was on this forum 

anyhow an ibwrt followed by an ibrd (like an *IDN? query) works fine (LA and DO bits

are correctly asserted) and is repeatable

but multiple ibwrt commands have strange behavior......i believe that an initial LA is asserted

but instead of reading correctly and returning ..the FIFO just fills up the 16 bytes on

the next few ibwrt commands then yields an EABO error

I have to check if the ibwrt is really adding the correct EOS char on each write

(I had checked that option on the PC software but probably need to verify)

[Steven_T]

Hello Lance,

I'm assuming you mentioned the check boxes in the termination properties on your NI-GPIB interface card.  These settings do not automatically append the termination character (EOS) onto the string you are outputting.  This just configures the card to stop reading when EOS is detected (only affects the the interface when it is listening).

This is probably your problem.  Let me know what happens.

Steven T.