Experimental Physics and
Industrial Control System

Hi Maren,

Have a look at conserver [1]. This is - yes, another layer that needs to be configured. Still, its most important ability is to unify access to different kinds of console connections. On the console-connection side, it supports everything from serial line over telnet, plain TCP to ssh, while providing a single TCP based access interface to clients, i.e. operators and controls people.

If configured correctly, the "console <iocname>" command anywhere in the controls network will put you on the IOC console, no matter if it is a soft IOC under procServ or screen, a VME CPU through a console switch or a local USB to a RaspberryPi. All the client needs to know is the IOC name.

Only one user will have write access to a console, but others can see what's happening (read-only), who is using the line with write access and - most importantly - bump that blocking user out of the connection grabbing write access.

Other goodies include unified logging/timestamping of all connections, security (SSL) for the client connection and PAM support for authentication/authorization.

It adds complexity, needs configuration, is somewhat outdated - but it is pretty much exactly what you want for IOC console access in a large heterogeneous system.

Test it and decide if the additional maintenance effort pays for the advantages you get.

Cheers,

~Ralph

[1] https://www.conserver.com/

On Thu, 26 Jan 2023 at 02:19, Maren Purves via Tech-talk <tech-talk at aps.anl.gov> wrote:

I'll have to look into that now that our computer system is functional again (never worked with procServ).

A console switch is similar to a terminal server, but with buffers for each port.

Thanks Mark,
Maren

On Tue, Jan 24, 2023 at 10:36 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:

Ø  (I assume that works the same way for console switches?)

 

What is a console switch?  It should work because there is only a single connection to the device, and that is from procServ.  Users connect to procServ which allows multiple users to share a single connection.  Everyone sees what everyone else is typing and receiving.

 

Ø  Our telescope operators open a telnet session to each of the iocs at the start of the night in case they need to reboot one. Does the one prevent the other?

 

I don’t use telnet to the IOCs, so I am not sure.  But if you use procServ they will be able to reboot using that and so may not need a telnet connection to the IOC at all.

 

Mark

 

 

 

From: Maren Purves <m.purves at eaobservatory.org>
Sent: Saturday, January 21, 2023 5:28 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov
Subject: Re: abdf1 driver that logs with logMsg? - I know this is a real long shot

 

Thank you Mark,

 

yes, I do have the source code, but those print statements are in state notation code rather than in the driver. I can try replacing the printf in there.

 

I did not know that there is a way around only one person being able to access a terminal server (I assume that works the same way for console switches?) at a time.

Our telescope operators open a telnet session to each of the iocs at the start of the night in case they need to reboot one. Does the one prevent the other?

 

Thanks, will have to look into details later (it's not the only problem we're having at the moment),

Maren

 

Maren Purves
Head of Instrument and Telescope Software
East Asian Observatory / JCMT

 

On Sat, Jan 21, 2023 at 5:47 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:

Hi Maren,

 

I assume you don't have access to the source code for the abdf1 driver, so you can't change the printf() to logMsg()?

 

We log the console output on all of our vxWorks systems as follows:

• Connect the console serial port to an Ethernet terminal server.
• Run the procServ program on a Linux machine.  Here is an example of the command used to start one of them:

/usr/local/bin/procServ --logstamp -n "13IDA_IOC" -L /home/epics/logs/13IDA.log 20024 /usr/bin/telnet gsets2.cars.aps.anl.gov 4004

 

That does the following:

• Connects to the terminal server gsets2 via telnet on port 4004
• Logs all of the console output to the file /home/epics/logs/13IDA.log
• Allows multiple users on the Linux system to connect to the console port at the same time using the command:

telnet localhost 20024

 

The log file has a timestamp on every line, so you can see when error messages were generated.  Here is an example:

 

[Fri Jan 20 09:17:14 2023] sevr=minor Motor motion timeout ERROR on card: 2, signal: 0

This solution won't put the log output in the same place that logMsg would, but at least it will be on your Linux server where you can search it.

 

Mark

 

 

 

 

 

 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Maren Purves via Tech-talk <tech-talk at aps.anl.gov>
Sent: Saturday, January 21, 2023 2:59 AM
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: abdf1 driver that logs with logMsg? - I know this is a real long shot

 

Hi all,

 

we have an EPICS ioc (ppc604, mvme5100 to be exact) that connects to an Alle Bradley PLC using the abdf1 driver. We have some errors recorded from state notation language but that only goes into the buffer of the console switch. We use logMsg (not sure exactly where that comes from) to write to a nightly EPICS.log which is much easier to access than the console switch that only allows one connection at a time.

 

The abdf1 version used dates back to 2011, and we're still running EPICS 3.13.8 on VxWorks 5.5. While I'd like to upgrade to EPICS 7 and for many (at least the monitoring) things softIocs we don't have the effort to do that in a more than very piecemeal way, if at all.

 

TIA,

Maren Purves
Head of Instrument and Telescope Software
East Asian Observatory / JCMT