Emerson Exchange 365

In reply to Andre Dicaire:

This has been a very useful discussion. It has been very informative. If I could ask one question to clarify what I am hearing.

I have a system with about 150 devices that I was thinking as candidates for EIOC until reading this discussion. All of them are using Modbus communications. About half clearly fall into the sub system category. The other half are communicating with VFDs. All communications with the VFDs are via Modbus. What I have is a mixture of technologies and the number of places within the system where there is a single point of failure bothers me. At first glance the EIOC looked promising as a way to improve my redundancy. I am hearing a lot of concern with using the EIOC with a system using VFDs. Is this issue just one where the set point going to the VFD is a part of a control loop where it will be changing frequently or is it also an issue where the set point is manually set? If I had a control module attempting to send a SP to a VFD via Modbus over the EIOC, what would be the problems that you would expect that I would encounter?

Thank you for the clarification!

In reply to gamella:

Gamella,

The main reason for Landing Modules was the licensing scheme of DeltaV, where a Modbus Dataset required a DST for every module that referenced a single register. Also, customers chose to pack individual bits into integers so that they could move many more signals for fewer DST licenses. The Landing modules then unpacked the registers to allow modules to references the bits or bytes as needed. Over the years this has become the defacto method to bring data into DeltaV via the VIM.

In v12, DeltaV licensing changed and each data set now only requires a single DST, no matter how many times it is referenced.

Pulling in a Dataset for DI or DO signals is possible in the VIM and allows modules to work directly with these bits out of the dataset. You can reference an Integer or Float register from a VIM using an AI block or a Boolean value using a DI block if the data set is Boolean.

Andre Dicaire

In reply to Andre Dicaire:

I have to retract an earlier statement. With the M-series carriers, the 2 wide carriers have a Redundancy connection at the upper left corner. I just checked on my PK carrier and this connector does not have an accommodating hole, and as a result, the LocalBus connector between the PK and 2 wide carriers is not fully engaged. The same issue occurs with the Left Extender module which also does not accommodate the redundancy connector on the M series 2-wide. So although this will work in software, the mechanical connection of the two carriers makes this unsupported.

I can see three reasons why we need the 2-wide carrier on a PK:
1. Use a VIM for simulation when IO includes Bus cards or FF. These are not supported in virtual controllers.
2. A VIM is required to support a second protocol on the PK.
3. The IO bus contains more cards than the PK 3 Amp power supplies can provide. i.e. I need System Power supplies.

When the S series connector for the PK carrier is made available, the S-series two wide connectors will be possible next to the PK because these 2-wide carriers do not have this redundancy connector, and currently will connect to the left side extender.

So if you are thinking of using a PK controller with a VIM, you will have to modify a carrier. Sorry for the confusion.

Andre Dicaire

In reply to Andre Dicaire:

I'm having a bad week. OK, the VIM does work with the PK controller. This was tested, and my concern over the carrier was a mistake on my part. Likely born out of the issue with 1 wide extenders (which do not fit on the left side of a 2 wide).

So you can install a 2 wide to the right of a PK, install a VIM, or two or additional system power supplies.

I'm going to check my self into a rehab center or something.

Andre Dicaire

In reply to Andre Dicaire:

Do you have any references for how to configure the communications between the EIOC and a compact Logix controller? Rockwell hasn't been much help.

In reply to Roger Priestner:

Roger,  Emerson is preparing an Implementation guide to provide some best practices and recommendations for this. 

In v13, the EIOC was released with the Ethernet IP Protocol that supported UCMM logix tags.  Prior this, the approach was to use a VIM which emulated Modbus Datasets of up to 100 integers or 50 Float variables.  Prior to UCMM support in the PLC, we had to create mapping files in the PLC and use the Class 3 Explicit PCCC format. These files required the PLC to taken offline for modification.

So the UCMM aspect of Ethernet IP affords us the ability to add/modify UCMM Array Tags in the PLC without taking it offline.

