• Not Answered

Best way to communicate with AB PLC and PK Controller.

I need to connect a Allen-Bradley PLC to a PK controller and read the signals from the PLC.

We have only ever used DeviceNet to communicate with PLCs.

I am not sure how to bring the signals into DeltaV based on the information that the vendor has provided.

Can anyone please provide some guidance on how to do this.

Map Descriptor Name	Data Array	Array Offset	Data Point Description	Data Type	Object ID	Scale	Units
Header_Pressure_A	PM_Data	0	Header Pressure Transmitter A	AI	1	0-300	PSIG
Header_Pressure_B	PM_Data	1	Header Pressure Transmitter B	AI	2	0-300	PSIG
Header_Pressure_C - Reserved	PM_Data	2	Header Pressure Transmitter C - Reserved	AI	3	0-300	PSIG
Header_Pressure_Average	PM_Data	3	Header Pressure Averaged for Plant Master Loop	AI	4	0-300	PSIG
Plant_Master_CV	PM_Data	4	Plant Master Pressure Loop Control Variable	AI	5	0-100	%
Plant_Master_SP	PM_Data	5	Plant Master Pressure Loop Set Point	AI	6	0-100	%

Thank you in advance.

Adam Villhauer

• 19 May 2025 12:12 PM
• Cancel

5 Replies

• Scott Thompson

  

  • 19 May 2025 8:07 PM

  To talk to an A-B PLC from the PK you would need to make sure P01 is enabled with the protocol set to Ethernet/IP and a unique IP address configured. You can also specify which port is being used to connect to the network the PLC is on.  It usually defaults to port 3 which is the bottom on the left.  Downloading changed setup data to the controller if you make any changes to the outbound message port.

  

  Under P01 on the PK Controller you would configure a new physical device specifying the IP address of the PLC.

  

  Under that physical device you would define the logical device to reference the data specified by the vendor.  As the vendor supplied you with a Logix Tag reference you would want to configure Messaging Class as UCMM with Logix Tags, 6 values, Input direction, Floating point datatype, Rack number 1, Slot number 0 (most likely, might have to make sure the ethernet card is the first rack which it most likely is, processor is always in slot zero for ControlLogix), put PM_Data in the Logix Tag Name. Requested Packet Interval (RPI) will be how often the controller asks the PLC for the data.  Extended address can be left unchecked unless the source data is being passed through other PLCs on the way to the PK Controller.

  

  This will create 6 signals under the logical device for the six inputs in the PM_Data array.

  If you have other ethernet connected IO devices you'll need to make sure you have sufficient licenses to add another connection (physical device).  If this is your first ethernet device in your DeltaV system you will need licenses to enable Ethernet/IP communications (I think it's VE4105) and VE4109Sxxx where xxx is the number of physical devices you will be talking to.

  • Cancel
• Matt Forbis

  

  • 20 May 2025 12:06 PM

  In reply to Scott Thompson:

  I just want to add two small things to Scott's answer which is exactly what I would recommend as well. While Rockwell/Logix supports mixed data type array's, DeltaV does not, so make sure when defining in the PLC that you group all of a single data type together into a tag.
  
  Second, I don't believe a PK requires a VE4105 (the EIOC does - which is another way to bring in this data as well and potentially more cost effective for large amounts of data and/or devices and/or PLC's).

  • Cancel
• Andre Dicaire

  

  • 21 May 2025 2:14 PM

  Having the data defined in an Array is a good start. The PK controller supports EthernetIP protocol, which is the Ethernet version of DeviceNet, but with much more capability.
  
  The first step is setting up the Ethernet IO port on the PK controller. There are two parts to this.
  A: Set up the Ports of the PK controller. This is done in the Controller properties where you can enable and segregate the RJ45 ports for how you need to use them. Refer to BOL for more details. In v14, your do the port assignments in the controller properties, and you define the Subnet addressing in the P01 port of the controller. In V15, The port assignment has been enhanced and is where you define the subnets you plant to use. You can also define Gateway addresses for each subnet here.
  
  Note, a redundant EIOC or PK reserves the Secondary Address based on the primary. i.e. primary card= 192.168.1.10, then secondary card is assigned 192.168.1.11 and also on the Secondary Network which uses a separate subnet i.e. 192.168.2.10 and 192.168.2.11.
  
  At the P01 port, you enable and select the protocol and set the IP address of the PK or select the defined network in v15. You will be using the UCMM for control tags.
  
  Now you define the PDT (Physical Device Tag) where you set the IP address of the PLC. If it has redundant network ports, they must set up on separate IP addresses to use the redundancy of DeltaV. If so, enable redundancy and define these addresses on the PDT. These secondary addresses must be in the subnet you've defined on the PK (or you set the PK subnet to match the PLC IP addresses)
  
  Finally, you create an LDT (Logical Device Tag) Here you select the UCMM option. Class 1 implicit is mainly for simple end devices/IO, Class 2 Explicit supports legacy plc's, where you would have File structures holding the data. For current Rockwell PLC's, you would use UCMM for control tags and point this LDT to your array tag in the PLC. Match the data type as Analog In to align with the data type of the array.
  
  One LDT can pull in an array tag of up to 100 signals. You assign each LDT signal a unique signal tag name and that is your DeltaV IO reference tag, which can align with the register in the PLC Array.
  
  The LDT is assigned an RPI time, Request Packet Interval, which drives the PK polling schedule to the device. With EthernetIP, a PDT will poll its configured LDT's in sequence, one every 20 ms. For an RPI of 500 ms, you can schedule up to 25 LDT's, however, that leaves no margin and would likely result in occasional RPI errors (response took longer than target RPI). Emerson recommends no more than 80% loading so 20 LDT's for 500 ms RPI would be a good target.
  
  Mixing faster and slower RPI LDT's on the same PDT will not result in a balanced polling. Occasionally, all LDT's will be polled in the same cycle and that will trigger an RPI error on the faster LDT's. If you have a need for a lot of data from a single PLC, you will likely need to create additional PDT's. Each PDT creates a new connection and independent polling of LDT's. However, they also require a Physical Device License, and since they will reference the same device IP address, will generate a warning on download. You can ignore this warning and the additional PDT's will provide you added bandwidth to that device.
  
  For a single Array tag, you will have no issues in this respect.
  
  In DeltaV Diagnostics, you can confirm connection and can view the data from the LDT. This lets you know your network connection is working and from they you can build you configuration. If there are issues establishing connection, you may need to use a network capture tool like Wireshark to identify the issue. This will need a mirrored port on a switch of some way to connect and collect the capture. Being able to do a network capture is always useful to trouble shoot third party networks and to pinpoint why connections are not working.
  
  Good luck

  Andre Dicaire

  • Cancel
• Adam Villhauer

  

  • 28 Jul 2025 6:41 PM

  This is what I have so far.

  How do I know what Array Offset each SIGNAL is pointing to?

  Also I assume that I set the second set (PM_BitData) up the same way but use the Boolean and not the floating point? This requires that I create a new LDT for each set of data?

  Thank you all.

  Really hope these pictures comes through.

  ......

  • Cancel
• Adam Villhauer

  

  • 28 Jul 2025 6:43 PM

  In reply to Adam Villhauer:

  Guess they didn't come through the first try.

  

  

  • Cancel