[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference helix::realtime

Title:Realtime Conference
Moderator:HELIX::LUNGER
Created:Mon Feb 24 1986
Last Modified:Mon Jun 02 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1241
Total number of notes:4452

1239.0. "2t-iea11-ca problems" by AUSSIE::MCNAMARA () Mon Apr 21 1997 05:52

    G'Day All,
    		We have a customer using a 2T-IEA11-CA IEEE488 controler
    on VMS and it works just fine until he adds in the HP37204 GBIP bus 
    extender.
    
    He suggested that the standard driver tell devices to talk before it
    tells itself to listen.
    
    Does anyone know how this beast works?
    
    Regards Scott
T.RTitleUserPersonal
Name
DateLines
1239.1They work 90% of the time for 90% of applicationsRHETT::HICKSMon Apr 21 1997 14:0252
Scott --

	The IEEE-488 standard states that the maximum bus length is two meters 
times the number of devices or twenty meters (whichever is less).  It goes on 
to say that "caution should be taken if individual cable length exceeds four 
meters".  

        There are many manufacturers who sell bus extenders, using a variety
of technologies (wire, fiber optic, infrared, etc).  Our team has been 
supporting IEEE-488 customers using a variety of Digital interfaces (IEC-11, 
IEU-11, IEQ-11, IEZ-11, IET-11) for about 15 years.  This symptom (application 
works fine without the bus extender but fails with it) is a common inquiry.  Our
official reply is "The IEEE-488 standard does not support the use of any type
of bus extender.  Our experience here is that bus extenders work 90% of the
time for 90% of applications.  This is because our IEEE-488 interfaces (like
those of most manufacturers) exceed the requirements of the IEEE-488 standard.
However, Digital will only guarantee that our interfaces will conform to the
standard and any use of bus extenders is considered unsupported".

        So, where does that leave your customer?  In general, if you can get a
bus extender to work, it will work consistently.  Frequently, the problem is a
timing problem with the handshaking.  If you put an IEEE-488 bus analyzer on
the lines, you will probably find out more.  I wouldn't be surprised if you
find that the NRFD and NDAC lines asserted at the simultaneously.
Occasionally, you can work around a problem like this by introducing some very
short delays in your program or by using the IO$M_TCS modifier on a read or 
the IO$M_STANDBY modifier on a write.  Also, your customer might want to test 
a bus extender from a different manufacturer.

	I am not certain what the customer means when he says that "the 
standard driver tells devices to talk before it tells itself to listen".  The 
IEEE-488 handshake is a three wire handshake that assures that a message 
that is posted to the bus is properly received before another message can be 
posted.  Of course, this assumes that the device conforms to the standard 
(many do not).  However, in your case, the device functions properly without 
the bus extender.  There is always the possibility of an IET-11 driver or
hardware bug, but I don't see any evidence of it here.

	In order to better address the issue, it would be helpful to have a
trace from an IEEE-488 bus analyzer - with the bus extender and without it.  
By observing differences in the traces and using the output to identify the 
specific QIO that generated the error, you might be able to work around it.  
One other warning - adding an IEEE-488 bus analyzer might change the problem 
(a variation on the Heisenburg uncertainty principle!) or (believe it or not) 
might make the problem go away.  

	I hope this helps!

						Gary Hicks
						Realtime Expertise Center
						Atlanta CSC