Emerson Exchange 365

Best Practices integrating Modbus TCP/IP or EtherNet/IP

Hello All,

Trying to learn Delta V and integration, your insight would be greatly appreciated.

What are some of the best practices when integrating a Modbus TCP/IP or EtherNet/IP networks with a large device count (i.e. 120 devices) into the DeltaV systems?

From what I've seen, most experts here are utilizing the VIM2 to tie the networks together. That being said, I believe the VIM2 only supports 32 devices and/or 128 Datasets.

So does that mean I would have to add (4) 2-wide carrier containing the power supplies and VIM2 to the left of the controller to be able to support that device count or am I missing something?

If the above assumption is correct, adding these VIMs on a new build is fine, but what about existing panels, they normally don't have this extra space. How is this over come? 

Thank again

Gsr13k

• 22 Jun 2018 4:31 PM
• Cancel

14 Replies

• DBacker

  

  • 22 Jun 2018 5:44 PM

  Have you looked into using an EIOC instead of a VIM? Books Online states that EIOCs can support 256 physical devices and up to 256 logical devices per physical device. EIOCs have a limit of 2000 DSTs. Connecting over 100 devices to a single controller seems like a lot to me. You should also spend some more time learning the differences between Modbus/TCP and Ethernet/IP class 1 and Ethernet/IP Class3 before you make any decisions.

  • Cancel
• Michael Krispin

  

  • 23 Jun 2018 8:30 AM

  Depending on the amount of data per each device you also might consider the cheaper standard serial card and use Modbus in multidrop with RS485, means several devices connected to one port on a serial bus. I have done many projects with this constellation and 3rd Party Remote IO.
  For In/Out communication to each device you can handle max 8 devices per port , 16 per card (2ports). Each dataset can handle 128 analogue signals, digital as packed word even more.
  As DBacker mentioned you should take care not to connect too much devices in one controller only with Vim or Serial Card.
  You need to process also these signals in your control modules. Don't make one controller as Signal input and supply over the controller network. Better divide your signals into sense full areas over several controller.
  Anyway, Modbus is the cheapest way from the view of DST count ( => Base count, Batch, foundation support etc count all on DST License!) to bring your signals in DeltaV . VIM connect via a TCP/IP wiring, Standard Serial card connect via 2 wire Serial cable, same as Profibus. The signal exchange even with 38kBaud is fast enough to update more than 1 times per seconds or data over Modbus of a full 16DST/128Word per port. If you don't use the full 128 signals/DST even faster. Since a DCS is not as fast as a PLC, everything is managed also in at least typically 1 second tasks. So it should be good enough.
  
  Best Regards, Michael

  • Cancel
• Gsr13k

  

  • 25 Jun 2018 4:32 AM

  In reply to DBacker:

  DBacker,
  
  Thanks for your insight! I did not know that the EIOC could communicate to both M and Series controller. This is exactly what I was looking for. In reference to the classes, the device controls and critical status monitoring will be cyclic data and others will be acyclic to mitigate the overhead or less deterministic. 100+ device may seem a lot, but in the PLC world I'm use to having the ability of of adding up to 256 network connections. Guess I will have to more cautious in the Delta V side.
  
  Thanks again.

  • Cancel
• Gsr13k

  

  • 25 Jun 2018 4:42 AM

  In reply to Michael Krispin:

  Michael,
  
  Thanks for your insight as well! No go on the Modbus RTU, as any new equipment will be specified will have Industrial Ethernet as the protocol. So as DBacker mentioned, the EIOC will likely be the route I take to integrate in the existing system. Great info nevertheless! That being said, I forgot to ask, but what is the recommended device count for a single controller to handle, assuming I'll be moving 20 bytes in and out per device?
  
  Thanks again.

  • Cancel
• István Orbán

  

  • 25 Jun 2018 7:38 AM

  In reply to Michael Krispin:

  Michael, starting with v12, batch licensing is no longer DST-based, but unit-based.

  • Cancel
• István Orbán

  

  • 25 Jun 2018 7:42 AM

  You can have up to 2 VIM2 cards per controller, 4 is not supported. www2.emersonprocess.com/.../DV_COL_PDS_S-series_VIM2.pdf

  • Cancel
• Gsr13k

  

  • 25 Jun 2018 12:53 PM

  In reply to István Orbán:

  Thanks for the update.

  • Cancel
• Michael Krispin

  

  • 25 Jun 2018 2:50 PM

  In reply to István Orbán:

  Thanks Istvan,
  I don't know that with the Batch license. I know only that this is a crap from the beginning of DeltaV with the always changing license models in every version.
  So I have to pay now for every Unit module which is part of the batch? It would be good to have a calculation sheet where I can play a bit which design would be better for the project.
  Best Regards, Michael

  • Cancel
