Emerson Exchange 365

Hi Pete, you need to know that there is not unlimited comm_req resources available on the CPU. I'm pretty sure you are ok with two connections at the same time, but as you keep adding additional connections you may run out of these resources depending on how fast you are trying to communicate. I think the best approach is to stagger the comm_req's with some time in between so they don't all happen at the same time. It is also important to check all the status information returned from the comm_req so your code can handle any exceptions that may arise.

Since you are using a redundant pair, also note that the connection has to be restarted following a role-switch between controllers. Since you have one connection working you may have already considered this. The server (Delta V module) you are connecting to also need to support at least two connections for the role-switch to happen quickly. if there is only one connection available you have to wait for it to time out before you can re-connect.

Hi, Peter,
Mats Andersson has given your a clearly explanation, besides he mentioned, I want to add a little comments: There are 32 channels available for Modbus communication, You should use different channels between Prosoft module and EIOC modules

In reply to Jimmy Lee:

Below Information from GFK-2224Z manual:
<<10.4.1 Open a Modbus/TCP Client Connection (3000)
The Modbus/TCP Ethernet interface transfers data to or from another Modbus/TCP device
using a channel. Up to 32 channels are available for Modbus/TCP client communications.
However, these 32 channels are shared with SRTP Channels so that the combination of
SRTP Channels and Modbus/TCP Channels cannot exceed 32.
The Open Modbus/TCP COMMREQ requests the communication subsystem to associate a
channel with a remote Modbus/TCP device. Using the COMMREQs defined later in this
document the PLC may transfer data to and from a remote device.
Once a channel is allocated for Modbus/TCP Client communications, the channel remains
allocated (i.e. another protocol such as SRTP Channels cannot use the channel). The channel connection is released only when: the application program closes the channel,
the channel is automatically closed when the PLC transitions to STOP, when the Ethernet
interface uses a Redundant IP and the CPU transitions from the Active to the Backup unit,
the Ethernet interface is reset or the underlying TCP connection is terminated.
The IP address of the remote Modbus/TCP device is specified in the Open Modbus/TCP
COMMREQ using the standard dotted-decimal format. No other IP address format is
accepted.
The COMMREQ Status Word (CRS) indicates the success or failure of the Open
Modbus/TCP Client Connection COMMREQ. If the COMMREQ requests an invalid channel
number or an already allocated channel the COMMREQ fails and the CRS is set to a nonzero
value to identify the failure. See 10.5, Status Data for detailed CRS failure codes.》

In most DCS integration applications, the DCS is the Modbus TCP Client or Master. In this case no programming is required in the PACSystems RX3i since the DCS will initiate all requests and the PACSystems RX3i will respond automatically. You will need to configure the PACSystems RX3i for Modbus addressing to allow the %I, %Q, %AI, %R and %W tables to be read. Data in other tables and in symbolic variables can be MOVEd into these data table areas if required.

In reply to Steve Ward:

The CPE330 or RX3i CPUs do not have selective opening up of addresses of %I,Q, Ai, R , W.....If we enable it, all these tables are available to DCS/other TCP client for both read and write....Is there any way to have limited window?

In reply to Vikram Pungaliya (Prime Controls):

Modbus TCP is not a secure protocol and in the PACSystems RX3i the only options are enable or disable across the entire memory map. For applications requiring cyber security, disable Modbus TCP and use OPC UA with certificates for signing and encryption.

In reply to Steve Ward:

I may need to study more on the OPC UA on Rx3i PLC, but as COMMREQ is required in Rx3i to read/write data from/to modbus client....Can the OPC UA functionality in Rx3i CPUs read/write data from external OPC UA servers?. (This query may not be relevant to the main thread here...)

In reply to Vikram Pungaliya (Prime Controls):

Today the PACSystems RX3i is an OPC UA server only. We are working on pub/sub capability for peer-to-peer communications.

In reply to Vikram Pungaliya (Prime Controls):

Prime_Vikram, yes you can selectively control access to the memory map on the PACSystems controllers by enabling "enhanced security" on your target. When you set this property true you are first forced to add a target password. You can then select the register area access in the CPU hardware configuration under the tab "Access Control".

In reply to Mats Andersson:

Thanks Mats!

In reply to Vikram Pungaliya (Prime Controls):

Note Mats comment, you can use Enhanced Security and then enable Modbus Addressing and then use the Access Control tab to set no access (default), Read-only or Read/Write access to each area. For Modbus, this still only allows access to %Q, %I, %AI, %R and %W tables as before.

In reply to Mats Andersson:

Thanks Mats, i shall try this out.