Nk18000016 - Iod4111 Modbus Tcpip Vim2 Release Notes

Knowledge Base Articles
IOD-4111 Modbus TCP/IP VIM2 Release Notes
Article ID: NK-1800-0016

Publish Date: 05 Oct 2021
Article Status: Approved
Article Type: Product Revision/Release
Required Action: As Needed
Recent Article Revision History:

Revision/Publish Description of Revision
05 Oct 2021 Linked to compatibility KBA
(See end of article for a complete revision history listing.)
Affected Products:
Product Line Category Device Version
DeltaV Controller & I/O Hardware IOD-4111 Modbus TCP/IP Driver for DeltaV All
VIM2
1 Introduction
This Knowledge Base Article, NK-1800-0016, contains release information for Modbus TCP/IP VIM2 firmware.
2 Compatibility
For compatibility information, please see KBA NK-2100-0297: Virtual I/O Module Hardware and Software Compatibility.
3 Installation instructions
3.1 Supplemental download links
Simulation VIM2 firmware:
https://gsuds.emerson.com/pickup/psg/pscoe/Simulation-Vim2-v262.hex: (Size: 1229 KB)
Checksum: 4BC92E98D1F54C5DC63993684357ED809D0EA259C0D52E3382D528449D45D0FF
3.2 Pre-upgrade considerations

• Upgrading the VIM2 firmware will terminate communications with all field devices. Make sure the plant process is
in a safe state.
• Upgrading a simplex VIM2 installation connected to a redundant DeltaV controller may cause a controller
switchover.
3.3 Post-upgrade considerations

• Changing the firmware type (e.g. Simulation to Modbus TCP/IP) will require a configuration upload once the
firmware is upgraded.
• In a Redundant VIM2 installation, wait for the newly upgraded VIM2 to indicate a good status (solid network light,
no errors in DeltaV Diagnostics) before performing a redundancy switchover.
3.4 Installing the firmware on existing installations

To install the firmware on existing installations, follow these steps:
1. Open VIMNet Explorer.
2. Right-click the IO VIM2 placeholder, and then click Properties.
3. Click Flash Upgrade.
4. Click Simulation VIM2 firmware v2.6.2, and then click OK.
Wait for the flash-upgrade to complete.
5. The VIM2 is now flashed with the latest Simulation firmware.
6. Continue to the Flash procedure.
Page 2 of 16
3.5 Flash procedure
1. Open VIMNet Explorer.
2. Right-click Simulation Net, and then click New Simulation VIM.
3. Type a name, valid IP Address and subnet mask for the placeholder, and then click OK.
4. Right-click the Simulation VIM2 placeholder, and then click Commission.
5. From the decommissioned VIMs list, click VIM2, and then click OK.
6. Right-click the Simulation VIM2 placeholder, and then click Properties.
7. Click Flash Upgrade.
8. Browse to and select the firmware file included in this kit.
Wait for the flash-upgrade to complete.
9. The VIM2 is now flashed with the latest firmware.
4 Changes in v4.6.5
Modbus TCP/IP VIM2 v4.6.5
https://gsuds.emerson.com/pickup/psg/pscoe/ModbusTCP-Vim2-v465.hex: (Size: 1716 KB)
Checksum: A623CC9DE693DA520747F86A08377996169DFE347513D98C6A61BAFC46856147
4.1 Enhancements
Issue
Description Reference KBA
Number
Not
No enhancements in this version. Not applicable
applicable
4.2 Resolved Issues

