GPIB command string too long when using a multicore processor machine

[gmandude]

I have an HP 3457A multimeter that I communicate with using GPIB. I have two machines that have identical operating systems installed. CentOS 4.8 (equivalent to Red Hat Enterprise Linux 4.8) with kernel version: 2.6.9-89.0.25.ELsmp.

The first machine has a 2.8GHz Pentium. We have been using this setup for a few years now without any issues. Since the single core processors are going away we need to get our system software working on a multicore machine. So, I've loaded all our software on a new machine with a Core2 Duo. I have only this one odd issue left before I call this experiment complete.

In our code we issue the following command to the multimeter and check for a response:

char *pm_init = "RQS 0;PRESET;TERM REAR;END;LOCK ON;OFORMAT SREAL;";

if (!((er = ibwrt(pm_ud, pm_init, strlen(pm_init))) & ERR))

On the Pentium machine this works just fine. On the Core2 Duo machine the multimeter doesn't respond. If I break this up into two commands like so:

er = ibwrt(pm_ud, "RQS 0;PRESET;TERM REAR;", strlen("RQS 0;PRESET;TERM REAR;")) & ERR

if (!((er = ibwrt(pm_ud, "END;LOCK ON;OFORMAT SREAL;", strlen("END;LOCK ON;OFORMAT SREAL;"))) & ERR))

it works on both machines. However, this is a real ugly fix. Can anyone tell me what is so different about the way the NI driver passes the long string verses the shorter two strings?

Thanks.

[JasonSmith]

The only real difference is that the larger transfer is going to be performed using DMA, where the smaller transfers will not.

We encountered a machine a while ago where the BIOS was not setting up the PCI board to enable the use of DMA. I suspect that you may be encountering the same problem.

We have updated our Windows driver to reconfigure the device to enable DMA, resolving the issue with the system we found. Unfortunately, we do not have an updated NI-488.2 package for Linux which includes this fix. The fix is actually in a shared NI component, so you should be able to obtain it by installing NI-VISA 5.0 for Linux.

Is installing NI-VISA 5.0 an option for you? Also, could you tell me the make and model of the machine you are using?

-Jason S.

[gmandude]

Jason,

Thanks for your response.

I installed NI-VISA 5.0 but it didn't fix the issue. The machine I am using is a custom built system with an ECS PX1 Rev. 1.0B motherboard and a Core2 Duo processor. The hard drive is a 160GB SATA. I looked through bios and cannot find a setting for DMA.

After installing NI-VISA 5.0 I rebooted the machine and still no luck. Do I need to include something else in my source code to access the fix from this?

Thanks again.

Greg

[JasonSmith · Accepted solution]

Sorry about that, I thought that installing VISA would bring along the fix we need, but when I looked back it didn't include a fix for Linux either.

This means that we currently don't have a driver available which will resolve this problem, but there is a workaround if this is indeed the problem you are seeing.

The workaround is to disable DMA for your GPIB interface. To do so, you will need to open a handle to the board, and use the ibdma command to disable DMA. For example:

handle = ibfind("GPIB0");

ibdma(handle, 0);

At this point you should probably keep the handle open until your program is exiting, to ensure nothing reinitializes the board and enables DMA again.

As you can imagine, disable DMA can have some performance impact in your application. If you are performing small transfers, such as would likely be done with a DMM, you are unlikely to notice a performance difference. If you are transferring large buffers, you may experience higher CPU utilization and lower throughput than you would when using DMA.

Please let me know if this workaround allows your program to work, as this will tell us if this is the problem you are seeing, or if something else is going wrong.

-Jason S.

[gmandude]

Hey John,

That has fixed it. Thank you very much for your assistance.

Greg C.