Technical FAQs

Ask a Question

NOE77101 Exec Firmware version 4.4

Goals and Symptoms

Provide the list of enhancements and fixes that are included in exec firmware version 4.4 for the 140NOE77101.

Facts and Changes

140NOE77101 exec firmware version 4.4

Causes and Fixes


  • Incorporate IGMP support into the Global Data implementation.

Problems fixed:
  • The 'Local Rack' web page does not show any modules or racks that are linked to the first local
rack with an 'XBE100 00'.
  • The NOE manages two crash logs that could be found in two files named
‘/FLASH0/wwwroot/conf/diag/crash.log’ and ‘/FLASH0/fw/crashlog.txt’ but, only one of them is
  • shown in the Web pages. The two crash logs need to be merged into one.
  • The online help describing the number of PRODUCTS that supports the MBP_MSTR block is
  • The start address and length of the write data to the slave MBP_MSTR block is described
  • The online description for the fourth implied register (control [5]) of the MBP_MSTR block is
  • The online help for the MBP_MSTR block does not show where the data that will be used to write
to or read from the remote device is stored. There appears to be only one data buffer to store both
the write and read data base. No description can be found specifying the structure of the data buffer.
The description should show that the data buffer must be the size of the data to be written and the
data to be read. It should also describe that the data buffer stores the write data first followed by the
read data from slave.
  • Online information is needed for the MBP_MSTR block stating that the control buffer and the data
buffer must use located addresses. The MBP_MSTR block will not work with if the control and data
buffer are defined using un-located memory addresses. (i.e., %MW).
  • The 'NOE 771 01 and 'NOE 771 11 V2.0' referenced in the online help, applies only in Concept
with the MSTR block. Function 23 client and server support in Unity (MBP_MSTR) applies only
to the 'NOE 771 01' and 'NOE 771 11' which can be found in V3.0 of the NOE firmware.
  • The NTP service behavior in UNITY is not the same as that found in and a PL7 application. In
PL7, the PLC clock is update is identical period to that configured for the update of the module by
the server. The clock is updated too often in a Unity application.
  • The I/O Scanner does not check the reply from the slave to ensure that the Modbus transaction ID
matches the current request that has been sent out.
  • If the NOE is configured with a duplicate IP address, it still responds to its previously configured IP
  • The online description for control block word 3 of the 'Write CTE' ethernet communication does not
correctly specify the number of words to transfer. The format appears to require 11 words based on
the 'datbuf' length, but the length needs to be 12 in order for the MBP MSTR to work.
  • On a HSBY switchover and re-starting 'I/Scanner', sometimes on NOE swap over, it was seen that
new Primary NOE takes up to 12sec to talk to devices.
  • Bootp does not work on a '140NOE77101' with version 4.3 Exec Firmware.
  • Communications gradually degrades then stops. After 13-30 minutes it recovers on its own.
  • A broadcast storm on the network results in 'Stop Code 80' in PLC.
  • On sending a trap event to the network manager the NOE should be identifying itself as
136141-3833 (where 3833 is the identification for Schneider), but the NOEs instead responds
with an identity 123456, etc.
  • SMTP may not work with certain external email servers. The documentation has been updated to
recommend the use of Lotus Domino, Microsoft Exchange, or Sendmail.
  • 'I/O scanner' is disabled when another entry is disabled.
  • The web page for exec firmware version 4.20 shows that 10/100BASE-T is being used when the
NOE is connected using fiber optic.
  • If the subnet mask is changed from ‘’ to ‘’ or the frame type is changed from
‘Ethernet II’ to IEEE802.3, the ‘IO Scanner’ will stop working after the application is downloaded with the
NOE. The ‘IO Scanner’ starts to work if the Concept is disconnected from the NOE.
  • During a ‘Hot Standby’ system switch over, sometimes the primary NOE goes into fault mode for
20 seconds and then starts communicating normally.

Was this helpful?
What can we do to improve the information ?