With UCMM Logix Tags, you have to map the PLC data into Array tags which you can then map into EIOC Logical Device Tags (LDT's).  Each LDT can be up to 100 Signals (Registers) and the LDT starting address is fixed at 0 (first register in the UCMM Array)

The LDT can be configured as an Input, and Output or an Output with readback.

A couple of things we've discovered.
1.  The Ethernet IP protocol uses Complete Block Writes to the UCMM tag.  Unlike the MODBUS TCP driver, or the VIM drivers, Individual Writes are not supported in the Ethernet IP protocol.

There are various reasons for this approach,  but this can affect Bidirectional parameters.  When one signal is changed, the entire LDT is written.  Care is needed to ensure a value changed in the PLC is retried to ensure it is not overwritten due to a write to a different parameter.

2.  The amount of Data and the update rate may exceed the capacity of a single PDT, and you will need to create multiple PDT's to handle the complete data map.

V14 BOL states that it is recommended to have one Control module perform writes to an LDT.  This applies to data that will be continuously written to by DeltaV.  It mainly applies to Small Devices such as motors and drives where DeltaV is the Host for the control decisions.

In a PLC, the integration is more of a SCADA application, where the PLC hosts the control Data and the EIOC is providing the DeltaV HMI/operator with the ability to view and manipulate the PLC data registers.  Therefore, the vast majority of writes are initiated by Operator actions.  In a SCADA application, having multiple modules write to the same LDT does not cause any issues. 

In our application, we use bidirectional LDTs to handle parameters like SP, OUT, MODE, and Tuning values like GAIN, RESET, RATE, and alarm values like LIMIT.  We also use these for Bypass bits on interlocks and such.  This simplifies the DeltaV EIOC Control modules by allowing the same parameter for data entry writes and for displaying the current value in the HMI. 

Data Performance.
the EIOC uses a PDT to define the IP address of the End Device.  Under the PDT you create the LDT.  You can create up to 256 LDT's under on PDT.  which is a lot of parameters.  However, the more LDT's you create, the longer it takes to get these processed.  The maximum number LDT's per PDT is around 50, but it is recommended to leave some free time, so that the max is really more around 40 to 45 LDT's per second.   If you want say a 500 ms Requested Packet Interval (RPI), you should limit the number of LDT's to 20 in that PDT. 

To maximize the amount of data being exchanged, you need to consider maximizing the number of Registers/Signals per LDT.  This will reduce the number of LDT's and subsequently improve overall data exchanged.

Step 1:

The simple math is to determine the number of registers you need, assign these to an arrangement of LDTs (Floating Point, 16 bit integer, 32 bit integer, Boolean in and out, etc).  Use the smallest number of LDT's that makes sense.

Step 2:  Determine the fastest Update rate required for any LDT's.  The Fastest LDT's go into the first PDT you create for this PLC.  The maximum number of LDT's in this PDT depends on the fastest RPI / 25.  For example, if you one or more LDT's at 500 ms RPI, divide 500 by 25 to get maximum number of LDT's in this PDT which will be 20.  If you have 20 or less LDT's total, place them all in this one PDT.

Step 3:  If you have more LDT's that the maximum allowed in the first PDT, you can slow down the fastest RPI and increase the LDT count.  If you increase the minimum RPI's to say 1000 ms, you can have 40 LDT's in that PDT.

Step 4:  If you have more LDT's than you can place in the first PDT, (assuming there is at least one LDT at 500 ms and you have more than 20 LDTs, or you have more than 40 LDT's, or what ever the mix of RPI and LDT count) You can configure a second PDT to the same IP address.  This will create a warning when you download the EIOC port, but this is supported.  To maximize the LDT capacity, you should consolidate the faster LDT's in the first PDT, and place slower LDT's in a second PDT. 

Step 5:  If you exceed the LDT count for your first 2 PDT's, you can configure a 3rd PDT to the same PLC.  Again, based on your overall LDT Count, the RPI update rates need to allow for the number of LDT's required. 

With this approach, you can have up to 2000 signals updating every 500 ms in a PDT with 20 LDT's all set to 500 ms.  Note that if you have 10 LDT's at 500 ms RPI, and you cannot have more than 20 total LDT's to the PDT, even if the balance of the LDT's are set to 1 second or even slower.  Exceeding the max allowed LDT will cause inconsistent updates on the LDT's that have the faster Update rate, creating significant jitter in their update rate.  If the 500 ms RPI is important, keep the LDT count to the recommended max of 20.  If it is not that important, then use a slower RPI and increase the number of LDT's.

If you have less than 2000 signals to exchange and can fit in 20 LDT's, all is good and carry on.

Given your configuration and data types and update rates, you may not maximize the LDT signals to 100, and that means more LDT's for the same signal count.  That is fine and makes sense.  But as you increase the LDT's you need more time in the scheduler.  So it is a balance to keep in mind.

Each PDT creates a unique schedule with the EIOC.  Creating a second PDT for a PLC means we can schedule more LDT's without interfering with the schedule of the first PDT. If you create a second PDT and the fastest RPI is 1000ms, this PDT can host 40 LDT's, or 4000 registers/signals.  that gets us to 6000 signals from one PDT, with a third of them at 500 ms updates. 

