Emerson Exchange 365

• Not Answered

EIOC communication with E300 (Ethernet)

We have DeltaV 14.3.1

Project: communicate EIOC with E300 (ethernet).

We need to know the communication parameters for EIOC to communicate with the E300. so far we have achieved with class3 explicit but not sure if this is the correct?

Vithal Modak

• 3 Oct 2023 3:36 PM
• Cancel

5 Replies

• Matt Forbis

  

  • 9 Oct 2023 12:59 PM

  See if these settings will get you started:.

  

  For the signals, they will vary by application.  The most important two are probably OUT0 which is an output with a byte/bit offset of 0/0.

  This is a typical sanitized signal list I developed for one of our customers.  They might not all apply to your situation and you might have to add more based on your needs, but it probably will give you an idea of how to translate the manual to deltav.

  

  Hopefully this helps!  Otherwise, please feel free to ask additional questions.

  • Cancel
• Vithal Modak

  

  • 14 May 2024 9:06 PM

  In reply to Matt Forbis:

  Thanks Matt. we were able to establish the communication with E300 (Ethernet) to EIOC.
  Now I have a follow-up question:
  brief project description:
  we are retrofitting old Devicent motors to E300 -ethernet motors.
  each redundant EIOC pair has ~50 motors (we have two pairs -A and B network). we have ring formation thru start switch network.
  Question: in the existing Devicent configuration if there is communication loss occurs then we trip the motor immediately. but with the ethernet communication should we keep the same as immediate trip or should add some delay may be 3-5 sec.
  Please share if anyone has done similar kind of configuration
  
  Thanks in advance.

  • Cancel
• Matt Forbis

  

  • 15 May 2024 1:20 PM

  In reply to Vithal Modak:

  That's more of a process and safety question than a technical question. That being said, I have worked with customers who configure both in DeltaV and the E300 for an instantaneous trip on communication loss as well as customers that will not trip in the E300 and have a time delay in DeltaV.
  
  One thing I will point out is that by setting devices up for trip on communication lost, you will run into the occasional issue with a switchover of a redundant EIOC. Since an EIOC is different than a controller and DeviceNet card, it has to re-establish the connection from the second EIOC. Between logic in DeltaV and configuration that could occur in the device, special care has to be taken to avoid this situation and in some cases, I don't think it can be completely avoided. Where this becomes important is online upgrades where you have to do a switchover to upgrade the Active.
  
  The customer I worked with was extremely risk adverse and so they would rather trip on a switchover, so we didn't investigate too far in depth as to whether when setting the trip on comms loss in the E300 could be avoided or not.

  • Cancel
• Andre Dicaire

  

  • 15 May 2024 3:04 PM

  In reply to Matt Forbis:

  Agree with Matt that a modest delay on the device side will avoid spurious trips due to transient conditions, like a switch over.
  
  BOL discusses setting up matching timers in the DeltaV module that will set the EIOC signal to passive if communication is not restored. Think of it this way, you are not trying to align these timers precisely, but rather you want to survive a spurious loss of comms that comes back quickly, within a second or two. To be predictable, the timer in the device needs to be longer than DeltaV to avoid the device going passive but DeltaV immediately restarting the device because its timer has not timed out.
  
  If the comm loss lasts longer than the DeltaV Timer, taking into consideration module execution time, DeltaV sets the output passive. At this point there are two possible situations: The comm outage continues and motor trips due to loss of comms. Or the comms are restored before the motor trips and DeltaV stops the motor. Both conditions result in a motor stop.
  
  If the Comm outage is restored before DeltaV timer expires, DeltaV leaves the command unchanged and motor continues to run or if stopped stays stopped.
  
  Making the two timers too close to each other, or the same leaves a small window where the motor trips, but DeltaV module immediately tries to restart it because the timer allows one more module execution.
  
  Consider that at the time of the Communication outage, there has been no process change, no interlock condition related to the process has necessarily occurred. A three to 5 second delay on the motor trip will impact the process, and that most likely results in either loss of production or creates more serious concerns in safety. So riding out a transient network event can have a significant positive impact on the facility.
  
  If a timed delay is implemented, consider the DeltaV Timer as the master, and set the device timer slightly longer. A true transient event won't trip either timer and motor continues to run.
  
  Many of our customers implement a hardwired E-Stop signal and don't stop on loss of comms. Emergency or safety stops are independent of the Ethernet control. The motor still has its local interlocks and process interlocks through the Motor control module, and can be stopped over the Ethernet communications. A loss of comms will trigger the emergency stop as deemed necessary. If there is no hardwired E-stop, then a loss of comms timeout is recommended. The timer values are cases by case specific.

  Andre Dicaire

  • Cancel
• Andre Dicaire

  

  • 15 May 2024 3:25 PM

  In reply to Vithal Modak:

  Many customers have A and B networks. On a single EIOC, you can configure the P01 port to be redundant and place A devices on the Primary and B devices on the Secondary. (unless you've deployed PRP). Devices like the E300 do not support redundant clients, but you can still connect them to the primary or Secondary network of the EIOC.
  
  When we originally tested the E300 with the EIOC in v13, we discovered the E300 would reset before it would recognize the new client on an EIOC switchover. Typically, redundant PLC's swap the IP address so the active processor uses the host address and the devices don't see a change in IP Address. The EIOC uses a different IP address for the secondary card. Our customer had some pull with Rockwell and the device was updated to survive a change of IP address.
  
  By using both networks, the EIOC will not switch over on loss of comms to the Primary network, since active communications are persisting over the secondary network. A failure of the connected switch or cabling causing loss to all devices cannot be fixed by a switch over of the processor as both processors require this same external hardware.
  
  Even if you keep the two EIOC's dedicated to A and B networks, you can subdivide the A network and further reduce impact on the number of affected devices due to such a failure. Or you can split A devices across both EIOC's on the primary network, keeping all these devices in the same subnet, and split the B devices across the Secondary network connected to both EIOC's.
  
  The impact of doing this is that the A and B devices must reside on separate subnets as the EIOC primary and secondary networks must be defined as separate subnets. If all your devices reside in the same subnet, then using two EIOC's allows you to have your A and B networks in the same subnet. However, this creates a common failure condition on the network that could take out communications to all devices. I would expect A and B networks are segregated and separate subnets would be possible.

  Andre Dicaire

  • Cancel