Serial connecting PLC on Alpha1200 TTA0

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