AnsweredAssumed Answered

VRf-VEE_Serial_Problems

Question asked by VRFuser on Aug 20, 1997
send q VRf-VEE_Serial_Problems ww vrf aohamala@cc.helsinki.fi

from: Greg Goebel / HP-MXD
      gvg@lvld.hp.com / 970-679-3030 / FAX 970-679-5971
      website:  ftp://fcext3.external.hp.com/dist/mxd/index.html
to:   VRf-Ari Hamalainen
date: Wednesday, 20 August 1997 1717 MDT

> Date: Tue, 19 Aug 1997 12:32:57 +0300 (EET DST)
> From: Ari Hamalainen <aohamala@cc.helsinki.fi>
> X-Sender: aohamala@kruuna.Helsinki.FI
> Subject: VRf_serial_IO_problems
>
> Ari Hamalainen
> University of Helsinki, Department of Physics
> VRf_serial_IO_problems
>
> I am using VEE for developing physics education software. I use mainly a
> Vernier ULI as the data acquisition system (see www.vernier.com, if
> interested). ULI is is connected to a serial port. Direct IO is used in
> VEE. I have a Pentium 120 with 32 MB for program development.
>
> I recently upgraded to VEE 4.01, and have run into some trouble in serial
> communications.
>
> It seems that in VEE 4.01, it is not possible to have a receive buffer
> size larger than 1024 bytes. The Advenced Device Configuration dialog
> accepts values up to 32727, but the actual buffer size is still 1024. It
> is possible to set the size smaller than 1024.

The buffer size on Win95 is currently limited to 1024 bytes.  This is not
the case on WinNT.

> I have also things to ask about the serial IO actions EXECUTE BREAK,
> EXECUTE CLOSE and EXECUTE RESET. I have not found a _detailed_ explanation
> about what do these commands actually do. Expecially, I'd like to know
> what, if any, bytes do they send to the device, and do of do not they
> empty the receive buffer.

EXECUTE BREAK simply sends a BREAK signal.  This puts the serial line in
a SPACE (zero) mode for "longer than a single serial data frame".  It
clears the line so the remote unit can sync up again.  I believe the time
interval is actually ten serial frames.

EXECUTE RESET sends a BREAK, clears the error queue, and flushes the serial
buffers.  I believe the pinouts of the interface will be left in an
operating-system dependent state.

EXECUTE CLOSE simply closes the device file, allowing other programs to
access it (other programs are locked out while it is open).  It leaves the
interface in an unknown state ... which doesn't matter, since when you open
the interface again (by performing serial I/O) it does an effective RESET
(except no BREAK is sent).

> EXECUTE CLOSE for serial IO seems to be a new action in VEE 4.0. I have
> not found any documentation how it should be used. When experimenting with
> it, I discovered that after EXECUTE CLOSE is run first time in a program,
> serial data read transactions always stops when a <LF>, or 0x0a, is
> received. This of course ruins a binary mode transmission. It seems that
> EXECUTE CLOSE "poisons" the the whole VEE environment, since the only cure
> is to close and restart the VEE.

Sir:

I connected a laptop computer with VEE 4.X as a remote to my PC.  I wrote
the following serial I/O program on the laptop:

   +-----------+
   |  Integer  |
   +-----------+   +-------------------------+
   | 0000: 33  |   |       Direct I/O        |
   | 0000: 45  |   +---+---------------------+
   | 0000: 62  +-->| A | WRITE BINARY A BYTE |
   | 0000: 13  |   +---+---------------------+
   | 0000: 70  |
   | 0000: 36  |
   +-----------+

This sends six bytes, the fourth of them being the numeric value of a line
feed.

On the PC I wrote the matching program:

                                         +---------------+
                                         | Alphanumeric  |
   +---------------------------------+   +---------------+
   |           Direct I/O            |   | 0: 33         |
   +-----------------------------+---+   | 1: 45         |
   | WRITE BINARY x BYTE ARRAY:6 | X +-->| 2: 62         |
   +-----------------------------+---+   | 3: 13         |
                                         | 4: 70         |
                                         | 5: 36         |
                                         +---------------+

I ran the two together multiple times and all six bytes came through.  Then
I modified the program as follows:

   +---------------------------------+
   |           Direct I/O            |
   +---------------------------------+
   | EXECUTE CLOSE                   |
   +---------------+-----------------+   +---------------+
                   |                     | Alphanumeric  |
   +---------------+-----------------+   +---------------+
   |           Direct I/O            |   | 0: 33         |
   +-----------------------------+---+   | 1: 45         |
   | WRITE BINARY x BYTE ARRAY:6 | X +-->| 2: 62         |
   +-----------------------------+---+   | 3: 13         |
                                         | 4: 70         |
                                         | 5: 36         |
                                         +---------------+

I ran the two programs again several times and all six bytes came through.
I cannot duplicate any problem with an LF terminating binary reads (though
it by default is the appropriate terminating character for text reads).

> And even more bizarre was that when _two_
> VEE environments were open simultaneously, with programs using EXECUTE
> CLOSE, the "poisoning" occurred _only_ in that VEE where the program was
> first run; the other instance worked OK.

I would find that to be expected behavior ... the two environments are
distinct.

> --
> Ari.Hamalainen@Helsinki.FI
> Univ. of Helsinki, Department of Physics
> tel +358 9 191 8311 (desk), +358 40 514 3867 (mobile), fax +358 9 191 8680
> http://www.helsinki.fi/~aohamala/    

If you have more comments, please let us know.

[<>] regards -- gvg

Outcomes