Issue
Number
NK-2000-0363:
The VIM2 may become stuck during the boot up process after commissioning, PRODUCT QUALITY
decommissioning, or flash upgrade. When stuck, DeltaV Diagnostics will show a CONCERN: Process
“not communicating” status for all cards emulated by the VIM2. Affected VIM2 Systems and Solutions
DD-888
have the part number or hardware revision listed in the referenced KBA. The -- DeltaV - Unexpected
VIM2 boot procedure has been modified to account for the hardware changes. Behaviors Affecting
This allows the boot process to finish normally. Virtual IO Modules
(VIM2)
The VIM2 may disconnect from a Modbus TCP/IP master sooner than expected
when Special Data 5 of a slave dataset is configured to use an idle timer less
than 3 seconds. The documentation indicates that the VIM2 has a minimum idle
timer of 3 seconds. This minimum was not enforced. Configuring a small idle
DR-729 timer may cause the VIM2 to unexpectedly close connections and potentially Not applicable
affect IO value update frequency.
The slave connection idle timer has been modified to behave according to the
documentation. The minimum of 3 seconds is now enforced.
Page 3 of 16
5 Changes in v4.6.4
Checksum: 6D675136913DCC35F215A0AA0D7764C21A1E72515AC29CF1B2C5BE01DA0AF206
5.1 Enhancements
Issue
Number
The dataset status string in DeltaV Diagnostics for Modbus exception code 0x0B
DR-310 has been changed. The previous string was “Error Response – Target device not Not applicable
responding”. The new string is “Gateway Target device not responding”.
The redundancy standby ping timeout for “RTU via TCP” and “RTU via UDP”
DD-867 messaging modes has been changed. Prior to v4.6.4, it was fixed at 2 seconds. Not applicable
The redundancy standby ping now uses the port-level timeout configuration.
5.2 Resolved issues

Issue
Number
For output only datasets on a redundant VIM2 pair communicating with a
redundant field device that uses the active/standby pattern, the VIM2 may lose
output write events. In order to lose an output event, the following must be true:
• Output-only dataset direction (with readback disabled)
• Redundant field device
• Primary IP of the field device is not responding to Modbus TCP/IP
requests, but will allow TCP sessions to be opened NK-1900-1128: VIM2
• A register in an output dataset is changed Modbus TCP
Firmware(IOD-4111)
• Connection routine to the Primary IP has just completed and has not
DR-709 v4.6.3 or Earlier May
been tested with a Modbus TCP/IP request
Lose Writes in
In this scenario, the write request will be sent using to the Primary IP of the field Redundant
device. Since the field device is not responding on its Primary IP, the write will Applications
time out. The VIM2 then takes a fault recovery action (switch to the Secondary IP
of the field device) and resumes normal operation. The original write is not
resent.
The pending output event system has been changed to only mark outputs
completed that have received a successful acknowledgement from the field
device. Previous versions would mark an output completed once the write
request is transmitted (not waiting for the response).
Under heavy data change load, the VIM2 would display inconsistent values for
“Generation Rate” and “Poll Rate” in VIMNet Diagnostics. The poll rate would
DR-440 appear to be twice as fast as the generation rate. Not applicable
The poll rate calculation has been changed to display the correct value,
regardless of VIM2 load.
Page 4 of 16
Under heavy data change load, the VIM2 would not send some input change
events to the DeltaV controller. This results in stale input data in the datasets. For
this to occur the following must be true:
• The “Number of Buffers” parameter in VIMNet Diagnostics must
consistently be 287 or fewer
• An input dataset with infrequently changing values must be configured on
a serial card (for example, discrete feedback)
DD-449 Not applicable
• One or more input dataset with frequently changing values must be
configured on the same serial card (for example, analog sensors)
Previous versions will discard input change events when the input change queue
is full, unless periodic input/output rate (Special Data 4) is used with a non-zero
update period. The VIM2 will now use the periodic reporting system as a fallback
when the input change queue is full. This will prevent stale data in the dataset of
the DeltaV controller.
Page 5 of 16
6 Changes in v4.6.3
Checksum: 6CD16BDD96DAA07D36D210DB9CB0D434E1F5AB1E0F999D8F9FD501F99D923527
6.1 Enhancements
Issue
Number
Not
applicable
6.2 Resolved issues

