Serial connecting PLC on Alpha1200 TTA0

[Anton van Ruitenbeek]

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

[Hakan Zanderau ( Anders]

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.......

[Jon Pinkley]

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

[Jon Pinkley]

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.

[Walter Miller_1]

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]

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]

> [...] 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]

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

[DECxchange]

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]

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.

[DECxchange]

John,

The issue is really why the Alphaserver 1200 thinks the PLC is trying to login when it is connected to the TTA0: port. This could be because the application is not assigning a channel to that port.

As far as the use of logical block vs. virtual block for the TT driver, and the QIO modifier functions, I posted, I don't have the TT Driver I/O reference manual in front of me. This is code that I wrote about 15 years ago for a steel mill that communicated with in plant devices such as Streeteramet scales, Femcos, etc. I also wrote an application that communicated with an Allen Bradley PLC5 using the TT driver. It worked great. Now that was 15-16 years ago. But as I recall, there are times you want to purge the typeahead buffer before posting your QIO to get rid of extraneous data that might throw things off.

Sometimes dumb devices get confused as well. I'm not trying to rewrite the guy's application. It seems like this particular issue is simply about switching RS232 ports, in which case there really shouldn't be any changes necessary to the existing source code. Probably just some changes in logical name definitions should do the trick. But you are more experienced at VMS than I so what do I know?

[Anton van Ruitenbeek]

The terminalserver is a Lantronix.

I've attached the portsettings (show terminal) of the TTA0 and the LTA103.
Unfortunaly the /no_typeahead isn't working.
Also attached the portsettings when program is running (on LTA103:)
I also added the source code which does the connection.

The resultcode is 244
%SYSTEM-F-ILLIOFUNC, illegal I/O function code

AvR

