11-05-2010 03:17 AM
When I try to communicate with a Hameg HMP4040 over PCI-GPIB using VISA I get very often time out error 0xBFFF0015 (VI_ERROR_TMO).
When I start the same Software with the Instrument connected over GPIB-USB-HS everything works fine.
Any ideas what could be the reason for my problem with PCI_GPIB?
(We experienced such an effect that the USB-GPIB-HS makes less troubles than PCI-GPIB with actual NI Software also in the production area with other instruments connected)
Thank you...
11-05-2010 06:54 AM
Hi,
I guess u have to add /n at the end of ur Visa write commands or just try to increase the time node.
Regards,
Pallavi
11-06-2010 04:12 PM
11-08-2010 03:51 AM
Thanks for your response,
I tried now several times, first it seemed to be OK with the 2us Bus timing (in the NI-MAX, for the used GPIB0 (PCI-GPIB)),
but after several test intervals the problems came back slowly (without changing anything) and reached then the previous state of nearly permanent errors - but sometimes it can also work fine for some time...
When I change back to the GPIB-USB-HS everything works fine and makes a rock-solid impression
@Pavalli:
what do you exactly mean with "increase the time node"?
Best Regards
Hansjoerg
11-10-2010 02:37 PM
11-15-2010 02:50 AM
There were just two cables from the gpib card - one to the Keithley 2000 and one to the Hameg HMP4040, both cables about 2 meters long and looking pretty fresh. I used the same cable with USB-GPIB and it worked stable...
My colleague had the same troubles with the PCI-GPIB Card with his setup (using other cables), he uses now only the USB-GPIB-HS ...
greetings from Austria
11-16-2010 09:34 AM
The actual timing on the bus should be the same with the PCI-GPIB or the GPIB-USB-HS, but I suspect that this may have something to do with the latency inherent to USB communication. When you perform a query using PCI, there will be less idle time on the bus between commands than there is when working with USB. It is possible that after you write a command to your instrument, it is not actually ready to receive further commands for some short period of time. Since the USB takes longer to start the next command, that could be why it is working better for you.
Try placing a small delay between your GPIB commands to see if that solves the problem with PCI. A millisecond or two should be sufficient to emulate the delay that would be seen with USB.
-Jason S.
11-17-2010 07:38 AM
Hi, this time I have good news - implementing a delay of 1ms after each write and query command makes the communication working also with the PCI-GPIB.
Thank you Jason, for your explanations - these make sense to me, and the results matches too...
Best Regards,
Hansjoerg
11-30-2010 12:32 PM
I am glad that worked for you. You may check with your instrument manufacturer to see if they have any firmware updates that may solve this problem. It sounds to me like the instrument is accepting messages from the GPIB bus before it is actually ready to process them. Given the way GPIB works, the instrument should be able to refuse to accept any data until it is ready for it.
-Jason
12-06-2010 08:04 AM
I were also in contact with the Manufacturer of the devices and with some effort to get in contact with the right persons - we got now a firmware update (exchange of GPIB-boards to Firmware 2.002), and now it seems to work really fine.
(With the above mentioned delay things were much improved but over a longer observation period I still got some problems)
On the other hand, I discovered now the similar behaviour with our Hoecherl&Hackl PL1540 - heavy communication troubles with PCI-GPIB while USB-GPIB works fine, inserted delays improve the behaviour, but there are still some troubles left...
I will look what this Manufacturer can do for me
Best Regards
Hansjoerg