Modbus RTU over TCP

Hi Carles 

To communicate with a device using AVEVA Plant SCADA (formerly Citect SCADA) via Modbus RTU over Ethernet (also known as Modbus RTU over TCP/IP), you need to use the built-in MODBUS driver. This driver supports RTU framing and can be configured for TCP transport, typically when connecting directly to a device that supports RTU over TCP or via a serial-to-Ethernet converter/gateway that tunnels RTU frames over a TCP connection (without the Modbus/TCP header).

Note: If the device actually uses standard Modbus/TCP (with MBAP header), use the MODNET driver instead. Based on your query specifying "Modbus RTU over Ethernet," the MODBUS driver is appropriate. Ensure the device or gateway listens on a TCP port (commonly 502, but confirm with device docs).

Required Driver

• Driver: MODBUS (built-in to Plant SCADA; no separate installation needed). This handles the RTU protocol (PDU + CRC).
• Do not use MODNET, as it is for Modbus/TCP.

Configuration Steps

Configuration is done in Plant SCADA's Citect Studio (or equivalent editor) under the Communications section. Set up Boards, Ports, and I/O Devices as follows:

1. Configure the Board:
   • Board Name: Arbitrary (e.g., "TCP_BOARD").
   • Board Type: TCPIP.
   • Address: 0 (required for Ethernet).
   • Leave I/O Port, Interrupt, and Special Opt blank.
2. Configure the Port:
   • Port Name: Arbitrary (e.g., "TCP_PORT").
   • Port Number: Arbitrary (e.g., 1).
   • Board Name: Select the board you created (e.g., "TCP_BOARD").
   • Special Opt: Use this to specify the TCP connection details. Format: -I<IP_address> -P<port> -T
     • -I<IP_address>: The IP address of the device or gateway (e.g., -I192.168.1.100).
     • -P<port>: The TCP port the device listens on (default to 502 if not specified; e.g., -P502).
     • -T: Forces TCP mode (required; UDP is not suitable for RTU).
     • Example: -I192.168.1.100 -P502 -T
   • Mode: RTU (or ASCII if needed, but RTU is standard).
   • Baud Rate: Set to match the device's serial settings (e.g., 9600 or 19200; even if over TCP, this may be used for framing/timing).
   • Data Bits: 8 (standard for Modbus RTU).
   • Stop Bits: 1 or 2 (match device; commonly 1).
   • Parity: Even, Odd, or None (match device; commonly Even).
   • Leave other fields blank or at defaults.
3. Configure the I/O Device:
   • I/O Device Name: Arbitrary (e.g., "MODBUS_DEVICE").
   • I/O Device Number: Arbitrary (e.g., 1).
   • I/O Device Address: The Modbus slave ID (e.g., 1; range 1-247).
   • Protocol: MODBUS.
   • Port Name: Select the port you created (e.g., "TCP_PORT").
   • Cache: Enable if needed for performance (default is fine for most cases).
   • Other options like Delay, Timeout, or Retries: Set based on network reliability (e.g., Timeout: 3000 ms).
4. Configure Tags/Variables:
   • In the Variables/Tags editor, create tags linked to the I/O Device.
   • Address format: Use standard Modbus addressing (e.g., 40001 for holding register 1, 00001 for coil 1).
   • Data Type: Match the device's data (e.g., INT, REAL, DIGITAL).

Testing and Troubleshooting