Issue
Number
For output datasets using single value output mode (output mode = 1), output
write failures will cause the entire dataset to be written to the field.
Below are some of the ways this issue can be observed:
• Unintended behavior of the field device.
• Momentary alarms based on the MERROR parameter.
• Output dataset registers with an unexpected status.
The following sequence of events must occur for this issue to be encountered:
1. An output value is changed
2. The field device rejects the value with a Modbus exception code
3. The VIM2 sets the overall integrity of the dataset to bad (marking all
registers bad)
DR-708 4. On the next scan of the control modules, all bad output values are Not applicable
rewritten to the field device.
5. If the last write succeeds, the overall dataset integrity is set good and all
registers are marked good, ending the sequence of events
6. If the last write fails, the overall dataset integrity is set to bad and all
registers are marked bad. The sequence of events loops back to Step 4.
The status handling for single value output mode datasets has been changed to
prevent setting the dataset overall integrity bad when one write request has
failed. A given output write request will only affect the status of the associated
register, it no longer modifies the dataset overall integrity. This interrupts the
above sequence of events at Step 3, preventing the control module from writing
registers that have not changed value or status. Failed write requests will still
cause a resend of that write request each time the control module executes.
Page 6 of 16
6.3 Known issues
Issue
Number
NK-1900-1128: VIM2
Modbus TCP
For output only datasets on a redundant VIM2 pair communicating with a Firmware(IOD-4111)
DR-709 redundant field device that uses the active/standby pattern, the VIM2 may lose v4.6.3 or Earlier May
output write events in certain circumstances. Lose Writes in
Redundant
Applications
Page 7 of 16
7 Changes in v4.6.2
Checksum: D9C45D5F131C812014894616C0462555BFD8AFD77A926519B4AF51991A739439
7.1 Enhancements
Issue
Number
Modified the TCP connection close procedure to prevent a TCP FIN from being
sent. The VIM2 instead uses the TCP RST flag to terminate a connection. Using
the TCP RST flag alone reflects the state of the connection in the VIM2, indicating
that it will not accept further responses on this TCP connection.
DR-700 While the previous VIM2 behavior was within the TCP specification, it triggered Not applicable
undesired behavior on other field devices. One field device known to exhibit
undesired behavior is the FloBoss S600+ (kernel 2.6.20 Mar 7 2013, kernel 2.6.20
Aug 31 2016). In certain circumstances, the VIM2 would send a TCP FIN shortly
followed by a TCP RST. This combination caused the S600+ to stop responding
to future Modbus requests.
Added support for Modbus Unit ID 0 and 255 to server mode.
The VIM2 in server mode emulates a gateway to serial devices, each having the
Modbus Unit ID that corresponds to the selected Device Address in the DeltaV
DR-704 Explorer configuration. To accommodate Modbus TCP/IP clients that do not Not applicable
support Modbus gateways, the VIM2 will now redirect requests using Unit ID 0
and 255 to the datasets of Unit ID 1. All datasets on slave ports with device
address 1 will be accessible with Unit ID 0, 1, and 255 from Modbus TCP/IP
masters. All other device addresses are accessible with the matching Unit ID only.
7.2 Resolved issues