If that is still not enough, consider a third PDT set with LDT's at 2000 ms, or an additional 8000 signals.  That is a total of 14,000 signals from one PLC.

How many PDT's can I configure on one PLC?  Now that gets into some variables that carry into the PLC Ethernet Port.  The golden rule is to use the fewest number of PDT's to meet your needs.  If you want the EIOC to pull 32K signals all from one PLC, you'll have to schedule some as slow as 5 second RPI.  You also have to consider the bandwidth of the PLC ethernet port, how is it configured and how many other connections is it supporting. 

When it comes to the EIOC, each PDT forms an independent scheduler.  The schedule is simple.  It schedules all the defined LDT's in series with a delay between each LDT communication.  Adding a second PDT gives you a second scheduler that is operating in parallel.  Now we are asking for up to two LDT's within the same time frame.  This increases the data capacity requirements of the PLC Ethernet card.  The typical LDT response from the PLC is in the 2 to 3 ms range, but could be longer.  The more PDT's we configure to the same PLC, the more outstanding request that can happen and the more likely you will see a rejected or timed out request from the PLC.

What we found was that adding a couple of PDT's improved overall data performance, (reduced latency).  But adding too many resulted in intermittent Bad Status on LDT's.  Just like you prescription drugs, a few pills a day is good, too many and you're in trouble.

What about that Complete Block vs Individual Writes.  This impacts the Bidirectional LDT's, which will write the entire LDT when one register changes.  Rule number one.  No continuous Writes to signals in a bidirection LDT.  There is a KBA that indicates you should use an RPI that twice as fast as the DeltaV Module.  This allows a write to be processed in one scan, a read back to occur on the LDT's next scan, so that the LDT updates in between the writes.  Since you have to also consider the PLC logic and other timing issues, continuous writes to a bidirectional LDT will cause data overwrites that could be always, but worst could be intermittent.  We ended up finding this during FAT with customer.  We implemented a data confirmation loop since our situation had several possible sources for parameter changes, including internal sequences in the PLC.  The sequence did a one time write to a control parameter and if DeltaV Overwrote this, the sequence would fail.  Since the block write is triggered by any signal change, the Operator can be changing the SP on one loop and cause an overwrite of data on a different loop. 

Our solution was to monitor the change source.  If the PLC value was changed by a different source than the UCMM source, we write the new value to the UCMM register and ignore any change to this UCMM register until we confirm the PLC value was seen by DetlaV.  This requires that in the DeltaV Module, we Write back the value we see in the PLC via a second UCMM register.  When the PLC sees the confirmation value is the same as the PLC value and the UCMM value, we know that the value has been successfully processed and any block write from DeltaV will send the same value.  For the SP value, it is only available to the Operator when in AUTO mode.  THis confirmation feature is only enabled when in Auto.  IN MAN, the SP tracks the PV and so is continually changing in the PLC.  We write these to DeltaV UCMM register and reflect this to the HMI, but in DeltaV we do not write to the confirm value.  Similarly for the OUT value.  In AUTO mode, it is driven by the PID and constantly changing.  We send it to DeltaV but DeltaV does not update the confirmation value. 

For Alarm limits, Tuning values and such, these are not dependent on PID mode and can be changed at any time.  Though infrequently changed, if changed in the PLC via local HMI or configuration tool, DeltaV must be updated and if a block write occurs at the same time, we don't want them overwritten or lost.  So we use the Confirm method above, which is always active.

For our case the customer stated that the PLC is the master of all its data and in no way or at no time should the EIOC overwrite any data that is changed from the PLC side.  That was our solution.  If individual writes were available, conflict would only arise with a simultaneous change to a single parameter.  That is no different than two DeltaV consoles trying to change the same DeltaV Module parameter.  Last one to write wins.    Block writes make it that any write to any signals overwrites all signals. So care is required to secure the data.

In v14, we now have the Control Tag Integration protocol which is a variant to Ethernet IP, supporting Logix tags and the User defined tjags in the PLC by name.  I have not had a chance to explore this protocol yet.  It does leave you with a higher DST license cost, but is intended to eliminate UCMM array mapping and data movement within the PLC.  It has great potential.

Andre Dicaire

In reply to Andre Dicaire:

I really appreciate your prompt and thorough reply. In the PLC I mapped file 0 to the array of the double integer controller tag I created. What is interesting is we are getting the data from the PLC into DeltaV. Is there another detail I missed? Thanks.

