Emerson Exchange 365

• 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

• EIOC
• register offset
• EIOC migration

Clarence Cuerdo

• 4 Mar 2022 4:00 AM
• Cancel

8 Replies

• Matt Forbis

  

  • 7 Mar 2022 3:22 PM

  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.

  • Cancel
• Andre Dicaire

  

  • 7 Mar 2022 4:31 PM

  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

  • Cancel
• Clarence Cuerdo

  

  • 10 Mar 2022 2:39 AM

  In reply to Andre Dicaire:

  Hello Andre Dicaire and Matt Forbis, 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.

  • Cancel
• KeithStThomas

  

  • 6 Apr 2022 10:18 PM

  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

  • Cancel
• StephenCowhey

  

  • 6 Apr 2022 11:01 PM

  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.

  • Cancel
• Chaitanya Adkar

  

  • 15 May 2023 10:50 AM

  In reply to KeithStThomas:

  KeithStThomas Andre Dicaire Matt Forbis
  
  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.

  • Cancel
• Matt Forbis

  

  • 15 May 2023 2:12 PM

  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. Juan Carlos Bravo is the marketing manager for Data Integration.

  • Cancel
• Andre Dicaire

  

  • 15 May 2023 4:30 PM

  In reply to Matt Forbis:

  I would suggest providing feedback to the Product Manager.

  Andre Dicaire

  • Cancel