NAT7210 to host data transmission problem

[Lunatic]

It would help alot if you could send the scope measurements!
Examplecode for which platform/programming language?

[MaSta]

We did no scope measurements so far. My understanding of GPIB is not deep enough to know what's right and what's wrong on the bus, because as a programmer of the GPIB chip I don't care about the bus signals. This was the part of the hardware developer. Afaik, the GPIB is not sensitive to the usual noise and distortion.

Programming language actually doesn't matter, but it's C in this case.

I've searched with Google for "NAT7210 example code" and similar, but to no avail. I would like to compare an example initialisation routine (we followed the instructions given in the NAT manual very strictly) that is tested to work 100% with ours, also an interrupt routine.

FYI: we are receiving the NAT chips from a german distributor, which is supposed to help us in this case. But they also seem to have problems finding a solution. I mean, it looks like the bus traffic is distorted, but then it should have been ever since and we would have realised that earlier. We didn't change anything on the hardware in the past years, except switching from CB7210 to NAT7210. With this, we also changed the init routine a little, in order to match the requirements of the NI chip.

[Lunatic]

Please talk to the hardware developer, and try to get some measurements of the bus. The GPIB bus may be very stable, but there's always a point where it's not tolerant enough... Some scope measurements would really help to localize the error!

Have a look at this link, it describes the limitation of cable length for GPIB cables to work properly:

http://digital.ni.com/public.nsf/allkb/CD66538B9541F474862570820047B175?OpenDocument

The NAT7210 actually has no buffer, and therefore can't flush it.

[MaSta]

I found that the SRQ line was set by the 7210 because of serial polls from the CIC.

What I can't understand is why the CIC sends serial polls during an ongoing data transmission. Crappy IEC 625 bus...

With the SPEOI = 0, the error occurs not so often anymore, but still occurs. I need to find out, why the controller asserts SRQ.

[MaSta]

Update:

The config drives me mad. I did not set 0xA as EOS byte for the controller, so the user can use either LF, CR or CRLF as end token. The end token as used by the user is also used by the controller at the end of reponses. 

But when testing the *IDN? query with the NI communicator, the NI communicator send 0xA at the end of the string, though the EOS byte is 0 by default.

Only if I set the EOS byte to 10, I can hardly make the error happen again. In any case, if the error occurs, SRQ line will be asserted by the 7210, either permanently or for some milliseconds. This disturbs the data reception of the CIC. 😞

[MaSta]

Update 2:

The 7210 randomly asserts the SRQ line and does not unassert it. Serial polling is enabled, parallel polling diabled. So if the CIC send the SPD command (serial polling disable), the 7210 should unassert SRQ. But it does not everytime and then SRQ is locked for other units on the bus. This is another problem I have to solve.

SRQ can then only be reset by *RST command.

[MaSta]

Update 3:

I wrote a small LabView test VI which queries *IDN? every 100ms and watched the SRQ line on an oscilloscope. What I saw made me loose my faith.

The SRQ was asserted and unasserted in irregular intervals and also for irregular periods. When the test stopped, SRQ was unasserted.

This may be normal, but not according to the 7210 description where SRQ is used to request service from the CIC.

My firmware does not request service via SRQ line, so how can it be asserted?

[MaSta]

Update 4:

I'm using a NI chip and a NI PCI GPIB board and NI software.

When I restart the 7210, the SRQ line is unasserted. Then I start the MAX, going to GPIB devices and use SCAN FOR INSTRUMENTS.

My instrument is found and the IDN string is displayed. The SRQ line remains unasserted.

Then I click SCAN FOR INSTRUMENTS again, the instruments is found and displayed. But now the SRQ line is and remains asserted. 

What is going wrong here? NI, please help!

[MaSta]

Final words:

Using "Scan for instruments" twice or a lot of *IDN? queries put the controller into a state where it ramdomly asserts SRQ when transmitting data.

The test VI was running a test for about 3 minutes and the error only happened one time. 

When I made single tests with that test VI, just sending *IDN? one time, I could see the SRQ line being asserted and unasserted like 50 times during the data transmission of a 70 byte long IDN string.

It may still be a software error in the chip setup or interrupt handling, but now I need to contact NI support. We are using these chips for quite a while now and it seems

this has been there ever since, unnoticed. It may not disturb the normal GPIB function as long as service requests are not used, but if they are used...

[MaSta]

Bumping this old topic because the problem has still not solved completely. It was only ignored or somehow neglected. The fact is, you may use SRQ or not. When trying to use it, the NAT7210 guide tells you some things and misses a lot. Meanwhile, mostly due to customers reporting problems in connection with other devices on the GPIB and coming from the SRQ signal, we found out that the microcontroller was programmed to request service whenever there is a change in the STB. But, requesting service and thus setting the RSV/RQS bit that asserts the SRQ signal can happen anytime. While the device is talker or listener. It turned out to be very bad to request service while the device is talker AND is talking, means transmitting data. Since data transmission is interrupt based, this can happen. I found nothing about the condition when SRQ may happen, perhaps it's only written in the IEEE488 standard. In the NAT7210 manual, it is not.

So, by blocking SRQ generation while being talker, the device does not distort its own data transmissions anymore. However, setting RSV bit and asserting SRQ should cause the host to do a serial poll and, as described in the NAT7210 manual, the PEND and RSV bits are to be reset automatically after the poll, so that the SRQ signal should also unassert automatically. But when watching the SRQ with an oscilloscope, it does not unassert again, which makes me think the service request was not served.