In reply to Roger Priestner:

Sounds like you created a file in the PLC and mapped this to a UCMM tag, and mapped the UCMM tag to an EIOC PDT/LDT.  The LDT polls the UCMM tag.

Did you configure the LDT as OUTPUT and wondering why your seeing PLC data in the DeltaV signals?  I think that's because I misspoke.  In the UCMM tag configuration has options to set as Input, output.  I'm looking at the LDT configuration and for UCMM with Logix Tags, and there is option for no Output with Readback.  So it actually Output means Output with readback.  (I was told this was configurable like the Modbus TCP but did not check this detail.  my bad.)

So you should always expect the LDT to show you the current value in the UCMM tag, regardless of whether it is Input or Output.

The concept of an Output only LDT is one where you never read it, and so don't care about the read back. 

Because you've mapped to a file, you have to write logic to pull and push data from the file. We did not use files since the UCMM array can be manipulated directly from the PLC code.  If this is a migration and the data exchange was created using the PLC N and I files, it is likely better for you to map the files to UCMM and avoid changing code in the PLC.  you can also use the Class 3 explicit PCCC messaging that allows yo to map directly to the files, as shown in picture below:

Notice that the Class 3 method allows you to set the starting address of the LDT.  The UCMM method does not.  UCMM forces the LDT to read from the first register in the UCMM Logix Tag array.  If the PLC File has more than 100 registers, you have to map them to separate UCMM arrays so the data is addressable from the first register.  If you mapped 500 registers into one Array tag, the EIOC cannot read the ones over 100 with UCMM.  The Class 3 explicit does allow yo to reference the higher register indexes. 

Also not that with UCMM, if you created an array with 100 values, but decided you wanted to use multiple LDT's to read the data for reasons of mapping to different modules or updating at different rates, you cannot.  All LDt's start at 0.  the Class 3 explicit would allow this.

The UCMM Logix Tag have one advantage.  They can be added and changed without stopping the PLC.  The files have to be added offline.   I like the UCMM for this reason. If the mapping is already fixed and done to the Files, it's your choice and Class 3 explicit does give you some added flexibility in the starting address.  But if you are adding UCMM tags to the file, you can map any range of file registers to the first group of registers in the UCMM tag and that lets the LDT link to any range of registers in the PLC File.  So the UCMM file can give context to the PLC registers in the PLC, and then you map that context to an LDT for use in DeltaV. 

With an Output LDT, you should be able to see values from the PLC.  Map an LDT signal to a DeltaV output parameter via external reference.  You will see the value from the PLC here and if you write it, the value will appear in the PLC.  Works great.  with manual writes you will not see an issue.  Now create a second module and add a signal generator and wire this to a different Output parameter mapped to the same LDT.  Now you have a continuous write occurring from this module.  If the LDT is set to an RPI that is 1/2 that of the module scan time, you can test the effect of Block Writes.  Since the signal generator writes every scan of the module, the LDT updates in between module writes.  If you now change a value in the PLC using the PLC configuration online tool, you may or may not see the value appear in DeltaV.  It will depend on whether you set the value before a write execution of the module or a read by the LDT.  If you set the LDT RPI to the same value as the module execution time, I expect you will no longer be able to see any change to the PLC data because the DeltaV Module is continuously writing the data in the LDT to the PLC prior to doing read. 

When you have no continuous write to the LDT, you'll find it hard to lose a write from the PLC due to a manual write from DeltaV.  it is still possible, but highly unlikely.  If the PLC data changes are continuous, they will get through on the next scan, such as the OUT value of the PID in AUTO mode.  The data transfer from the File register likely fails and subsequent write to the File register updates DeltaV.  The value written would be the last value sent prior to the DeltaV write, so likely the worst the happens is the OUT value holds for one scan if at all affected.  One off changes like a Tuning value or a change in SP from a PLC Sequence, these can be lost if a write occurs to any register in the LDT.   

If the PLC will be controlled solely from DeltaV and all tuning values and control parameter changes will come from DeltaV, the Complete Block write behavior on outputs will likely not cause any issue since values will not change in the PLC except when they are under PLC control.  That is, when in AUTO mode, the OUT value is reported to DeltaV and the Operator cannot change this value unless he places the PLC in MAN.  While in AUTO mode, any write to OUT as the result of the block write is ignored by the PLC and OUT is immediately restored to the PID OUT value.  (note.  If writing to OUT while the PID is in AUTO causes unexpected disruption of signal to the field, this is something of concern, but the block write behavior is more one of a hesitation in the signal, where on a single scan, the PLC UCMM register is written to by DeltaV and receives the previous OUT value, and the worst that happens is the OUT value goes back to this value and then continues.  )  Keep in mind that DeltaV is updated all the time, so a BLock Write typically involves one new value and all other values get the last value they sent. 

