Accessing the CC100 RS-485 interfaces from Linux while CODESYS is using them

CODESYS
1

We are developing an application on a WAGO CC100 (751-9402) using CODESYS V3.5. The controller has two RS-485 interfaces, both currently used by the CODESYS application for Modbus RTU communication.

We would like to occasionally access one of these same RS-485 interfaces from a Linux application running on the CC100 for diagnostic and maintenance purposes.

The Linux application would never access the RS-485 interface simultaneously with CODESYS. The intended sequence would be:

  1. CODESYS temporarily stops communication on the selected RS-485 interface.
  2. The interface is released by CODESYS.
  3. The Linux application opens the corresponding serial device (e.g. /dev/tty...) and performs the required Modbus RTU communication.
  4. Linux closes/releases the serial interface.
  5. CODESYS resumes communication.

Our questions are:

  • Is this type of exclusive, non-simultaneous access to the CC100 RS-485 interfaces by CODESYS and Linux supported?
  • How are the two CC100 RS-485 interfaces exposed to Linux (e.g. /dev/tty...)?
  • Does the CODESYS/WAGO serial driver allow the interface to be properly released and subsequently reopened by a Linux process?
  • Is there a recommended WAGO mechanism or API for switching ownership of the serial interface between CODESYS and Linux?
  • Are there any restrictions or precautions regarding this approach, particularly concerning the CODESYS runtime and the WAGO serial drivers?

We are specifically interested in occasional Linux access, rather than having Linux permanently manage the RS-485 communication.

2

Hello, I am Matthew Kim, living in South Korea.
I read your post with interest and am leaving a reply.

Are you attempting to use the two RS-485 ports on the CC100?

Is the plan to use one port as a constant RTU, while using the other as an RTU but pausing it temporarily to execute external RTU commands when received, then resuming the original operation once finished?

I haven’t tested this myself, but I expect it is feasible. However, the CODESYS runtime and the Linux application need to communicate or exchange information with each other. This is necessary so they can determine which process holds ownership of the specific port.

There are various ways to handle this, but using Modbus TCP seems like a convenient method for the exchange.

First, when CODESYS is using the port, the Linux Application (LA) sets a “request-to-use” bit to ON.

CODESYS then switches the communication port from “open” to “closed” and sets a “closed-status” bit to ON.

The LA confirms that the “closed-status” bit is ON and then opens the RTU connection.

After completing its task, the LA closes the connection and sets the “request-to-use” bit to OFF.

Upon confirming that the bit is OFF, CODESYS resumes normal communication.

It appears this would work assuming the RTU ID function operates correctly, though I cannot speak to the safety or stability (e.g., risk of bugs).

Is the CC100 the device you are trying to maintain?
Is the data you want to check located inside CODESYS?

I am not sure exactly why you are sticking to this specific approach, but if it were me, I would use the IP address 192.168.42.42 for maintenance purposes.
Alternatively, I might open a Modbus Slave instance in CODESYS and connect a client to it whenever I need to perform maintenance and retrieve internal data.

Your proposed method carries a risk of timing conflicts or deadlock issues. Also, since it does not use standard Modbus RTU at all times, you will likely need to use a separate library.

Is it a situation where you need to open a Modbus server for maintenance, or where using 192.168.42.42 on-site is not possible?

3

Hi,

Thank you for your message.

We use both RS485 interfaces on the CC100 to communicate with external devices using Modbus RTU. Therefore, Modbus RTU is required.

We access the CC100 remotely through a VPN. For testing purposes during the pre-commissioning phase, we would like to run a communication application directly on the Linux side of the CC100.

Best regards,
Annibal

4

I think you already check about this topic.

If that is not the case, please check the relevant topic.

Please provide further feedback.