When the CPU is at 100ò0the GPIB can read garbage

[Beltane]

We have encountered problems that when the CPU is at 100% usage, the GPIB will periodically read garbage, rather than the expected data. This only seems to happen on the NT/2000/XP line of drivers. The problem does not occur on Win98. The problem occurs calling RcvRespMsg. Neither ibsta nor iberr indicate there has been a problem.

[NI-488.2 master]

What version of the driver are you using?

Craig A
National Instruments Engineer

[Beltane]

I am using version 2.2 of the driver.

Using NI Spy, I've included the comunications to and from the GPIB. 3015 to 3021 shows the normal pattern of communications that should occur. Thousands of these can occur without a problem, but if the system load is high, it sometimes fails. The failure is shown in 3022 to 3026. Particularly, compare 3019 and 3026, which are the reading of the header from our instrument, before a data block is read. The 10 bytes read in 3026 do not at all contain the data I expect and also not the values to which the buffer is initialized.

3015. SendSetup(0, {0x0002})
Start Time: 16:05:32.156 Call Duration: 00:00:00.000
ibsta: 0x138 iberr: 0 ibcntl: 3(0x3)

3016. SendDataBytes(0, ".........(", 10 (0xA), DABend (0x02))
Start Time: 16:05:32.156 Call Duration: 00:00:00.000
ibsta: 0x128 iberr: 0 ibcntl: 10(0xa)

3017. ibcac(GPIB0, 0)
Start Time: 16:05:32.187 Call Duration: 00:00:00.000
ibsta: 0x138 iberr: 0 ibcntl: 10(0xa)

3018. ReceiveSetup(0, 0x0002)
Start Time: 16:05:32.187 Call Duration: 00:00:00.000
ibsta: 0x134 iberr: 0 ibcntl: 3(0x3)

3019. RcvRespMsg(0, ".......@..", 10 (0xA), STOPend(0x100))
Start Time: 16:05:32.187 Call Duration: 00:00:00.203
ibsta: 0x124 iberr: 0 ibcntl: 10(0xa)

3020. RcvRespMsg(0, "................", 16392 (0x4008), STOPend(0x100))
Start Time: 16:05:32.406 Call Duration: 00:00:00.125
ibsta: 0x124 iberr: 0 ibcntl: 16392(0x4008)

3021. ibcac(GPIB0, 0)
Start Time: 16:05:32.578 Call Duration: 00:00:00.218
ibsta: 0x134 iberr: 0 ibcntl: 16392(0x4008)

3022. SendSetup(0, {0x0002})
Start Time: 16:05:33.281 Call Duration: 00:00:00.109
ibsta: 0x138 iberr: 0 ibcntl: 3(0x3)

3023. SendDataBytes(0, ".........(", 10 (0xA), DABend (0x02))
Start Time: 16:05:33.406 Call Duration: 00:00:00.000
ibsta: 0x128 iberr: 0 ibcntl: 10(0xa)

3024. ibcac(GPIB0, 0)
Start Time: 16:05:33.578 Call Duration: 00:00:00.656
ibsta: 0x138 iberr: 0 ibcntl: 10(0xa)

3025. ReceiveSetup(0, 0x0002)
Start Time: 16:05:34.234 Call Duration: 00:00:00.109
ibsta: 0x134 iberr: 0 ibcntl: 3(0x3)

3026. RcvRespMsg(0, "z4.U..s.u.", 10 (0xA), STOPend(0x100))
Start Time: 16:05:34.343 Call Duration: 00:00:00.000
ibsta: 0x124 iberr: 0 ibcntl: 10(0xa)


None of our software changes between Win98, where it works, and WinXP, where it fails. It is "only" the OS, and I presume, the NI driver that change.

Also, our software has a small layer between the GPIB driver and the main portions of our software. This is because over the years we've used 3 different GPIB cards. Before settling on NI a few years ago, we used the IOTech card. I cannot duplicate the problem with the IOTech card. This leads me to believe that the problem is in the small layer of our code that calls the NI driver, or in the NI driver itself, rather than in the instrument with which we are communicating over the GPIB. The small layer calling the NI driver was last changed in May of 1999, so perhaps there have been changes in how the driver needs to be called or there is a problem with the driver's interaction with WinXP.

Thank you.

[Ricardo_SR]

Hello,

Do you have the same 2.2 version in Win98? Do you have the same program or the same structure in your Win98 and XP machines to talk to the GPIB?
What event do you think should trigger an error for the iberr or ibsta?
Whenever you read wrong information it could be caused by a faulty DMA channel. What you can try to do is disable DMA by doing the following command ibdma 0 in ibic.
Another thing that would be interesting is for you to try directly in ibic to write and read something from the instrument when you have 100% cpu and that way you take out of the equation your underlying software. This way we can check if it is a problem with the driver or just how you are calling it.
Hope this helps

Ricardo S.
National Instruments
.