Issue
Number
After the VIM2 enters and exits failsafe mode a number of times, it will be unable
to open new connections to the field device. A power cycle of the VIM2 is required
to recover from this issue. The exact number of times failsafe mode must be
entered and exited in order to trigger this issue depends on the configuration
loaded into the VIM2. Datasets affect by this issue could display any of the
following statuses in DeltaV Diagnostics:
DD-821 • “Possible loss of IP …” Not applicable
• “Network Error-20-0x5020 The connection is broken”
• “Network Error - 48 - 0x0”
A timing issue prevented resources from being released correctly upon entering
failsafe mode. The VIM2 has been modified such that the resources are always
released upon entering failsafe mode, regardless of timing.
Page 8 of 16
Datasets using “RTU via UDP” messaging mode will alternate between good and
bad status while the field device is not reachable on the network. Restoring the
network connection to the field device recovers from this issue. This is observable
in DeltaV Diagnostics and in the Event History. Depending on configuration, the
Event History will show “IO failure” or “input/output transfer failure” occurring and
clearing while the field device is offline.
When a field device is not reachable on the network, the VIM is expected to set
the datasets to a bad status. This bad status should remain until the field device
returns to the network. The previous VIM2 firmware version will set the datasets to
a good status while waiting for responses to “RTU via UDP” messages. When
these messages fail, the VIM2 sets the datasets to a bad status.
This change prevents the datasets status from being set to good while waiting for
“RTU via UDP” responses. The datasets are set good only once a proper
response is received. If configured, the Event History should have one event for
the first time the dataset transitions from good to bad, and one event for
transitioning from bad to good once the field device is restored.
After a redundancy switchover, an output with readback dataset may have
registers with incorrect values. To trigger this issue, the register must have been
written by the controller just before the VIM2 switchover occurred. The dataset
register value matches the desired value from the control module, but the desired
value was not written to the field device. Upon readback, the affected register is
not updated to reflect the actual value in the field device. Writing a new value to
DD-830 any register in the dataset will return the affected register to normal operation. Not applicable
The VIM2 has a data structure used to determine when output registers must be
written to the field device. In the previous firmware version, this output pending
structure is set to an inconsistent state if an output is pending when a redundancy
switchover occurs. This firmware version keeps the output pending structure
consistent across VIM redundancy switchovers, preventing incorrect register
values.
When using Modbus server mode, floating point and 32-bit integer datasets use a
different byte order for reading values compared to writing values. A Modbus client
that uses these data types would notice inconsistent values if it reads from register
addresses it had written in the past.
DD-842 Floating point and 32-bit integer datasets require the use of two 16-bit Modbus Not applicable
registers to hold the value. Reading back a 32-bit value immediately after writing
results in the two 16-bit portions being swapped.
The 16-bit word order for the read and write side have been aligned. The order
matches the default word order of the VIM2 in master mode.
Page 9 of 16
8 Changes in v4.6.1
Checksum: 927839DCCA25BA621684446E376F5761D5C6A622EB1A8E87131801B5336BFED0
8.1 Enhancements
Issue
Number
Not
applicable
8.2 Resolved issues