• Michael Krispin

  

  • 25 Jun 2018 3:08 PM

  In reply to Gsr13k:

  Hi Gsr13K ,
  The device count depend on what you want to do with that 20 bytes per device. I guess you will have some analogue signals, digital in and out for some control. Let say a variable speed drive with 1 AO, 2 or 3 AI , One Status word for digital signals and one control word for the command output.
  What else are the up to 20 bytes/10words?
  For that basic control modules I guess some between 100 and 200 devices if that is the only IO you need to connect. Then some additional sequences or PID control etc. Such status signals don't must have an individual DI control module which would produce unnecessarily more load on the CPU as a dedicated special control module . Such signals are mostly all in one control module for the whole device. No idea what your device is, but with so many I would develop in every case a new dedicated typical instead to split each signal in the standard (PCSD?) Library modules. Want you tell us a bit more about? Then the guys here can support better.
  Best Regards,
  Michael

  • Cancel
• Michael Moody

  

  • 25 Jun 2018 3:40 PM

  In reply to Michael Krispin:

  Michael, I've used DeltaV since v6.3. Except for some specific add-ons, the primary license changes I've seen are related to Bus connections and Batch. For Batch, I'm neutral on the change. I makes it easier as we add instruments (DSTs) to an existing unit much more often than adding new units to the batch system. For the changes to devices connected via a bus technology (i.e. VFDs), most see as very positive as it basically was greatly reducing the complexity related to bus signals and reducing the costs associated. They also streamlined the concern around counting a single DST more than once.
  
  So, while Emerson's license model is always a topic of discussion, I think most of the changes since my involvement were for the best. Also, I haven't noticed changes every version, only one major change in about 6 versions.

  • Cancel
• Gsr13k

  

  • 25 Jun 2018 7:43 PM

  In reply to Michael Krispin:

  Michael,
  
  Great info for a Delta V novice like myself to know. I'm learning and all of the members that are providing info is very useful.
  
  Most of the field devices are drives and motor starters and yes most only requires a single control word and status word. But newer technologies such advanced motor starts (E300 or C445) and others devices that are parts of MCC and sub station such as power meters and IEDs, has a lot of data that needs to be fed back into the Delta V system. This may include but are not limited to current, voltage, thermal capacity, etc will all take up a full word, that why I mentioned the conservative number of 20 bytes (can probably grow upward to 20 words). Typically they will not require and PID loops or anything fancy, just basic controls and monitoring of a lot of data.
  
  Normally, I would take all of the VFDs and starters and integrate into a PLC such as AB ControlLogix Processor for the controls and pass the data through some sort of OPC server to the SCADA/DCS. To reduce cost and me wanting to learn more about Delta V, I want to do away with any middle man and integrate directly with the EIOC. Now, at least I have something to gauge off of per your response. Do please provide any additional info or gotcha that will assist in helping me make a good decision when specifying the hardware.
  
  Thanks again!

  • Cancel
• Michael Krispin

  

  • 26 Jun 2018 2:31 PM

  In reply to Michael Moody:

  Hi Michael, I'm in from Version 2. I agree that in the past where less major changes which I know, but much more in the beginning and you are right - most becomes more easy. Changes occur so far I remember more ore less in every new Version. I don't forget how our sales guys send greeting to the hell to figure out that all in bigger projects. On the other side, if you handle small systems then for example the full OI license now is much more expensive as if you have only for example 500 dst at all. I was lucky during my Emerson time to go to our sales and let them do, but I remember that often enough some function on side suddenly pop up and - surprise - required additional licenses. Sure , during a project with the SI dongle you don't mind. The double dst count, if you refer from two or more modules to the same IO-register was good and fair to cancel. I have not all in mind anymore since I'm now more than 5 years out from Emerson and not so deep in touch with that all. I now work as freelance only in ready projects and be happy with that. But I still looking for alternatives if someone ask me for automation. Especially the Plantweb System is good for low budget DCS up to 250 DST. Here you can really save money with Modbus remote IO. I'm not sure it is available anymore. I know that especially in Asia where a big market for small systems to change manual operated systems into at least simple automation. My last company had several such rubber plants or other simple process plants. But this is all another story

  • Cancel
• Michael Krispin

  

  • 26 Jun 2018 2:45 PM

  In reply to Gsr13k:

  Hi Gsr13k, (could you please offer at least your own name thx)
  If I understand your requirements well, than you don't have a lot or no automation with sequences etc. If you count one device as a Motor than from the load perspective I don't see a bigger issue to put that all in one SX controller. Even if some signals will be used just as an AI module
  There is the new PK Controller soon, which might even good enough for your purpose as a complete stand alone system.
  But it is not yet really on the market. Contact your Emerson sales guys.
  Emerson provide a PCSD Library with ready control modules, faceplates, Dynamos for your operator interface and documentation . If they do the engineering of this project, they will use it anyway. If you going to do yourself then I think you would need some support from experienced Guys at least for your basic configuration including Library etc.
  Best Regards
  Michael

  • Cancel
• Gsr13k

  

  • 1 Jul 2018 8:16 PM

  In reply to Michael Krispin:

  Michael,
  
  Thanks for the additional information on the loads, controller, and available library/face-plates. Those will definitely make it easier. Whether Emerson or a contractor does the project, I'd like to be in the loop of it all. Everything is still at a pre-planning stage so I'll have time to further research, albeit the insight from you have been invaluable. I contact my Emerson rep and will proceed as advised.
  
  Thanks again
  
  Sith

  • Cancel