programs work with ISA GPIB board but not PCI board

[JasonSmith]

Hello Stuart,

I did not see in your response whether or not you have an analyzer card such as the PCI-GPIB+ or the PCMCIA-GPIB+?  This would allow us to see what it actually being transferred across the GPIB bus to determine if the problem is being introduced by your device or by the driver.  My suspicion is that the PCI card is performing the reads at a much higher rate than the ISA card, and your instrument may not be ready fast enough, so is just returning garbage rather than a valid byte.

Some steps that you could take to troubleshoot the problem are as follows:

1. If you have an analyzer card, post a capture an analyzer capture and a corresponding NI Spy log, so we can see what is actually happening.

2. Modify the code to count the number of times the loop iterates in a fixed amount of time.  Run this with both the ISA card and the PCI card to get a general idea how much faster the code runs with the newer card.

3. Try adding a small delay to the loop, to see if this resolves the problem.  You will have to choose a value that will work with your application, but if this is the problem then even a few milliseconds should be adequate.

Please let us know what you learn!

Jason S.
GPIB Software
National Instruments

[sbvande]

Hello Jason

I do not currently have access to a GPIB analyzer card.  I can do an NI Spy capture, but it doesn't tell you much, because of the rather strange format of the data sent to the CAMAC device.  The difference in loop iterations between the PCI and the ISA cards (when a move completes normally) is only about one loop -- eight or nine for the PCI card, nine or ten for the ISA card.  This is for a move of 314 steps, or 1 mm of linear travel in the system.  I tried a delay within the loop, starting at a millisecond, then two, then up a bit at a time until I got to about a half second.  Nothing helped, and the longer delays actually made things worse.

I can add a simple line of code to reject the return value of the camac_read function if it is greater than 4, but there are still problems with the read_position function call which follows.  Delays may help this problem, which is what I'll try next.

Stuart Van Deusen

[JasonSmith]

Hi Stuart,

About the only thing that should be different when using the AT-GPIB/TNT and the PCI-GPIB would be some low-level timing differences on the GPIB bus.  Unfortunately without the analyzer we don't have any way to identify exactly what could be going wrong to cause the PCI boards not to work.

Some things you could try:

1. Increase the GPIB bus timing from the default 500ns to 2us.  This can be done through the GPIB properties in MAX, or by issuing the call listed below after opening a handle to the board:

ibconfig (ud, IbcTIMING, 1);  //ud is the handle returned from ibfind()

2. Ensure that High Speed handshaking is disabled.  Once again this can be done through the properties in MAX, or with the following command:

ibconfig (ud, IbcHSCableLength, 0);


Also, is this is custom instrument that you are communicating with, or a standard mass-produced instrument?   If it is a standard instrument I would recommend that you contact the manufacturer for known issues and to check for new firmware.  If it is a custom instrument I would recommend that you look into purchasing a card with analyzing capabilities so that you have the capability to diagnose problems such as this and make appropriate corrections if necessary.

Please let us know what you find!

Jason S.
GPIB Software
National Instruments

[sbvande]

Hello Jason

I ordered a card with the analyzer earlier this week; it ought to be here next week.  I am currently using the AT-GPIB/TNT card in order to have some sort of functionality with the CAMAC crate.  There are still some problems using this card, but mostly things work (better than with the PCI card).  In regard to your two suggestions, I changed the timing value and it made no difference.  The high speed handshake was already disabled in MAX.

The instrument is a Kinetic Systems GPIB crate controller.  It is actually pretty old.  The original computer controlling the data acquisition was an HP 9816, and everything worked fine.  When we first tried to use a PC with the AT-GPIB/TNT card and the National Instruments drivers ten years ago we had all sorts of problems, and ultimately found a slightly newer version of the crate controller which worked.  We are trying to eliminate the CAMAC instrumentation, which at this point consists only of some stepper motor controllers, counters, and a few digital I/O lines, so upgrading the GPIB crate controller isn’t an option.  We just need to be able to communicate with the crate until we find solutions to replacing the stepper motor controllers and counters.  Had I realized the problems that a new computer and new versions of the National Instruments hardware and software would cause, I would have figured out the stepper motor controller problem first.

Thank you for your suggestions.

Stuart Van Deusen

[Albert.Geven]

I'm pretty sure that the camac crate is not very fast on the bus

For such old systems we not only set the bus timing to 2 uS but also disable autoserial poll

This sometimes comes too fast for old stuff

[sbvande]

I actually always operate with the auto serial poll disabled because of considerations with some of the other GPIB instruments I use.  I just need to keep the crate controller working a little while longer, and the suggestions I've been getting and some of the other things I've been trying are starting to come together.

I've also discovered that some of my troubles result from the computer upgrade itself, going from a 400 MHz Pentium 2 with whatever bus speed to a 3.4 GHz Pentium 4 with an 800 MHz FSB.  There's a lot more speeding up of the system than just the ISA to the PCI.

Thanks for your suggestion.

Stuart Van Deusen

Message Edited by sbvande on 07-14-2006 09:53 AM

[sbvande]

Hello Jason

I finally have installed a PCI-GPIB + analyzer card in my computer.  I captured analyzer and NISpy data when the program worked as expected and when it did not.  Unfortunately, due to the restrictions on the size of posts on this forum, I cannot include the data here.  I continue to have new difficulties communicating with this CAMAC GPIB crate controller (the code is now occasionally timing out when it tries to read response bytes from the controller), and I would like to know what is going on with the GPIB, but I'm pretty sure the problem is with the crate controller itself.  I guess this serves as incentive to replace the CAMAC hardware as soon as I have time.

Thanks

Stuart Van Deusen

[JasonSmith]

Hi Stuart,

If you would like us to take a look at the captures you have, you may contact a support engineer by email through our webpage, and send the attachments to them through email.  Looking at the captures will most likely allow us to identify the cause of the failure, although it may not be possible to solve the problem in the driver if the instrument is not compliant with the IEEE specifications.

Thanks,

Jason S.
National Instruments