Issue
Number
When recovering the settings from a commissioned VIM, the default gateway IP
address is not restored. After completing the recovery process, the recovered VIM NK-1900-0586:
placeholder in VIMNet Explorer would contain 0.0.0.0 in the default gateway field of Recovering a VIM
DR-669 the VIM properties dialog. Configuration Does
Not Restore the
Recovering a VIM2 with this hotfix applied will result in the default gateway IP Gateway IP Address
address of the VIM2 appearing in the new VIM placeholder in VIMNet Explorer.
A VIM2 using Modbus datasets under a slave port stops responding to Modbus
requests after some time. A reboot of the VIM2 is required to resume transferring
Modbus data.
A problem external to the VIM2 must first occur before this issue can be triggered.
The external issue must cause the VIM to be unable to send Modbus responses but
not close the TCP session. Potential external problems could be with the Modbus
master, the network, or a firewall. Once triggered, the VIM2 will remain in this issue
until reboot, even if the external problem is resolved.
For example, network trace analysis shows that the VIM2 stops responding to
Modbus requests shortly after the TCP receive window of the Modbus master
reaches zero. A TCP receive window size of zero indicates that the Modbus master
cannot receive responses. This would prevent the VIM2 from sending a response.
The Modbus master not allowing responses is an external problem that triggered
DR-601 this internal issue in the VIM2. Not applicable
Previous versions of the VIM2 would not time out when it is unable to send
responses. By not timing out, the VIM2 was unable to handle new Modbus
requests. This hotfix changes the VIM2 slave behavior so that it will time out when it
is unable to send responses. Timing out frees the VIM2 to respond to new Modbus
requests without requiring a reboot. The send timeout period is equal to the slave
disconnect delay time (dataset special data 5).
Note: This change does not fix the external problem that causes the
VIM to be unable to send Modbus responses. The cause of that
problem is outside the VIM2; in the network, a firewall, or the Modbus
master itself. This change allows the VIM to recover from the external
problem without requiring a reboot.
Page 10 of 16
9 Changes in v4.6.0
Checksum: 8A705457616E619BFDC2930F2651E548936BA19F6E029BEE5063CFED962228D1
9.1 Enhancements
Issue
Number
Modified receive handling to discard messages with unexpected Transaction IDs and
DD-574, instead, continue waiting for a response (with expected Transaction ID) or timeout.
Not applicable
DR-585 Previously, the VIM discarded responses with invalid Transaction IDs and timed out
immediately.
Modified scan mechanism of devices behind a serial bridge such that if one device is
offline, scan of other online devices is minimally impacted. An offline device enters slow
scan mode after a failure.
In slow scan mode, only the first input or output with readback dataset is scanned. With
each scan failure, a fail count is incremented to a maximum of 6. The slow scan is
executed at 10 seconds multiplied by the fail count.
Added new functionality to handle redundant devices which are operationally
Active/Standby. This flag marks the device as Active/Standby.
DD-492 When this flag is set, the standby VIM will report good status if either field device IP Not applicable
address responds to pings. Only when both field device IP addresses fail to respond
will the standby VIM report bad status to DeltaV Diagnostics.
For redundant VIM, the switchover status handling for devices using the “One
connection only” flag and not using ICMP ping has been modified.
Previously, the standby VIM would always set the switchover status to good for this
device. If the field device was offline, this would potentially cause the VIM to continually
perform redundancy switchovers.
Now, the standby VIM will keep the switchover status as bad for the device until the
active VIM changes its status to good. If the field device is offline, the VIM will only
switchover once.
Page 11 of 16
9.2 Resolved issues
Issue
Number
Dataset status toggles between good and bad when the field device state remains
unchanged. This issue occurs when the VIM can connect to the field device IP
address but does not receive Modbus responses. This can occur when a TCP
connection succeeds to a device’s IP address, but the underlying Modbus
application is not available.
Previous versions of the firmware set the dataset status good when a TCP
connection succeeds. With the device behavior described above, the VIM will
alternate between setting the dataset status to good when the VIM’s TCP
connection attempt succeeds and setting the dataset status to bad when the VIM’s
Modbus request times out.
This behavior can cause one or more of the following symptoms
• If a device behaves as described above AND is the only device for a given
Serial Card Port, the bad status on the datasets may trigger Controller
MAINT alarms. The alarm will toggle between active and inactive, filling the
controller event history.
• DD-496: The active VIM incorrectly reports good dataset status, while the
standby VIM correctly indicates ping failure.
• DR-529: The VIM has multiple redundancy switchovers and standby partner
DD-496, failure events in the historian when there are several configured but not
DR-529, present field devices. One of the offline devices must be a bridge or Not applicable
DR-574 gateway.
• DR-574: In a redundant VIM, when communications to a redundant field
device's primary IP are good (good TCP connection, good Modbus
responses), but the standby IP is bad (good TCP connection, timeout on
MB request), the status of output only datasets toggle between good and
bad in DeltaV Diagnostics.
The active VIM now requires a good Modbus response be received for a good
status to be set on the dataset. This change has the following effects on the
symptoms listed above
• Datasets will remain bad until a good response is received, eliminating
toggling MAINT alarms in the controller event history.
• DD-496: The active and standby VIM both report the correct dataset status.
Datasets are marked good when a Modbus response is received from the
field device.
• DR-529: The active and standby roles of the VIM will be constant if there
are no Modbus responses from a bridge or gateway field device.
• DR-574: The status of output only datasets are bad until the first Modbus
response is received for any of the input datasets on the field device. After
the first response, the output only datasets are marked good.
The VIM reports good dataset status, but the register values are not updating.
Network trace indicates that the last portion of a Modbus response is lost (i.e. a
partial response of more than 6 bytes but less than the full message). After a portion
of a response is lost, the VIM sends no further Modbus requests.
DD-538,
Modified receive handling of Modbus TCP/IP message in case the field device does Not applicable
DR-553
not send all expected bytes. Previously, the VIM would not time out if a partial
message was received. The VIM now will time out on a partial response when the
configured timeout period has passed, and all the bytes of a response have not
been received.
Page 12 of 16
Register values updated slowly on active datasets when disabling other datasets
DD-540,
and suppressing alarms via Scan Control. Registers now update at normal speeds Not applicable
DR-511
when any dataset is disabled and alarms suppressed.
Standby VIM in a redundant pair reports a bad dataset status when its network
cable is removed. When the network cable is restored, the standby VIM continues
to incorrectly report bad dataset status, if there are field devices with the bridge flag
enabled.
DD-542, The bridge flag prevented the standby VIM from dropping connection when the
Not applicable
DR-493 cable is disconnected. The error status is properly reported to DeltaV, but the
connection is not dropped as expected.
The Modbus TCP/IP connection to the field device is now properly closed if all field
devices behind a bridge are offline. The connection is automatically restored if the
network is repaired.
Unexpected IO Input or transfer failures for online field devices are reported after a
redundant VIM switchover. A momentary bad dataset status during switchover
DD-545, would sometimes result in a module alarm, via MERROR.
DR-568, Not applicable
DD-580 A redundant switchover will no longer report a momentary bad status for devices
that respond properly. Only devices that fail to respond within the timeout period
after a switchover will be reported bad.
NK-1800-0304:
If a field device has only output datasets and it is offline, the VIM will continually Output Only Devices
DD-549,
perform redundancy switchovers. This configuration is not supported. Each field Are Not Supported by
DR-575
device needs at least one input or output with readback dataset. Redundant
VIM1s/VIM2s
When configured with both the Bridge Device flag and Retry Count greater than 1,
the VIM may report good status for datasets of offline devices behind the Bridge
Device IP Address.
Previously, the VIM sent retries after a timeout to the next dataset under the Bridge
device IP address. If the next dataset belonged to an online device which
DD-619,
responded, the initial device which did not respond was incorrectly marked good. Not applicable
DR-596
With more retries, the VIM would try more datasets under the Bridge Device IP
address following the same behavior.
The VIM has been updated to handle status for each device configured within
DeltaV independently based on the configured Device Address. The VIM now
correctly sets status per device behind Bridges.
In a redundant VIM with a redundant without IP switching field device using the
One-to-One flag: The standby VIM did not report an error when the standby ping
DD-539, fails. Not applicable
DR-465
The standby VIM now correctly sets the standby dataset to a bad status when the
ping times out.
Inconsistent DeltaV Controller hardware MAINT_ALM is generated. Disconnecting
then reconnecting the VIM network cable activates the alarm. Rebooting the VIM
DD-557, with the network cable disconnected clears the alarm.
Not applicable
DR-578 The MAINT_ALM is now triggered when either the cable is disconnected or the VIM
boots without the cable connected. Rebooting without the network cable attached
no longer clears the alarm condition.
Page 13 of 16
When both VIMs are disconnected from the network, the field failure is reported
DD-601, correctly. Thereafter, when only the Standby VIM is reconnected, it remains in
DR-569, standby mode even with a valid field device mask. It is expected to go active. Not applicable
DD-564,
DR-572 The standby VIM now will transition to active when the active VIM experiences a
timeout and the standby VIM reports that it has more field devices online.
Version 4.5.6 of the driver introduced an issue where setting Simultaneous
Messages greater than one occasionally resulted in data read from the field not
being reported to DeltaV. DeltaV would show good status for these datasets but
DD-691 register data would be stale. Not applicable
This issue has been resolved and data changes from the field are now reflected in
the dataset register values regardless of the Simultaneous Messages setting.
When a redundant without IP switching field device is using ICMP as the standby
ping on a redundant VIM: It is possible for the VIM to check only one of the field IP
addresses for connectivity when they both go offline. This is a timing issue.
If the VIM is only checking one of the field IP addresses and the other address
DD-701 comes online, the datasets in DeltaV will still report bad because the VIM is waiting Not applicable
for the other IP address to become available.
The reconnect routine has been adjusted so that the VIM will check both IP
addresses when they both go offline. The timing issue that caused the VIM to use
only one field IP address has been removed.
10 Changes in v4.5.6
Checksum: 934A1D25AFE6566600DD19EA9578B5B0704FE8D3FCDE36EF096BD458D2BCF2C6
10.1 Enhancements
Issue Number Description Reference KBA
The connection method has been changed to not use an ICMP ping before
connection attempt. Instead, the connection attempt is started, and a 15-
Not Applicable Not applicable
second timeout is asserted. This new method optimizes connecting to field
devices, particularly in redundant systems.
VIM/VIM communications have been streamlined and optimized for faster

