VIM 2 and Modbus TCP/IP S-Series Controller

Hi all,

I have a unit that can communicate on Modbus TCP/IP and i have been told that it can connect to a DCS, I just want to confirm that I can use a VIM2 with a Modbus TCP/IP Master Driver to communicate with the unit?

we are at this moment in time taking values from the Modbus TCP/IP and displaying this on a DeltaV system (There will be no control).

I just want to ensure that i am going down the correct path?

...

GaryL

• 26 Mar 2025 12:07 PM
• Cancel

8 Replies

• TPatterson

  

  • 26 Mar 2025 12:51 PM

  Yep you're good. A few suggestions are to make sure you are at the latest VIM firmware version and also place a network switch between your device and the VIM2.

  • Cancel
• Douglas Crowder

  

  • 26 Mar 2025 1:05 PM

  Yes. You could also use a PK controller or an EIOC.

  • Cancel
• Scott Thompson

  

  • 26 Mar 2025 1:48 PM

  In reply to Douglas Crowder:

  Careful with using PK and EIOC as they only support standard Modbus addressing (10,000, 30,000, 40,000) prior to v15.FP3. Modbus extended addressing (100,000, 300,000, 400,000) requires v15.FP3 or later. VIMs support both standard and extended addressing.

  • Cancel
• Douglas Crowder

  

  • 26 Mar 2025 2:30 PM

  In reply to Scott Thompson:

  Interesting. I have never had to use Modbus extended addressing in 30 years. Probably 95% are 40,000 holding registers. There must be some devices out there that require extended.

  • Cancel
• Andre Dicaire

  

  • 26 Mar 2025 3:27 PM

  In reply to Scott Thompson:

  Technically, the Modbus spec does not refer to this as "extended" addressing. The 40,000 register range is a MODICON spec, based on 16bit register size. The full Register address range was always 65,535, but with a 16 Bit register that defined the first digit for data type/location (Holding, Input, Coil or status), the largest value starting with a 4 was 40000. This was pretty much accepted way to define the register range.
  
  By using a larger integer, we can represent the range as 400,000 to 465,535 to access the entire range. This has been used for quite some time, but the DeltaV Serial Card was released back in the late 90's, and used the Modicon mapping. This carried into the EIOC and subsequently the PK ModbusTCP driver. The VIM Modbus Driver recognized this limitation and provides a means to access the full range, but since the VIM emulates DeltaV Serial cards, data from registers above 9,999 must be remapped into by the VIM into compatible ranges with DeltaV.
  
  The v15.3 feature pack finally addresses this. The challenge was in how to preserve existing configurations/devices and support new devices with higher addresses. Looks like the v15.3 solution accomplishes this, allowing the user to set the supported address range of the connected devices.

  Andre Dicaire

  • Cancel
• GaryL

  

  • 28 Mar 2025 2:06 PM

  In reply to Andre Dicaire:

  Andre, from the manual i have found this....
  
  Modbus read and write requests require a 16-bit data address to be referenced.
  The limits of the data address referenced in a Modbus message are from 0 to
  9998 or 0x0000 to 0x270E. The data address range corresponds to either a readonly
  Function 04 Analog Input Registers 30001 to 39999, or the read/write
  Function 03/06 Analog Output Holding Registers 40001 to 49999.
  
  looks like i maybe able just to use a standard S-Series Serial card am i correct, or have i read you message incorrectly?

  • Cancel
• Andre Dicaire

  

  • 28 Mar 2025 4:40 PM

  In reply to GaryL:

  Yes, that would work and aligns with the register range the Serial card uses.  The documentation in BOL for the Serial Card will be in the context of the limited address range or 9999 registers per type.  With the serial card, we have to be concerned with communication settings like Baud rate, Error Bits and such, which must align on both sides, and proper wiring for RS232 or RS485 options.  But as for the register range, as long as the device data is located in the range the serial card can reference, you should be good to go.

  Here is the excerpt from the product data sheet for v15FP2. I'm not sure exactly what "Uses MODICON (PLC) based addressing (MODBUS absolute addressing is not supported".  I think it means we use the range of 1 to 65536, which is an offset of 1 from 0-65535.  In the original range, the limit was 1-9999, which meant 9998 total registers, which mapped to 0-9998.  (0x270E)

  

  You will find multiple sources of information on Modbus device manufacturers, and many will document their products in the 40001 - 49999 range as this was the common implementation.  I'd say the limitations on Modbus Serial communications likely played a role in the feasibility of trying to pass more than 10K addresses of 16-bit registers (20K plus if you passed all Input and Holding registers).  An RTU with multiple devices would need time proportional to the data from all devices on a segment.

  With TCP, the bandwidth increased a 10000-fold from a common 9,6 KB to 100MB.  actually, double that with Full Duplex.  That likely unleashed the use of the full range, especially in PLC's that host much more data than RTU devices.  

  A Plug for the PK.  In v15FP2, the PK controller supports a much-improved mechanism for configuring the multiple Ethernet ports with two changes:

  1- You configure networks that includes a Name, The IP address and subnet and a Gateway address.  Then you assigned the named network to the port or ports of the IOP, and also to the P01 container of the PK.

  2- You can bond a primary RJ45 and secondary RJ45 to a network, such that the PK can be connected to a simplex network using both IOPs, eliminating the IOP as a single point of failure.  Similar to PRP in topology, but without the need for PRP enabled devices.  This is required to support the new ProfNet Media Redundancy Protocol with the new PN1 driver on the PK in v15FP2 and beyond, but it can be used with ModbusTCP or EthernetIP

  Andre Dicaire

  • Cancel
• GaryL

  

  • 30 Mar 2025 5:39 PM

  In reply to Andre Dicaire:

  Thanks Andre, just checking on the cable length as i think this will be the deciding factor between Serial and VIM

  • Cancel