<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><META content="MSHTML 6.00.2600.0" name=GENERATOR><STYLE></STYLE></HEAD><BODY bgColor=#ffffff><DIV><FONT face=Arial size=2>Hello All,</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>This is an FYI:</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>This problem has been corrected by uninstalling the National PCI GPIB card and installing the Agilent 82350 card.</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>NI card setup was checked, showing no problems. Bus analysis with the NI card installed showed no corruption, but the Keithley scanner stalled the bus when receiving carriage return (c/r). As an example the string "B78C78C79 c/r l/f" stalled immediately upon receiving the c/r as required by the scanner manual. I could force the scanner to work by moving it to a different location on the bus, but then I started to find other problems with another vintage 1980s device made by MKS. </FONT><FONT face=Arial size=2></FONT></DIV><DIV><FONT face=Arial size=2>All of the problems with this system were corrected immediately with the Agilent 82350 GPIB PCI card.</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>Thanks for all the input.</FONT></DIV><DIV><FONT face=Arial size=2></FONT> </DIV><DIV><FONT face=Arial size=2>George Tyrrell</FONT></DIV><DIV><FONT face=Arial size=2>TestDynamics LLC</FONT></DIV><DIV><FONT face=Arial size=2>Thornton, CO</FONT></DIV><DIV><FONT face=Arial size=2><A href="mailto:georget@testdynamics.com">georget@testdynamics.com</A></FONT></DIV><BLOCKQUOTE dir=ltr style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV><FONT face=Arial size=2></FONT><BR></DIV> <DIV><FONT face=Arial size=2>Hi All,</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>I am experiencing what appears to be an excessive speed problem with VEE 5.0 on NT4.0, the National PCI-GPIB card, and a Keithley 706 scanner. I am hopeful that someone has used this combination and might have a solution or workaround. </FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>I am converting this system from a lan-GPIB configuration using the E2050A gateway, and in this configuration the Keithley 706 responds properly to bus commands. All bus cable lengths are well within the IEEE-488 standard, with a daisy-chain configuration. The system configuration consists of a mix of various manufacturer's GPIB interfaced products. Strict attention is given to those instruments requiring both c/r and l/f terminations. In VEE, I/O conformance is set to IEEE 488.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Converting to the National GPIB card internal to the PC, however, causes problems with the Keithley 706 recognizing its commands. For the Keithey 706, channel open/closure commands are sent followed by an ascii "X" to execute that set of commands. The Keithley 706 will hang the GPIB upon receipt of the "X", not accepting the character, causing a timeout. I have tried breaking up the channel open/closure commands using time delays followed with the "X", but it still hangs on that character.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>I am suspicious that the National card is sending channel open/close data faster than the Keithley processor can internally accept, and that the scanner doesn't know what to do with its corrupted data when the execute "X" command is received. This scanner appears to be mid-80s vintage. I can regain control of the device with a SDC command, but that resets it to the power-up state.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Is it possible the GPIB card is switching to high-speed mode when sending data to the scanner?</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Any information/suggestions about taming this GPIB card would be greatly appreciated!</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>Regards,</FONT></DIV> <DIV><FONT face=Arial size=2>George Tyrrell</FONT></DIV> <DIV><FONT face=Arial size=2>TestDynamics LLC</FONT></DIV> <DIV><FONT face=Arial size=2>Thornton, CO </FONT></DIV> <DIV><FONT face=Arial size=2><A href="mailto:tdllc01@earthlink.net">tdllc01@earthlink.net</A></FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2> </FONT></DIV></BLOCKQUOTE></BODY></HTML>
Hi Mike,
NI does boast the "high-speed HS488" mode, and they claim that this mode
occurs automatically. Reading through their setup, however, I find that the
cable length must be pre-defined at some non-zero value, and that a HS488
command set must be accepted by the instrument before the third wire is
disabled for that instrument's transactions. When in this mode, data may be
transmitted around 7 MBytes/sec with this particular card. The installation
default is for setting HS488 in the "off" condition with a zero cable
length. So it is unlikely that the card would be doing high speed
deliberately according to their setup.
You indicate that you have driven the older-style box successfully with the
card, and Peter Supancic in another vrf message also indicated the same.
Quite likely something else is occuring here with all of the other devices
on the bus, even though there are no address conflicts and I have used a
respectable daisy-chain cable arrangement.
Yes, I am the VRFer with the old bus analyzer. Its dust was removed 3 weeks
ago on the same system, where I finally located an obscure intermittant
serial-poll problem in a MKS spinning rotor precision vacuum gauge and
worked around the problem. That problem required both the 59401A and the NI
PCMCIA GPIB+ analyzer card in a laptop for taking a snapshot of bus
transactions over 20 minutes. I also have a 1615A logic analyzer with the
HP-IB timing analyzer interface, which I may need to dig out for this
problem. I'm reluctant to take that on site until I exhaust other
resources. I may just install their card on one of my NT4 systems and look
at the timing here just to see how the handshake interacts with VEE 5.0 and
6.0. That would be useful information for future reference.
I will be on-site with the analysis equipment next week, and should know
more by then! I really appreciate all of the input I have received through
vrf. It helps to target the investigation.
Best Regards,
George
> Hi George,
> This is a guess, but I know that NI boast a 'high-speed' mode
> which actually just turns off the bus handshaking, removing the whole
> beauty of IEEE-488! I would be looking at the card setup rather than the
> VEE end.
>
> I have used VEE before to drive an older-style Keithley box with
> similar type syntax and via a NI GPIB card but I have to say that I didn't
> have the same problem as you.
>
> Weren't you the VRFer with one of the old HP-IB bus analysers? If so
> here is a classic case to dust it off and check that the card is waiting
> correctly for the slowest device on the bus...
>
>
> Good luck!
>
>
> Best Regards,
>
> Mike Watts
> ---------------------------------------------------------------------
> This is the "vrf" maillist, managed by Majordomo. To send messages to
> this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
> unsubscriptions are done through the address
"vrf-request@lvld.agilent.com".
> If you need details, just send a message containing the text "help"
> to "vrf-request@lvld.agilent.com".
> ---------------------------------------------------------------------
---------------------------------------------------------------------
This is the "vrf" maillist, managed by Majordomo. To send messages to
this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
unsubscriptions are done through the address "vrf-request@lvld.agilent.com".
If you need details, just send a message containing the text "help"
to "vrf-request@lvld.agilent.com".
---------------------------------------------------------------------