data exchange.
Redundancy switchover status reporting to DeltaV and switchover time have

been improved.
Page 14 of 16
10.2 Resolved issues
Issue Number Description Reference KBA
The VIM would report a time out for a field device even though the device is
online. Network trace indicates that the Modbus TCP/IP response is split
across multiple TCP segments, specifically, the 6-byte Modbus TCP/IP
header was not in one TCP segment.
Previously, if the VIM did not receive all 6 bytes, it discarded all already
received bytes and started a fresh receive. This caused a communication
loss and inability to communicate with the field device.
DR-519 Not applicable
Modified receive handling of 6-byte Modbus TCP/IP message header in
case field device does not send all 6 bytes at once. The VIM will wait for all
response bytes, regardless of how many TCP segments it takes to transmit.
If the required number of bytes is not received within the timeout period, the
VIM discards the bytes and closes the TCP session.
This correction overcomes the field device limitation where the response
message is sent in small fragments.
For redundant VIMs, dataset error reporting has been changed so that an
error is asserted for the Active VIM only if both connections in a dual-IP
redundant system are down. An error is not asserted if one connection is
down and the other is active.
Contact Information
Services are delivered through our global services network. To contact your Emerson local service provider, click Contact
Us. To contact the Global Service Center, click Technical Support.
Related products and services: DeltaV DCS | Lifecycle Services
Complete Article Revision History:

