AnsweredAssumed Answered

vrf Serial ports & Version 6.0

Question asked by bwalden on Jun 27, 2000
Oh Happy Day (serial wise)

It seems that the new reflector address works better than the old - I
have gotten numerous responses to my RS232 serial port dilemma.  The
best was from Bruce Wenner pointing out that version 6 has some serial
port enhancements which might address my concerns.  I'm happy to say he
was right!

Version 6 includes "programmable instrument properties" which
facilitates changing an RS232 port configuration from within an
application.  This means it is now an easy matter to provide a baud rate
selection menu or establish communications with an instrument by
automatically testing various likely protocols.

Another new feature is the "Dynamic I/O Automation Server".  This allows
an application to determine the Logical Unit Numbers (Select Codes) of
hardware interfaces available on a target machine.  Under some
conditions it also allows determining what instruments are attached to
these interfaces.

Finally, version 6 can save the I/O configuration file with the
application which allows insuring that generic instrument definitions
(and specific instrument definitions) are available when an application
loads on a target machine.  Since the parameters associated with any
instrument can now be changed on the fly, a generic definition becomes a
very handy thing.

Adding the above together, my applications can now:

1) determine the Logical Unit Numbers of available RS232 ports.

2) assign a hardware port to a pre-defined software Direct I/O object
having a generic name such as SerialPort1 (this is not necessarily the
same as Com1).

3) allow the user to set the parameters associated with SerialPort1
and/or programmatically determine what these parameters should be.

Not bad  - but there are still a few warts:

1)  RS232 and its close relatives RS422 & RS485 are simple minded; the
average user plugs a cable into the back of his machine and notes the
number following the letters "COM" on the label.  This is the operating
system's port designator, not the HP Logical Unit Number provided by the
Dynamic I/O Automation Server.  In fact, from the Automation Server's
point of view there are no serial ports until HP I/O Configuration is
run and a relationship is established between operating system port
designators and Logical Unit Numbers.  This means that HP I/O
Configuration must be available on the target machine and there is no
direct connection between the number on the port label and the numbers
returned by the Automation Server.  In turn, this means an application
can't present an operator with a list of ports and let him select the
correct one based upon the port's hardware label.  Of course, this is
exactly how RS232 connections are normally handled and is what most
operators would expect.

One solution is to establish a consistent port number to LUN strategy
and provide application users with instructions.  As an example, one
could establish a one-to-one correspondence between hardware port
numbers and Logical Unit Numbers.  In this way the user will never
realize the two are not synonymous and the illusion can be heightened by
naming the generic serial instruments something like "Com1" and "Com2".
Unfortunately, this falls apart when there are a lot of ports involved
because some LUNs are reserved and can't be used for an RS232 interface
(i.e. Com14 cannot be assigned logical unit number 14).  Still, the
technique works until you add that second 8 port expansion card.

The real downside to all of this is that no matter how you cut it, I/O
Configuration must be run on the target machine with the goal of
obtaining some pre-determined relationship between physical port numbers
and assigned LUNs.

2) The Advanced I/O Data Available (DAV) event for serial ports is tied
to an interface rather than an instrument.  This means that use of this
object in an application requires knowledge of the target machine's I/O
configuration and LUN assignments.  Use of the DAV event object is
extremely important in applications where multiple serial ports are in
simultaneous use.  The "interface" rather than "instrument" feature
negates much of the good done by programmable instrument properties
since, if DAV's are used, runtime assignment of hardware ports is a
waste of time because the application's port code already needs to know
the target machine's assigned LUNs.  Programable Interface Properties
might solve this problem.

3) The Direct I/O object "Timeout" value is still a problem.  This value
designates how long to wait for completion of each transaction within
the Direct I/O object.  A long continuous input requires a large timeout
value.  When the timeout timer is running, all other threads are blocked
so a lengthy 300 baud data input can stop an application's real time
clock display among other things.  If a timeout occurs, any data
received up until that point is lost which means a pause in a data
transmission can't be used as an input terminator.  The correct solution
is to allow specifying an inter-character timeout interval and don't
throw away characters received if a timeout occurs.  In the mean time,
input can be done one character at a time but this shouldn't be

Fortunately, as a result of the enhancements provided by Vee 6.0 Pro, I
believe it will be possible to devise methods for doing all the things I
need to do with serial ports.  The code will be a little convoluted but
I'm convinced it will work and, unlike with an ActiveX Com object, I
will be able to take advantage of the highly positive aspects of Vee's
Direct I/O capabilities.


This is the "vrf" maillist, managed by Majordomo.  To send messages to
this maillist, just email to "".  Subscriptions and
unsubscriptions are done through the address "".
If you need details, just send a message containing the text "help"
to "".