slow down gpib communication rate

[LD McBain]

I have several programs that have been running on a Windows 95 machine or equivalent (and by several i mean 40-50 unique software packages).  I was instructed to upgrading the computers to new XP machines (amd athlon 64, etc) (upgraded GPIB interface to PCI-GPIB\TNT5004 - they were various flavors of old isa-gpib and a few old pci-gpib cards).  The applications worked fine in the new operating system, except for one thing, I would get timing errors in random places during test (invalid OP code from the HP 6942A multiprogrammer (the device attached to the GPIB interface)- I know this to be caused by the GPIB sending out the commands to quickly).  Now while most places/people would say the solution is to place delays in the code, etc. it is highly undesirable to edit 40-50+ programs (some of which i don't really have ready access to the code anyhow).  I have found a temporary fix by replacing the newer PCI-GPIB card with an older PCI-GPIB card that was available at the time.  However, i do not wish to make this my permanent solution, as i may or may not have control over which GPIB card is installed in the target computers (20+ machines) and i do not wish to relay on obsolete equipment that may be hard to get ahold of in a pinch.  Is there some software (an executable, configuration setting, etc.) solution to this problem that could limit the speed of the GPIB device that could be installed onto the computers?  I have already used the NI software to edit the properties of the device to bump up the timing settings as far as they would go (2usec),  but this proves flaky at best for improving the situation.

[Collin M]

I understand the problem you are having and have a couple suggestions and questions.

Have you done enough testing to be sure that the problem never happens on the older style PCI-GPIBs? These PCI-GPIBs have a few ICs and will have a label that starts with 183617.... The newer PCI-GPIBs have just one IC and have a label that starts with 188513.... All the timings between these two boards are so similar that I am surprised that the old always works while the new consistently fails.

NI does still sell the older style PCI-GPIB and will probably do so indefinitely. You can order the PCI-GPIB for Mac OS Classic and you will get an older (183617...) board but it is the same board that was previously sold for Windows.

It sounds like there is a limitation in your system of a maximum transfer rate. Is there a corresponding limitation of a minimum transfer rate? For example, if the system could be modified such that the GPIB transfers were 10 or 100 times slower would that cause a problem?

Another question, are you certain this is a hardware problem as opposed to a SW problem? You can slow down the software a little by running NI-Spy during normal operation. The GPIB timings between the two PCI-GPIBs should be very similar. When you replace a new PCI-GPIB with an older one are you changing anything else in the system (GPIB cable, PCI slot, ...)?

[LD McBain]

I ran the newer card 5-6 times, and the failure would occur about every other time, in just about the same spot (there is a section of code at that place that has back to back calls to the Multiprogrammer).  After replacing the newer card with the older one, i ran the test 10 times in a row without a single failure.  (the older card # is 183617G-01).

As far as minimum transfer rates, obviously i don't want it to crawl to a snails pace, but 10 times slower shouldn't hurt.  The test set will be attached to live ordinance, so while i could care less about the speed of the test, if something were to go wrong, I wouldn't want it to take a very long time for it to tell me about it.

For the HW/SW issue, I didn't change any other hardware/software when i swapped the cards.  I base that the problem is HW based on the fact that speeding up the transfer rate goobers up the HW.  From what i have been told/read, the handshaking on the GPIB should keep this from happening (I am by no means a GPIB communications expert), but it is known that many equipment manufacturers do not or did not do proper handshaking, thus the equipment can goober up from time to time if you talk to it too fast.  THe standard fix is to add delays into the software, but as i stated before, that would be VERY undesirable.  At the moment, the best fix i can find is to use older cards, cross my fingers, and hope the problem does not occur again (but as I also said before, if the computer breaks down for some reason, they will simply go out and buy the first GPIB card they can get their hands on)  The solution is better than nothing, but hard to control.

Another thing i did try was to use an older driver version (1.7) on both cards.  It did help a bit with the newer card (reduced the frequency of occurance of the problem), but still had no success.

Using N-Spy could help solve the problem, but an issue with that idea is that the people who will be using the software are not the most computer savy people out there, and I can't expect them to do this properly (you would be amazed at how easily an easy instruction can get messed up).

I'm hoping there is some sort of solution where I can implement it now, and not have to touch it again until i reinstall the machine or build a new one.

Thanks

[Collin M]

When a newer card fails does it always fail at the exact same point in the code? If it does this may point to something other than a timing problem. I would expect timing problems to occur randomly. I can't rule out a timing problem though.

Can you try the NI-Spy test? Just run NI-Spy in the background with a failing board and see if the same failure happens.

[LD McBain]

I did the following test:

1. I re-installed the newer PCI-GPIB card (still have 1.7 driver installed).
2. Reran the test as normal to insure that the fail recurred (it did)
3. Reran the test 8-10 times with Ni-Spy running (half w/ data logging on, half w/ data logging off)

with the Ni-Spy running, the failure did not reoccur

The failure is not always at the "exact" spot in the code.  There is two sections where it catches, at the points where it turns on or off certain interrupts on the Multiprogrammer .  It is my belief that the command to either clear or set the interrupts takes a little longer than the standard processes, and so in the case of back to back commands after talking to the interrupt card, this can goober up the Multiprogrammer because it is still handling the previous process.  Thus this is why it only occurs in certain places and not in random places (or so i believe).  Though the failure appears randomly on some runs, but not others.

Thanks

[Collin M]

Ok, that test provides some additional insight. NI-Spy will slow things down at the API level but not at the individual byte level. NI-Spy will introduce a delay proportional to the number of API calls and not the number of bytes transferred. In other words the amount of delay added by NI-Spy to transferring 10 bytes is the same as transferring 10,000 bytes.

My assumption is not that the bytes are being transferred to quickly to the instrument, but that the entire commands are being transferred to quickly. That is why running NI-Spy helps because NI-Spy would introduce a delay between commands but not to individual bytes within a command.

So in summary, I don't think the issue is HW handshaking but rather the device not interpreting entire GPIB commands quickly enough. I think you stated the same theory in your last post.

There may be a global setting somewhere that can help but I'm not sure. Are you using VISA?

[LD McBain]

The programs are written entirely in VB (6.0), and use the GPIB-32.dll.  I believe the interface module for VB originaly came from NI.

[Collin M]

Can you try setting re-addressing through the ibconfig IbcREADDR option? This will cause the GPIB controller to readress the bus after each transfer. This has the effect of adding a significant delay between commands to the instrument. If this works it will need to be done for each program, but will only need to be done once in each program.

Message Edited by Collin M on 10-30-2006 01:16 PM

[LD McBain]

Good idea, but the problem with that is that as far as i can tell, that option can only be set from within the software (I could be mistaken), and:

a) i have 40+ executables (which take a LOT of effort to change... update documentation, do demos, do prove-ins... all very costly and time consuming)

b) i don't have the source code to edit for all of the programs in the first place, thus editing the code (even one line) is out of the question for 60-70% of the software.

The fix must be made without changing the source code or recompiling the programs.  Is there a way to permanently change the ibconfig settings externally to software that I am unaware of?

Thanks

[GPIB_Guru]

How do the programs work? Do they use ibdev or ibfind for the device handle? You can run NI Spy in the background to try to answer it. If you use ibfind than yes, you should be able to make the change externally. If no, then not much luck I am afraid.