Revision/Publish Description of Revision
05 Oct 2021 Linked to compatibility KBA
09 Jun 2020 Added v4.6.5
21 Jan 2020 Added v4.6.4
31 Oct 2019 Added v4.6.3
06 Sep 2019 Added v4.6.2
20 Jun 2019 Added v4.6.1
24 Oct 2018 Modified v4.6.0 by adding enhancement DD-622
08 Oct 2018 Added v4.6.0
28 Mar 2018 Original Release of Article
©Emerson Automation Solutions 2009-2021. All rights reserved. For Emerson Automation Solutions trademarks and service marks, click this link to
see trademarks. All other marks are properties of their respective owners. The contents of this publication are presented for informational purposes
Page 15 of 16
only, and while diligent effort has been made to ensure their accuracy, they are not to be construed as warrantees or guarantees, express or implied,
regarding the products or services described herein or their use or applicability. All sales are governed by our terms and conditions, which are
available on request. We reserve the right to modify or improve the design or specification of such products at any time without notice.
View Emerson Products and Services: Click This Link
Page 16 of 16

Nk18000016 - Iod4111 Modbus Tcpip Vim2 Release Notes

Uploaded by

Copyright:

Available Formats

You might also like

Nk18000016 - Iod4111 Modbus Tcpip Vim2 Release Notes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nk18000016 - Iod4111 Modbus Tcpip Vim2 Release Notes

Uploaded by

Copyright:

Available Formats

Knowledge Base Articles

IOD-4111 Modbus TCP/IP VIM2 Release Notes

Article ID: NK-1800-0016

Recent Article Revision History:

3.2 Pre-upgrade considerations

3.3 Post-upgrade considerations

3.4 Installing the firmware on existing installations

4.2 Resolved Issues

5.2 Resolved issues

6.2 Resolved issues

7.2 Resolved issues

8.2 Resolved issues

Issue Number Description Reference KBA

VIM/VIM communications have been streamlined and optimized for faster

Redundancy switchover status reporting to DeltaV and switchover time have

Issue Number Description Reference KBA

Related products and services: DeltaV DCS | Lifecycle Services

Complete Article Revision History:

View Emerson Products and Services: Click This Link

You might also like