Connection priority should be scheduled and usually the connection type on a PF755 is set to Point to Point (though Multicast might work, but I've not tried it.)  For a PF755, the communications array on the drive influences the number of bytes input and output.  The number of input and output datalinks sets the bit/byte offsets.  I've attached a screenshot of a "typical" PF755 setup we use (I say typical in that I took a few different customer configs I have done, combined and sanitized.  It is by no means the only or necesaarily the most correct, but a way to hopefully shed light on how it's configured.  The first datalink on the input direction is offset by 4 padding bytes.

Hopefully this helps, otherwise let me know if you have more specific questions.

In reply to Matt Forbis:

We use a lot of Powerflex drives on enet but none directly to EIOC. They connect to ENBT or similar on PLC then we use the EIOC to read/write data through PLC. I'm curious what the max number of drives you guys have seen connected directly to the EIOC? I wonder if there is any type of limit, for VFDs, in addition to the standard EIOC guidelines?

In reply to s_brwn:

On an EIOC, you are limited to 256 physical devices and 26 PID blocks. For drives, if you create a PCSD style manual loader that uses a PID block to control the speed, then that could be your limiting factor. You can also work around that with some creative custom module design, but in projects I have done in the past as a mix of motors of vfd and non-vfd, that usually doesn't become an issue.

Beyond those two limitations, I have not seen any other limits that would affect how many VFD's on an EIOC (or PK for that matter, except the number of physical Ethernet Devices is smaller).

In reply to Matt Forbis:

When you land the drives in a PLC, the EIOC sees a single device. The data is abstracted into PLC registers and you build you EIOC LDT's to map these into DeltaV Signals. The LDT's are of the same data type so you likely end up with booleans and bytes sent as an integer that is then broken up or combined in the EIOC Module. Or you have multiple LDT's for each device, giving you easier signal processing, (floats, integers, bits ) but additional licensing.

The Through put of the EIOC is based on having data communicating from 256 devices. When we consolidate to a PLC we have one device. Within that device, the LDT's are scheduled to allow other device communications from other PDT's. The schedule is one LTD every 20 ms for Ethernet IP (likely protocol to a rockwell PLC). You are forced to create additional PDT's in order to avoid RPI errors. Typically, you are limited to about 20 LDT's per PDT if the RPI is set to 500 ms.

If you eliminate the PLC and communicate directly, you will have a PDT per drive, and can use Class 1 implicit or Class 3 Explicit configuration depending on the drive. Class 1 Implicit resembles the configuration with DeviceNet where you can configure signals of different data types within the same LDT and work with Floating points, integers, bytes and booleans all under one LDT and therefore one License DST. And you eliminate the extra data concentrator PLC.

As Matt said, up to 256 devices per EIOC. or 16, 32, 64 or 128 per PK100, PK300, PK750 and PK1500 respectively. You get maximum through put as each device makes a dedicated Ethernet connection and has independence of communications. i.e. you can get all the signals at 400 or 500 RPI update rates. If all this were packed into one data concentrator PLC, you would likely need to group and manage data into different LDT's by data type and required update rates so that you get the process data at the required frequency by slowing the supporting data to a longer RPI.

By connecting drives directly to the controller (via VIM or with PK controllers) you have the control element (Drive) in the same controller as the process variable (Flow). Process balance of plant conditions from control modules in the controller are locally available to the Motor/Drive interlock logic and the motor state to the balance of plant interlocks in that controller. If motor control is being done over Ethernet communications, and there are no hardware IO associated with the motor control, having the motor in the EIOC is good. If you need start/stop/status wired signals, the module needs to be in a controller, and the supporting data from the drive would be better accessed in the controller module, avoiding a second module in the EIOC for data collection that feeds the control module that does Operator interaction. Prior to the PK, we used the VIM to integrate the motors and drives to the controller. The EIOC provides a good platform for a subsystem integration to a PLC or group of devices like analyzers that are not tightly integrated into the process closed loop control.

That doesn't mean the EIOC cannot integrate the drives. DeltaV Peer to Peer communication is fully redundant and automatically available. And if one is comparing performance between drives to a PLC to an EIOC, versus Drives direct to an EIOC, then that will inherently be better. If you have a PLC with logic and control functions acting on the drives and want to replace this logic, then a PK controller would be the better option as the Drives are direct to the processor executing the control, like the PLC was doing. The EIOC is well positioned to manage interface to a PLC when the PLC is an independent subsystem and we need to abstract that up to the HMI, sort of a scada play.

If you concern is performance on the integration of drives, eliminating an interim data concentrator PLC will improve performance and going direct to the EIOC will eliminate design complexities and simplify your configuration as well as the hardware design and footpring.

Andre Dicaire

In reply to Andre Dicaire:

I've see the data arranged in arrays:  

• DvTx_MtrCmd[0..49] INT
• DvTx_MtrSpd[0..49] REAL
• DvRx_MtrSts[0..49] INT
• DvRx_MtrSpd[0..49] REAL
• DvRx_MtrAmp[0..49] REAL
• DvRx_MtrFlt[0..49] INT

The EIOC is reading 4 datasets and writing 2 datasets where each is an array of 50.  So you get 50 motors with 1 device and 6 LDT's

The control strategy points to the array element.  Motor 0 uses element 0... e.g. MtrCmd[0], MtrSts[0], MtrAmp[0], MtrFlt[0].... etc.

The MCC uses DHCP per port where the Ethernet switch ports are label 0..49 so whatever device (VFD, SS, FVNR) is plugged into port 0 will be element 0 in the arrays  e.g. MtrCmd[0], MtrSts[0], MtrAmp[0], MtrFlt[0].... etc.

Only the data need for the control strategy is mapped to the DeltaV controller. All the other data (fault codes, warning codes, extended properties, energy consumption, temperature, etc.) is exposed as OPC data which goes directly to the Historian or other analytic tools.

Hi Adam,

We are currently working on interfacing the PF755 (20-750-ENETR) with the DeltaV PK via Ethernet I/P. Given your experience with this configuration, we would greatly appreciate any insights you have on the setup and data mapping.

Thanks!

In reply to Abhi:

I followed what Matt Frobis replied with and it worked for me. I would suggest trying that and seeing how that works for you.