• State Not Answered
  • Replies 14 replies
  • Subscribers 5472 subscribers
  • Views 28975 views
  • Users 0 members are here
Recent DeltaV Community Connect Discussions
Similar Posts
Charm RTD Offsets
Persistent offset in CAS master?
OUTPUT offset between DCS and PLC
AI HART CHARM MA offset reading for 4 wire transmitter output.
DCS Analog Input Charms Always giving an offset value of 2% with no Diagnostics Error
Share
  • Not Answered

EIOC Limitation on offsets

Good day everyone.

I am currently doing a proof testing on migrating from Serial to EIOC. I had one test where I needed to configure a Device tag, which is an input register, that needs to read register address 001. When configuring device tags from the EIOC (in DeltaV Explorer), it automatically puts the offsets based on the register type (in this case, it automatically makes it 30001 instead of accessing 001). Is there a way to overcome this? I am aware that for Serial cards, we have an option to upgrade its firmware to Programmable serial to be able to do this. Is there a similar solution that can be applied to EIOC?

Hoping for any response and thanks in advance.

Best regards,
Clarence

Clarence Cuerdo

14 Replies

  • Matt Forbis
    Hi Clarence,

    I'm not sure I understand the issue. There are some limitations within the registers that are able to be accessed with a EIOC, however it's always on register number >= 10000 that I'm aware of. In normal modbus communications, When you break down what the 30001 means (also sometimes denoted as 300001), it's really two components rolled up into a single representation. There is the register number / offset (which is either 0 or 1 depending how you think of it) and then there is the request type (3). The 3 corresponds to the modbus function code and refers to reading an input register. In the programmable serial card, these are just broken into two different fields, it's not that it's actually referring to a different register, but just a different way of representing the data. It's possible you have a very strange device and it doesn't follow normal conventions, but seems unlikely. If you have a link to the manual of the device you are talking to, please feel free to share and I can take a look and do some analysis on it.
  • Andre Dicaire
    Matt is correct in that the normal practice for Modbus register references is the leading integer number denote the register type requested, so 30001 is a call to the first Input Register, 40001 is the first holding register.

    It has become convention to incorporate the register type as part of the register reference. This initially was seen as 3000 and 4000 ranges (999 registers of each type). As PLC's become more capable with larger data sets, the convention moved to 30,000 and 40,000 ranges. ( max of 9,999 registers of each type). In actuality, the Modbus standard supports 65,535 registers of each type. So the valid range of Holding registers is actually 400,001 to 465,535.

    When the EIOC was created, the configuration dialog mirrored that of the Serial Card and kept the convention of 40,000 range, which is neatly represented in a 16 bit unsigned integer. To keep the first digit a 4, the range is limited to 40,001 to 49,999. In a different interface, you might be called to define the Register type and the index in two separate fields, with the index from 1 to 65,535. In this case, the resulting reference would be in the 400,000 range. But 400,001 and 40,001 refer to the same register.

    If you have a device with mapped registers above the 9,999 limit (i.e.>409,999), the VIM2 Modbus TCP driver will support this. However, these addresses will be mapped down into the supported range of the Serial Card data set. If you can remap these registers in the host device to be below 49,999, then you can use the EIOC to access them.

    Andre Dicaire

  • Clarence Cuerdo

    In reply to Andre Dicaire:

    Hello and , thanks for the prompt response. I understand that theoretically it should work that way. When we were doing the testing at site, the actual device's location was far so I was not able to see it personally. I just got an information yesterday that the device we were connecting to is Micro PI BF-424 (RS 485) through a Moxa MB3270 TCP/RTU gateway. I was trying to search for the device but is having no luck finding any manual (a bit hard to find). As per customer, the gateway was configured for pass through. When we were trying it in EIOC, I remembered when I checked it in DeltaV diagnostics, it was saying comms were good but not reading the register's value. I did not see the actual log but my customer mentioned that it DeltaV is requesting a full 30001 as a representation of the request to read 001. I'm not sure if I have stated it clearly.
  • KeithStThomas

    In reply to Andre Dicaire:

    Andre,

    Is there any plan to expand the register data map of the EIOC? We are upgrading our old DCS to DeltaV, but have hit a roadblock with the limitation of the EIOC holding registers. Our ancient DCS could access holding registers beyond 9,999 (49,999) e.g. 17,001 (417,001), but am disappointed this new EIOC cannot. We cannot remap the PLC data down to the lower registers, and planned on using the EIOC as a Modbus/TCP hub for several PLCs, but found out we now need to purchase a 3rd party device to act as liaison between the PLC and EIOC that handles remapping the data.

    Keith
  • StephenCowhey

    In reply to KeithStThomas:

    Thanks for highlighting this issue Keith. It has always befuddled me that I can download any number of free ModbusTCP programs, or buy cheap PLC like devices, that can handle a full range of Modbus registers but a system as powerful as DeltaV can't deal with it. Between that, and the incredibly punitive handling of DST licenses in Modbus interfaces, it presents a real barrier to have the DeltaV take a proper data aggregator role. It would have been great to see the serial "driver" fully redone for the PK/EIOC so that we can have huge pipes of data coming in.
  • Chaitanya Adkar

    In reply to KeithStThomas:



    Any updates or timeline on if Emerson is planning to include extended addressing in future updates? We are also facing same issue and have to use a 3rd party device to act as a liaison.
  • Matt Forbis

    In reply to Chaitanya Adkar:

    I know there has been discussions, but that is out of my primary job function, so I can't really comment. As an Emerson product user, there are really two ways to provide feedback for new features like this. First, you can submit the idea to udep (userideas-emerson.com/). This is moderated and voted on by fellow users and a great way to submit ideas. The second option is the Marketing managers provide direction and input into new features. is the marketing manager for Data Integration.
  • Andre Dicaire

    In reply to Matt Forbis:

    I would suggest providing feedback to the Product Manager.

    Andre Dicaire

  • chrishoffpauir

    In reply to Andre Dicaire:

    Andre, We have a client hitting this situation again with a Fire Alarm Control Panel today (6 digit Modubs Holding registers), any update to EIOC firmware to support > 65,535 (FFFF) yet?
    Just checking.
    p.s. Thanks for your contributions to this forum.
    CHris
  • Andre Dicaire

    In reply to chrishoffpauir:

    Emerson announced that this is resolved in v15FP1 ( Im on FP2)

    This is not something that will be rolled back into v14LTS, as far as I know

    Andre Dicaire

  • Shannon Jistel

    In reply to Andre Dicaire:

    Looks like v15.FP2 should support the full range now.

  • Colin Swaney

    In reply to Shannon Jistel:

    Just to clarify, if I have a Modbus server that uses 6-digit addressing (400001 - 465535), will a pre-v15.FP2 EIOC be able to read registers 400001 through 409999 from that device?
    Thanks

  • KeithStThomas

    In reply to Colin Swaney:

    Yes, use 40001 - 49999.
  • Colin Swaney

    In reply to KeithStThomas:

    Thanks for the confirmation.

This is the official online community site of the Emerson Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2026 Emerson Exchange. All rights reserved.