Emerson Exchange 365

Allen Bradley Flex I/O using EIOC V13

Is it possible to drive Ethernet I/P Flex I/O directly using an EIOC in V13 DeltaV?  We have quite a bit of Provox I/O we are needing to convert and the Flex seems like a possible solution.

Thanks!

• EIOC
• Flex
• I/p

s_brwn

• 3 Jul 2019 12:59 PM
• Cancel

3 Replies

• Jean Aley

  

  • 3 Jul 2019 3:04 PM

  Since February 1, 2019 MAS (Machine Automation Solutions, ex GE Intelligent Platforms) is part of Emerson.
  We have in-house solutions now, similar and even better to AB Flex I/O´s through Profibus or Profinet that should be suitable for your applications.
  I see you are based in Washington, so you may get in touch with John Perry at john.w.perry@emerson.com.
  Kind regards,
  Jean Aley

  • Cancel
• Andre Dicaire

  

  • 3 Jul 2019 4:52 PM

  I don't know if the EIOC can connect directly to Flex IO. In a recent project, a data concentrator PLC was used, but that might be due to how their Ethernet IP network was segmented.
  
  How are the Provox I/O currently connected? Are you using the DeltaV Migration controller with Provox IO interface or are they still connected to a Provox controller? Are they distributed and that is why you are looking at Flex IO?
  
  The obvious question is why are you not looking at CHARMS IO. They have flexible mounting solutions that could replace Control IO termination panels mounted in 19 inch Rails, could sit directly in the marshalling cabinet.
  
  The EIOC is primarily an interface node. Not knowing your overall control needs, I can't say if it will meet your needs. Connecting the Ethernet IO directly to the EIOC is only the start. If your control needs are such that the EIOC is not able to execute them, it might not be the right choice. For instance, the EIOC is limited to 26 PID loops.
  
  Do you have many HART enabled devices on your analog control signals? With Flex IO, you will not have access to HART data or be able to use AMS Device manager or the built in HART capabilities of DeltaV.
  
  But more importantly, what about control loop performance and system diagnostics. With a CHARM solution, you have a complete control solution from one Vendor. System integrity is maintained and configuration is all done in one application, with single channel integrity. You have full visibility of the hardware, including field wiring fault detection.
  
  In a third party IO solution, the integrity of the communication is monitored, but individual channel issues are not propagated with each signal.
  
  You may have M series controllers, and in v13, you cannot add CHARMS to these. In v14, you can assign CHARMS to M series controllers. You would be able to keep the same controllers and simply replace the Control IO with CHARMS. (I think you have to replace the migration carrier with standard 2 wide carriers.
  
  If you go with v14, you have an option to use a PK controller rather than an EIOC or your M series controller. The PK is available in 100, 300, 750 and 1500 IO Size. They deliver 4 times the CPU of your MX controller, work directly with M-series IO carriers. They have a built in Ethernet IO port with the same Ethernet/IP drivers as the EIOC in v13. This gives you unlimited use of function blocks and allows you to combine both DeltaV native IO and third party IO. The PK also is capable of 50 and 25 ms module execution, though this faster control works best with new Series 2Plus IO cards.
  
  You could look at other IO solutions via Profibus or Profinet. These require a controller (maybe your existing one, and either Profibus cards or VIM cards(Profinet). Again, the issue is that you lose connectivity to HART smart devices, you add a layer of abstraction between the IO signal and the DeltaV controller, which adds latency. And you don't have end to end diagnostic coverage of the system.
  
  The lower cost of the Flex IO, coupled with reduced DeltaV Licensing might seem attractive. The reliability of this solution is far less than that of CHARMS, with certain failure modes knocking out all IO at that location. Online changes can require interruption of existing IO signals. the ongoing maintenance and complexity in executing changes are real. Lack of diagnostic visibility could extend trouble shooting, and extend downtime.
  
  You may save money with a cheaper solution, but if your production losses are significant per hour, one preventable event washes those a way and decision does not look so good in hind sight.
  
  Good luck

  Andre Dicaire

  • Cancel
• s_brwn

  

  • 3 Jul 2019 8:49 PM

  In reply to Andre Dicaire:

  Thanks for the info. It is very helpful. We currently have a Sx controller with the provox migration carrier driving the Provox I/O files. All of the control is currently taking place in the DeltaV controller. We currently have an EIOC as a data concentrator to an existing PLC performing other tasks/equipment. We are considering Charms but the I/O count and density makes it quite a bit more expensive. We have about 1000 points divided amongst AI, AO, DI, and DO. We don't share points between controllers and all our I/O is in the same room. We are also considering traditional S series I/O through some fan out boards to keep the carrier length at a min. The HART data was a question.. I see HART capable Flex modules are available but it makes sense that the HART data would be stripped as it goes through the EIOC. We do have AMS so that would also be effected. I liked the 16 point AC modules offered in Flex as well as the form factor. It aligns well with our existing Provox term panels. Thanks again for the info. Seems like the Flex could have it's place but not where we need it for this project.

  • Cancel