[Hakan Zanderau ( Anders]

I will try another shot straight into the dark since no suggestions so far have worked.

How about letting the PLC login using ALF and then kill the process when the program wants to connect to the port ?

Could the program be started by the PLC logging in ?

regards,

Hakan Zanderau
HA-solutions

[Anton van Ruitenbeek]

There is one difference this morning i didn't mention. The person who had moved the testserver did by accident put the PLC into de OPA0: (serial 1). When I removed this and put it into TTA0, there wasn't a continuesly logging in. So it seems it only happens during booting. Also the programmer of the PLC mentioned that he had changed something but he don't know for sure what. It wasn't important (he thinks, but I needed to know what, sorry guys).
So, by unplugging/plugging it looks solved, so maybe the /no_typeahead will work. This we will check.
Now it looks like the settings/control of a TTA serial port is other than a LTA serial port. Does anyone knows this ?

The biggest problem for now is the time. Because of the location we aren't able to be here every day. Also because of the nature is the development only connected to the PLC (which is running in production) and no where else connected to (even no network!). So only poss. to access this environment is on location.

AvR

[Robert Gezelter]

Anton,

It would be helpful to know the precise cabling being used. I have seen situations where the some devices did "unusual" things with the modem control and dataset lines that a signal aware interface had issues with. The RJ45 cabling may prevent that from happening. Also, consider the fact that the TTDRIVER handling of those signals (documented in the manual) may differ slightly from the effective handling of the server and the LATDRIVER.

A modem breakout box displaying the actual signals may be helpful in this situation.

- Bob Gezelter, http://www.rlgsc.com

[Doug Phillips]

Now it looks like the settings/control of a TTA serial port is other than a LTA serial port. Does anyone knows this ?


Remember that the PLC and other such devices communicate with the port where they're physically connected.

It's the terminal server port's settings you need to look at to see how to set TTA0.

Physical device connection settings for LTA ports (like baud-rate and such) are different and some are meaningless because the terminal server is handling the device connection and your program is "talking" to the terminal server and device via a network connection.

We use something similar to John Gillings' example to handle the type_ahead problem. With dedicated port-devices, we set the port's "idle state" in a command file executed in systartup and the "active-state" gets set in the application startup.

If you have the PLC's specs or programming manual, that would be a good place to look.

But you say it's working now that it's plugged into the right port?

[Hoff]

OPA0: was sent piles of text during the OpenVMS bootstrap (or an OPCOM or other such), the PLC saw it, answered, text arrived back at OPA0:, OpenVMS saw it as unsolicited input, responds, text arrives back at PLC, lather, rinse, repeat.

DECserver terminal server devices also tend to use specific ports as a console for the DECserver itself, and this too can start the serial line connection a-chattering.

The problem and the solution here that most everybody (and the OpenVMS FAQ itself) has pointed at probably still exists with the PLC connected to another device, but so long as the application gets rolling before the host sends out a message (or a broadcast) and the PLC keeps its serial port quiet, you'll be back in your original state here.

Stephen Hoffman
HoffmanLabs LLC

[Jon Pinkley]

Anton,

When you had the PLC connected to OPA0: you probably got into a feedback loop:

VMS sent an OPCOM message, the PLC saw it and said "What??", VMS saw the unsolicited input and started LOGINOUT, etc.

So the recommendation to turn it off broadcast is valid, since you don't want the PLC to be getting unsolicited data sent to it.

Without knowing more about what is connected, and what data is being sent back and forth, we are just guessing.

$ set term/nobroadcast/notypeahead/perm tta0:

And as suggested by others, doing an allocate followed by set term/typeahead

My preference would still be to use the alternate typeahead buffer instead of changing the default typeahead buffer to something as large as 32k. If you don't have a lot of terminals, it probably doesn't make much difference, but the typeahead buffers are in non-paged pool. With the alternate typeahead buffer you also control when flow control kicks in; with the standard typeahead it is fixed at 8 characters before the buffer is full. However, in your show terminal output you currently have /nohostsync /nottsync so you effectively have turned off flow control from the VMS perspective. Perhaps the terminal server was providing flow control (either xon/xoff or hardware with cts/rts).

So I would suggest reading http://h71000.www7.hp.com/doc/73final/6136/6136pro_016.html section 5.2.1.5 Type-Ahead Feature. Note that you may be able to take advantage of the terminal driver optimization by also setting the /PASTHRU qualifier.

We have Lantronix ETS terminal servers, but we are using telnet instead of LAT, some of this may not apply.

You should be able to log into the terminal server if you know the access password.

Once you get logged in, you can do show the port characteristics, stats and counters for port 5 with the commands:

ETS> show port 5 characteristics
ETS> show port 5 stat
ETS> show port 5 counters

Here is the output from a port close to the factory default setting. These have VT510 terminals attached.

B86ETS32A_Port_34> show port 5 char

Port 5 : Username: B86ETS32A_5 Physical Port 5 (Idle)

Char Size/Stop Bits: 8/1 Input Speed: 9600
Flow Ctrl: Xon/Xoff Output Speed: 9600
Parity: None Modem Control: None

Access: Local Local Switch: None
Backward: None Port Name: Port_5
Break Ctrl: None Session Limit: 1
Forward: None Terminal Type: Soft()

Preferred Services: (Lat)
(Telnet)

Authorized Groups : 0
(Current) Groups : 0

Characteristics: Autoprompt Broadcast Loss Notify Verify
Remote Conf Telnet Pad Menu

B86ETS32A_Port_34>

This is what a port we have a printer connected to, and we are using TCPIP$TELNETSYM to print to the device.

B86ETS32A_Port_34> show port 30 char

Port 30: Username: B86LP4 Physical Port 30 (Idle)

Char Size/Stop Bits: 8/1 Input Speed: 9600
Flow Ctrl: Cts/Rts Output Speed: 9600
Parity: None Modem Control: None

Access: Remote Local Switch: None
Backward: None Port Name: Port_30
Break Ctrl: None Session Limit: 1
Forward: None Terminal Type: Hard()

Preferred Services: (Lat)
(Telnet)

Authorized Groups : 0
(Current) Groups : 0

Characteristics:

B86ETS32A_Port_34>

Note that we turn all the characteristics off on the ports we have printers connected to, since we don't want anything sent to the printer except what we send it. And we use hardware flow control.

Also, you will want to disable broadcast at the terminal server level (and the VMS level) as those messages will confuse whatever is connected to the port.

Jon

[DECxchange]

Anton,
I looked at your C code and I don't think the following Io functions you are presently using with the terminal server will work with TTA0:

if((( status = SYS$QIOW( 0, *chan, IO$_TTY_PORT | IO$M_LT_CONNECT
, &status_block, 0, 0, 0, 0, 0, 0, 0, 0)) & 1) != SS$_NORMAL) {

I believe these are for LAT terminal servers only. I think that is why you got the illegal function code error. The LAT terminal driver is a little bit different from the TT driver. I think you need to change these to either IO$_READLBLOCK or IO$_READVBLOCK.

I'm not sure if these LAT function codes purge typeahead first like IO$M_PURGE does, or whether your PLC communication needs it or not. The latter function code can be OR'd in with the other modifier, similar to how your existing code does the OR of function codes. I've not done this in C. I've done it in Fortran. But it should e similar.

Also, I there's a SYSGEN parameter for TTY_ALTYPAHD. When I wrote a program to talk to an Allen Bradley PLC5, I recall needing to set this to 1024. It is 400 by default on my Alphaserver 1200 (Top Gun Blue). Your PLC probably comes with some type of communication protocol docs somewhere.

[DECxchange]

The more I think about it, you might want to:
$ set/perm/notype_ahead/altypahd TTA0:

That is disable typeahead and enable altypahd. Then I think you want to adjust the SYSGEN parameter tty_altypahd to something like 1024. Then I think you will want the IO$M_PURGE ORd with IO$_READVBLK in your C source code (recompile and relink). You might want to experiment this either way to be sure.

What kind of PLC are you using? Thanks.

[Anton van Ruitenbeek]

@Hakan
The PLC is never logging in, its machinery.

@Bob
I've found in the documentation that the TT driver behaves quite difference than the LTA driver.
If whe change this program by modifying the behavior and check for TT or LTA port, I also (my opinion) need to change the other programs. Because the interfaces are probably changing there as well.

@Hoff
This is exactly what happend (I think). The PLC sends a 'NACK' (%X15) when it doesn't understand the message send (which needs to start with a 'ST'-bit (%X2)). But the strange thing what was happening is that previous the situation was that the machines booted up with the PLC on TTA0 and the behaviour was the same.

@DEXchange
Thanks for the code checking.

To all,
We (costumer and I) decided to not change the code (for this part) and go for the terminalserver solution. I mentioned the other PLC's in the hall and there are still some ports free on the terminalservers on the floor.
Only this PLC is ended in the computerroom (optical etc.) and here are no terminalservers.
The final will be that 1 terminalserver will be mounted with one port connected to this PLC endpoint. In the future we will try to move all the other connected PLC's to the computerroom.

Thanks for all of your input and thoughts.

AvR

[Jon Pinkley]

Anton,

I think you have made the correct choice: Keep everything as similar as possible. Since you are successfully using terminal servers other places, using them everywhere is best from a support standpoint.

Good luck,

Jon