Keep all continuous writes in Output only LDT's.  SCADA control of the PLC from DeltaV HMI should be based on manual data change.  Cascade control from DeltaV to a PLC is not SCADA and you should separate such control from the SCADA functions that integrate the PLC to DeltaV HMI.

Good luck.

Andre Dicaire

In reply to Andre Dicaire:

I really appreciate your help. We are planning on installing this on Thursday and I know nothing about DeltaV. The other guy in the office I am helping is very knowledgeable. I am doing the PLC side and we have been working on this together and sharing your information.
This is a new installation so we wanted to use the UCMM and as you mentioned communicate directly to the tags. The mapping was an attempt to get it working. I have created new tags in the PLC for testing, Data_From_CLX as a DINT array of 10 and another one Data_To_CLX as a DINT array of 10. I populated the Data_From_CLX as a DINT array with numbers without doing anything else and those numbers show up in Delta V EIOC UCMM as inputs. When we write data from the EIOC to the Data_To_CLX as a DINT array we just get a bad indication in the DeltaV. DeltaV is configured for 32 bits. I can send you some screen shots later this morning.

In reply to Roger Priestner:

lets try a float/real array. do not link it to any file.

that way we avoid signed/unsigned or Big/little Endian or word order issues.

set the LDT RPI to 500 ms and set module to 1 sec for test.

in diagnostic you can view data values and observe the entire dataset. status should be good. set a few values directly in PLC and confirm they are updating in this Output LDT.

Set your Output parameter in the test module to reference one of the values and download. in online view write a value.

check the PDT status parameter in diagnostics. it should be 0. trend this value using Watchit.exe. (good little app for testing) enter path to status. right click on parameter in diagnostics to see full path.

now, if the write fails, do you get a value of 5 or 6, or other? what error message do you see.

you might try to increase array tag size but leave LDT at ten, just to make sure we aren't dealing with a register offset.

confirm error is in LDT status, not a DeltaV write error due to security or plant area assigment.

send screen shots if you have them.

Andre Dicaire

In reply to Andre Dicaire:

Hello, Andre,
Your thorough explanation is really helpful with a similar project I'm working on. I'm able to read/write data from EIOC to a ControlLogix PLC using the UCMM messaging. Since UCMM doesn't give me the option for any offset, and my READ/WRITE signals are mixed in the same controller tags in ControlLogix, I thought using the Class 3 with PCCC messaging might be a better way without adding too many code in the PLC logic. However, I’m unable to read mapped integer file from ControlLogix so far, I tried the Class 3 with PCCC with a SLC505, I ‘m able to read integer file from it directly. Is there additional configuration required in the ControlLogix to use the Class 3 with PCCC besides the mapping table? Your help is greatly appreciated!
Thank you!
Ally Zhang

In reply to azhang:

My understanding is that the Class 3 PCCC is based on creating N or F files in the PLC, which emulates older PLC5 architecture, which I'm thinking the SLC505 does. The UCMM tags bybass this and can be added/modified online in the PLC. The PCCC Files must be added or modified off line.

But I'm not sure how to advise you further. Using the N Integer file will allow you to create LDT's that start at different addresses in the same file. However increasing the LDT count requires that you use longer RPI times so that all LDT's can be polled in one cycle. Although not stated in BOL, it is recommended to use the same RPI for all LDTS in an PDT. Faster LDT's will be delayed on scans where the number of LDT's exceeds the recommended limit of the fastest RPI.

We are anticipating a KBA or whitepaper with more information on recommendations for PLC integration. I know that the UCMM implementation does not support individual register writes. it is my understanding that the Ethernet IP protocol uses Complete Block writes for all sub forms of the protocol (Class1, class3, UCMM..)

Andre Dicaire

In reply to Kent:

Kent,
Emerson also offers Industrial Ethernet Services to help you discover, define and develop solutions. We know there are a lot of options for connecting 3rd party devices, and every customer's needs are different, so we developed a service to allow our experts to make it easy. Send me a message if you want me to connect you with the industrial ethernet services team. There is also a Service Data Sheet here: www.emerson.com/.../service-data-sheet-industrial-ethernet-services-deltav-en-5906434.pdf

Thanks!