Operating System - OpenVMS
1752576 Members
3834 Online
108788 Solutions
New Discussion юеВ

Re: Serial connecting PLC on Alpha1200 TTA0

 
Anton van Ruitenbeek
Trusted Contributor

Serial connecting PLC on Alpha1200 TTA0

Hey guys,

I'm connecting a Programmable Logic Controller on my TTA0 of the Alpha1200 and the Alpha keeps on thinking this port trying to login.
When I connect this PLC on a terminalserver everything works fine. A program connects to the port and does the interfacing. Because the port is continuesly logging in the program cant get connection to this port. The sessings of the terminalserverport are identical to the TTA0. The only difference is that the terminalserverport is a RJ45 and the serialport is a DB9 (and has modemcontrol etc).
I already tried (I think) all the possible settings there are possible. On the whole plant all the PLC are connected by terminalservers and these are working fine.
Normaly TTA0 is being used by a modem and this was working fine (not continuesly loging in etc.).

Tomorrow I'm going (again) to this costumer so maybe I can add the portsetting to this tread.

The reason for this action is to eliminate the terminalserver because there is only one port used.

AvR
NL: Meten is weten, maar je moet weten hoe te meten! - UK: Measuremets is knowledge, but you need to know how to measure !
21 REPLIES 21
Hakan Zanderau ( Anders
Trusted Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

Just a shot in dark....

Try set the SYSPASSWORD on port.

$ SET TERM/SYSPASSW TTA0:

It causes the port NOT to execute loginout.exe until a correct password is used.

Hakan Zanderau
HA-solutions

You will probably get more suggestions.......
Don't make it worse by guessing.........
Jon Pinkley
Honored Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

Do you have control of the program?

The supported way is to set term/perm/notypeahead tta0:

and then have the program issue a setmode qio to turn that terminal characteristic on, and possibly to select alternate typeahead buffer so characters aren't lost.

Described in the io user's guide if I am remembering correctly.

Jon
it depends
Jon Pinkley
Honored Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

Anton,

What type of terminal server is it? If it is a "DECserver" or compatible, if the port is set to "ACCESS REMOTE" then it ignores unsolicited input (turns the phone ringer off). On a cisco, setting a line to no exec does the same thing.

2511# config t
2511(config)# line 5
2511(config-line)# no exec
2511(config-line)#^z

Those would be what I looked for when you go back.

it depends
Walter Miller_1
Valued Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

On the Alphaserver 1200 do a "set term/perm tta0: /notype_ahead". With this setting the terminal will only accept input when a program or the system issues a read to the terminal.
Robert Gezelter
Honored Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

Anton,

I agree with the SET TERMINAL/NOTYPEAHEAD. It may also be desirable to permanently force certain other attributes as well.

Once testing is completed, these attributes should be forced fairly early in the startup process, to avoid problems with unexpected data arriving at inopportune moments.

- Bob Gezelter, http://www.rlgsc.com
Steven Schweda
Honored Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

> [...] fairly early in the startup [...]

Really? I haven't had to worry about this
problem for a long time, but I'd expect that
you could do whatever you want at any time
before the magic "SET LOGINS /INTERACTIVE"
command is executed. Does anyone care what
happens on a port before that?
John Gillings
Honored Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

Anton,

I've dealt with this issue many times. The terminal server doesn't know where to send stray input, so it gets dropped. On a fixed serial port with typeahead enabled, any input is seen as a login attempt, so OpenVMS starts a process running LOGINOUT to prompt for username and password.

As others have suggested, your startup procedure should SET TERMINAL/PERMANENT/NOTYPEAHEAD to prevent stray data from triggering a login. However, you probably WANT a typeahead buffer when your application is running so you don't lose data. Indeed it might even be a good idea to set TTY_TYPAHDSZ larger than the default 78 bytes - memory is cheap! Don't bother with TTY_ALTYPEAHD, just
set TTY_TYPAHDSZ to maximum value - 32K. This will cost very little, and make life easier for your application, without the need for code changes.

When your process wants to connect, it should use a sequence like:

$! Repeat the NOTYPEAHEAD, just in case
$! the startup didn't do it. If there's a
$! login happening, (from memory) the
$! SET TERM will hang until the other
$! process relinquishes the device.
$! Once it's set, further input will
$! be dropped.
$
$ SET TERM/PERM/NOTYPEAHEAD
$!
$! Now grab the terminal.
$ allocloop: ALLOCATE
$ IF .NOT.$STATUS
$ THEN
$ ! I recommend AGAINST a delay here.
$ ! You want to get this device before
$ ! anything else happens. Maybe code
$ ! a sanity check counter.
$ GOTO allocloop
$ ENDIF
$!
$! Now that you own the terminal, you can
$! reenable typeahead. This time we DON'T
$! specify /PERMANENT, so it will only
$! last for the duration of the ALLOCATE.
$!
$ SET TERM/TYPEAHEAD
$!
$! Now run your program, referring to the
$! logical name to open channels
$
$! After the program has run, it should
$! revert to /NOTYPEAHEAD when deallocated.
$ DEALLOCATE
A crucible of informative mistakes
DECxchange
Regular Advisor

Re: Serial connecting PLC on Alpha1200 TTA0

Hello,

Here are some set term things to try:

$ SET TERMINAL/PERM/SPEED=9600/UNKNOWN/NOHOSTSYNC/NOWRAP/NOECHO/NOBROADCAST/NOTYPEAHEAD/REMOTE TTA0:

Would this by any chance be a program like Fortran communicating with the PLC? Typically, when you are talking to a PLC from a Fortran program, you would do a
status = SYS$ASSIGN('TT',ttchannel,,)
status = SYS$QIO(W) with a IO$_WRITELBLOCK or IO$_READLBLOCK with modifiers similar to this:

If you're reading from the PLC:
qiofncvms = IO$_READLBLK.OR. ! Read Logical Block.
1 IO$M_PURGE.OR. ! Purge the typeahead buffer.
2 IO$M_TIMED.OR. ! Time out the read operation.
3 IO$M_NOECHO.OR. ! Don't echo input to terminal.
4 IO$M_NOFILTR ! Supress interp of ctrl chars.

Where 'TT' would be assigned (defined) to your device in a DCL command file, in this case, TTA0:.
Also, the numbers in between the lines are continuation characters from a piece of Fortran code I cut and paste into this window.

If you're writing to the PLC:
qiofncvms = IO$_WRITELBLK ! VMS Write Logical Blk
qiofncvms = qiofncvms.OR.IO$M_CANCTRLO ! Cancel Control O
qiofncvms = qiofncvms.OR.IO$M_NOFORMAT

The long and short is, if your TTA0: port is logged out, and your application program assigns an I/O channel to it, that port should not be able to allow logins to it, because it is allocated to that particular program.

If you could, please do a show terminal LTAxxxx on your terminal server port to see what set term characteristics it has. You should be able to do whatever the terminal server is doing on your TTA0: port if the application program is assigned to TTA0:. You might have to check a .COM DCL file somewhere or it might be embedded in source code somewhere.
John Gillings
Honored Contributor

Re: Serial connecting PLC on Alpha1200 TTA0

re: DECxchange

Huh?

/NOTYPEAHEAD mean that any input received when there isn't an active read posted is lost. /NOHOSTSYNC means the host has no way to flow control with the sender.

IO$M_PURGE on the read is redundant with NOTYPEAHEAD, but if typeahead is enabled, you throw away any buffered characters. Again data sent to the port is lost.

For a non-privileged application it should probably be IO$_READVBLK (Read Virtual Block). Granted for the terminal driver READLBLK is equivalent, but in theory it should need LOG_IO privilege, which isn't necessary for most applications.

I don't know what kind of application you're talking about, because all the ones I've ever worked on care very much about catching every character sent to the port! How can any protocol work if you're throwing away random chunks of data?

Assuming the sender does some form of flow control I'd expect it to be enabled, and a maximum sized typeahead buffer enabled.

Typically I'd also expect to see the reads on the port to be asynchronous with multiple read buffers. When a read completes, the completion AST would immediately post another read using the next free buffer and then place the current read buffer on a work queue to be processed by a different thread of execution. This design minimises the chances of losing data. Use large buffers and don't attempt to perform any parsing or other processing in the read AST thread, just shovel the data in as quickly as possible.
A crucible of informative mistakes