• Compile and run the project.
• Use the Kernel window or Tag Debug to check communication (look for #COM or errors).
• Common issues:
  • Timeout: Increase port timeout or check network/firewall (port 502 open?).
  • Bad data: Verify slave ID, addressing, and serial params match device.
  • If using a gateway: Ensure it's configured for transparent mode (no protocol conversion).

This setup encapsulates RTU frames over a TCP socket without additional headers. Refer to the Plant SCADA Driver Reference Help (accessible in Citect Studio) for MODBUS-specific params.

Hi Carles 

To communicate with a device using AVEVA Plant SCADA (formerly Citect SCADA) via Modbus RTU over Ethernet (also known as Modbus RTU over TCP/IP), you need to use the built-in MODBUS driver. This driver supports RTU framing and can be configured for TCP transport, typically when connecting directly to a device that supports RTU over TCP or via a serial-to-Ethernet converter/gateway that tunnels RTU frames over a TCP connection (without the Modbus/TCP header).

Note: If the device actually uses standard Modbus/TCP (with MBAP header), use the MODNET driver instead. Based on your query specifying "Modbus RTU over Ethernet," the MODBUS driver is appropriate. Ensure the device or gateway listens on a TCP port (commonly 502, but confirm with device docs).

Required Driver

• Driver: MODBUS (built-in to Plant SCADA; no separate installation needed). This handles the RTU protocol (PDU + CRC).
• Do not use MODNET, as it is for Modbus/TCP.

Configuration Steps

Configuration is done in Plant SCADA's Citect Studio (or equivalent editor) under the Communications section. Set up Boards, Ports, and I/O Devices as follows:

1. Configure the Board:
   • Board Name: Arbitrary (e.g., "TCP_BOARD").
   • Board Type: TCPIP.
   • Address: 0 (required for Ethernet).
   • Leave I/O Port, Interrupt, and Special Opt blank.
2. Configure the Port:
   • Port Name: Arbitrary (e.g., "TCP_PORT").
   • Port Number: Arbitrary (e.g., 1).
   • Board Name: Select the board you created (e.g., "TCP_BOARD").
   • Special Opt: Use this to specify the TCP connection details. Format: -I<IP_address> -P<port> -T
     • -I<IP_address>: The IP address of the device or gateway (e.g., -I192.168.1.100).
     • -P<port>: The TCP port the device listens on (default to 502 if not specified; e.g., -P502).
     • -T: Forces TCP mode (required; UDP is not suitable for RTU).
     • Example: -I192.168.1.100 -P502 -T
   • Mode: RTU (or ASCII if needed, but RTU is standard).
   • Baud Rate: Set to match the device's serial settings (e.g., 9600 or 19200; even if over TCP, this may be used for framing/timing).
   • Data Bits: 8 (standard for Modbus RTU).
   • Stop Bits: 1 or 2 (match device; commonly 1).
   • Parity: Even, Odd, or None (match device; commonly Even).
   • Leave other fields blank or at defaults.
3. Configure the I/O Device:
   • I/O Device Name: Arbitrary (e.g., "MODBUS_DEVICE").
   • I/O Device Number: Arbitrary (e.g., 1).
   • I/O Device Address: The Modbus slave ID (e.g., 1; range 1-247).
   • Protocol: MODBUS.
   • Port Name: Select the port you created (e.g., "TCP_PORT").
   • Cache: Enable if needed for performance (default is fine for most cases).
   • Other options like Delay, Timeout, or Retries: Set based on network reliability (e.g., Timeout: 3000 ms).
4. Configure Tags/Variables:
   • In the Variables/Tags editor, create tags linked to the I/O Device.
   • Address format: Use standard Modbus addressing (e.g., 40001 for holding register 1, 00001 for coil 1).
   • Data Type: Match the device's data (e.g., INT, REAL, DIGITAL).

Testing and Troubleshooting

• Compile and run the project.
• Use the Kernel window or Tag Debug to check communication (look for #COM or errors).
• Common issues:
  • Timeout: Increase port timeout or check network/firewall (port 502 open?).
  • Bad data: Verify slave ID, addressing, and serial params match device.
  • If using a gateway: Ensure it's configured for transparent mode (no protocol conversion).

This setup encapsulates RTU frames over a TCP socket without additional headers. Refer to the Plant SCADA Driver Reference Help (accessible in Citect Studio) for MODBUS-specific params.

Hi Oliver,

I'va been testing without exit...

If I put DoCRC=0, goes online, but the next tag read fail....

With modscan goes online and read all values  (100 positions without problem)

The pictures are with DoCRC=1, and DoCRC = 0.

Any suggestion?

Thanks.

Hello Oliver,

Finally read the steam using Node-red. The modbus from Steam add at response TCP the CRC!!!, and driver MODNET says Data not valid...

There are some citect.ini option to use MODNET and CRC?

Carles

Hi Carles 

There are no Citect.ini parameters or options to configure the MODNET driver to handle CRC (Cyclic Redundancy Check), as it's fundamentally designed for the Modbus/TCP protocol, which uses a different frame structure (MBAP header) and does not include CRC for error checking—relying instead on TCP's built-in mechanisms. Attempting to use MODNET with a device or gateway that's sending RTU-framed data (which includes CRC) will typically result in "Data not valid" errors or similar, because the driver parses the response expecting the Modbus/TCP format without CRC.

Key Differences Between Drivers

• MODBUS Driver: Supports Modbus RTU (or ASCII) protocol, which includes CRC in the frame for error detection. It can be configured for TCP transport (e.g., via a serial-to-Ethernet gateway tunneling RTU frames over TCP without conversion), making it suitable for "Modbus RTU over Ethernet/TCP" setups. This matches what you described where "Modbus reads the TCP response the CRC" successfully.
• MODNET Driver: Specifically for Modbus/TCP (Ethernet-native), with support for Modicon PLCs and generic TCP-compatible devices. It expects the Modbus/TCP header and no CRC, so it will reject frames containing CRC as invalid data.

If your device is truly using Modbus RTU over Ethernet (e.g., RTU frames encapsulated in TCP without the Modbus/TCP header), stick with the MODBUS driver configuration as outlined in my previous response. That's the standard approach per AVEVA documentation and community discussions.

If you are still stuck and not able to find a solution, it might be worth exploring an alternative approach, such as gateway (PLC) to aggregate the data or another software that can communicate with the device and exposes an OPC layer for Plant SCADA to communicate with.

Kind regards

Olivier

Hi Oliver,

OK, thanks.

Now, we are doing a gateway in Node-Red, and reading it....

Kind Regards

Carles