Communications on serial ports

[Phelipot]

Using OpenVMS 7-3-2 and developping a binary (not only ASCII char) protocol on RS232 lines.

Two TT ports are linked each other (TXA0, TTA0).

Both TT ports have SET TERM/PERM options : NOINTERACTIVE (displaying PASSALL), EIGHBIT, PASTHRU, and NOTTSYNC.

When sending one by one the 256 char from 0 to 255 (hex 00 to FF) on one TT port (TXA0), the char received on the other port (TTA0) are the emitted char, except : (hex) from 00 to 07, from 0D to 1F, 7F, from 80 to 87, from 8D to 9F, FF, which are never received (time-out in receiving process).

Thanks for any idea that could help us.

[Hein van den Heuvel]

Hmmm,

I would have thought that PASTHRU and TTSYNC and of course EIGHTBIT would be the only options needed.

Did you verify that the selected setting actually 'took': $SHOW DEV...

How about NOLINE (you don't want ^A (001) to be interpreted as insert/over flip. ^E should not be 'end of line'.... there is no line!).

I assume you are using QIO(W) to read/write?
Any modifiers on the IO function?
You pretty much always need a read outstanding. You have that?

What problem are your really trying to solve. Plain terminal line protocols are very error prone. I assume you are trying to talk to an existing piece of strange hardware?!

$HELP SET TERMINAL /PASTHRU
"Controls whether the terminal passes all data (including tabs, carriage returns, line feeds, and control characters) to an application program as binary data. The setting of /TTSYNC is allowed.

Make sure that you spell both these qualifiers exactly as they appear in the text."


Good luck.
Hein.

[Bojan Nemec · Accepted solution]

Hi,

How are you reading the characters? If you look at http://h71000.www7.hp.com/doc/731FINAL/6136/6136pro_018.html#readfunc_term you will see that all characters you mentioned are by default terminators. Probably the program you use to read characters has no support for reading terminators. If you are using sys$qio system service try to pass an address of an empty terminator mask in p4.
The mask must be something like that (I dont know which language you use):

1 word (2 bytes): 32
2 word (2 bytes): 0
32 bytes all 0

Ps
The documentation is from OpenVMS 7.3-1 because on the 7.3-2 documentation I cant take a direct link to the page.

Bojan

[Hein van den Heuvel]

I am under the impression that 'PASTHRU' is not in effect. Is that bit really set?

You possibly need some modifiers on the READ QIO.

Check out the IO DRIVERS REF MAN chapter Terminal Driver, "Read Function Terminators"
It mentions the x80 - x9F range + xFF

Check out IO$M_NOFILTR

So how are you terminating the reads?
How does the QIO know it is done?
Just asking for 1 character at a time?
Bigger buffer plus timeout?

Hein

[Antoniov.]

Hi Phelipot,
you could post as you receice data; I assume you are using SYSQIO.
I make as follow:
1) Open serial port using SYS$ASSIGN
2) Store line characteristic within IO$_SENSEMODE function of SYS$QIO service
3) Set line characteristic usign SYS$QIO service and IO$_SETMODE function:
TT$M_NOBRDCST | TT$M_LOWER | TT$M_NOECHO | TT$M_EIGHTBIT
& ~(TT$M_HALFDUP | TT$M_NOTYPEAHD
| TT$M_WRAP | TT$M_ESCAPE)
TT2$M_PASTHRU;
above code means:
SET TERM/NOBROADCAST/LOWER/NOECHO/EIGHT/NOHALF-
/TYPEAHEAD/NOWRAP/NOESC/PASTHR
In reading function set zero all default terminators.
If you will I can attach a little C program to make this.
For my experience, however, you cannot send XON and XOFF used by interface to handshake.

Antonio Vigliotti

[Bojan Nemec]

Hi,

You can send XON and XOFF if both terminals are set /NOTTSYNC /NOHOSTSYNC, but this is not recomended. If yours receiving machine cant handle all the received data on the fly, you will lost some data. If you have both parts in your hands is better to write a simple protocol and leave the XON/XOFF protocol to do its job.
The simpliest protocol is to convert the character to hexa and send 2 characters. On the other (receiving) part you convert this two characters back to binary.
With the previous protocol there is a great overhead (the transfered data is doubled). A litle better method is base64.
One of the methods is escaping. When you have to send an XON or XOFF you send first a predefined escape character and then a modified character say Q for XON and S for XOF, the same thing you do with the escape character. At the receiving part you test each received character for the escape character. When you recive it, you must drop it and modify the next character to the original one (S in XOFF,Q in XON ...). In such way you can escape all characters you wish.

Bojan

[Willem Grooters]

Are you sure the bytes are actually sent - that is: getting on the outside line?
One (sure) way to easy test this, is to hook up a VT terminal on the sending port and set it to display, not interpret, control characters - or a PC running a decent terminal emulator, that is: one that is capable of doing this (Reflection, Powerterm and KEAterm can)
This way, each byte will show up as sent, and you are to test the outgoing port to start with. If that's ok, you can start testing the receiver.

Willem

[Phelipot]

Hi,

Many thanks for all answers.

The solution is to specify a terminator list with no terminator in the QIO. if P4 parameter is not configured in the QIO, a set of default terminators is in use despite of PASTHRU option. We tried the Short Form of Terminator Mask Quadwords (all O) and it works fine, all char are now received.

Answers on questions in the replies :

-There is no modifier in the QIO READVBLK, all options are set with SET TERM
-Communication is with a very strange hardware : a kind of PLC (programmable logic cotroller, 19200 bps multipoint RS485 serial link), used to monitor industrial input/output
-We cannot use the XON/XOFF handshake managed by interface : communication is full binary
-Handshake is assumed by protocol

Phelipot