XM Firmware Revision 4

Transcription

1 Release Notes XM Firmware Revision 4 What s in These Release Notes These release notes provide the following information. For information about See page Revision 4 Enhancements 1 Special Issues When Upgrading to a New Major Revision 4 Revision 4 Corrected Anomalies 6 Revision 4 Enhancements This section describes the new features in major revision 4. General Revision 4 Enhancements Triggered Trend Several XM modules (see Table 1) can be configured to store a trend of various measurement parameters in response to a trigger event. The trigger event can be an internal relay activation, manual user request, or automatic I/O request from an XM-440 module. You can select which measurements are included in the trend records, the interval between trend records, and other configuration settings. Once stored, the trend data can be read and displayed at a later time using client software applications. Hundreds of data records can be stored in the trend. The exact number of records depends on how many measurement parameters you select to be included in the trend. Table 1 shows the trend features that are available for each XM module. For more information on the startup/coast-down trend, see Startup/Coast-Down Trend on page 2. Table 1 Trend features per XM modules XM Module Triggered Trend Startup/Coast-Down Trend XM-120 Yes Yes XM-120E No No XM-121 Yes Yes XM-122 Yes Yes XM-123 Yes Yes XM-220 No No 1

2 2 XM Firmware Revision 4 Table 1 Trend features per XM modules XM Module Triggered Trend Startup/Coast-Down Trend XM-320 Yes No XM-360 Yes No XM-361 Yes No XM-362 Yes No 4-20 ma Output Off During Transducer Fault If there is a Transducer Fault or Tachometer Fault that could affect the status of a measurement, any corresponding 4-20 ma Output will be turned off. The 4-20 ma Outputs produce between 4 and 20 ma (with 10% overshoot and undershoot) while they are on. They output less than 3.6 ma (approximately 2.9 ma) when they are off. New XM Modules The following XM modules are released in revision 4: XM-120 Eccentricity module, XM-123 Aeroderivative module, and XM-220 Dual Speed module. XM-12X Revision 4 Enhancements Startup/Coast-Down Trend The XM-12X modules (see Table 1) support a startup/coast-down trend in addition to the triggered trend described on page 1. The startup/coast-down trend also stores trend data for later retrieval. But storage of the startup/coast-down trend is triggered by the measured machine speed. You can select which measurements are included in the trend records, the delta-rpm between trend records, and the min and max speed limits at which storage starts and stops. Stored Spectrum and Waveform When the triggered trend's trigger event occurs, a snapshot of the current spectrum or waveform data set can be stored for later retrieval. This stored data set is sometimes referred to as a "trip" spectrum or waveform data set. Inhibit Tachometer Fault During Startup A new configuration parameter has been added to the configuration tools and EDS file that allows you to prohibit the Tachometer Fault alarm status during the startup period (while the setpoint multiplier is active).

3 XM Firmware Revision 4 3 Acceleration Measurement A new Acceleration measurement is available in the XM-120, XM-121, and XM-122 modules. This acceleration is the rate-of-change of the Speed measurement. IMPORTANT The Acceleration measurement is included in the Poll response message so the maximum size of the Poll response message increases from 120 to 124 bytes. Improved Alarm Reaction to Setpoint Multiplier The status of the alarms is updated whenever the setpoint multiplier feature changes status. This enhancement eliminates the possibility of a delay before the alarm reflects the new status. XM-360 Revision 4 Enhancement Additional XM-360 Data Units Two additional data unit options are supported percent and unspecified. XM-440 Revision 4 Enhancements Group Triggering The XM-440 can send a trigger event to a group of its slave modules in response to one or more relay activations. Up to four module groups can be defined. Each group has its own set of relay activations that will result in a trigger event being sent to the slaves in the group. The slave modules will store their triggered trend data and their "trip" spectrum/waveform data when they receive this trigger. IMPORTANT This new feature will only work with slave modules that are running Revision 4 firmware or later.

4 4 XM Firmware Revision 4 Support for New XM Modules XM-440 Revision 4 supports the new XM-120 Eccentricity module. Support for the Eccentricity module was also included in XM-440 Revision and later firmware revisions. Any XM-440 firmware prior to R3.010 does NOT support the XM-120 Eccentricity module. XM-440 Revision and later revisions support the new XM-220 Dual Speed and XM-123 Aeroderivative modules. XM-440 firmware revisions prior to R4.050 do NOT support the XM-220 or XM-123 modules. Special Issues When Upgrading to a New Major Revision Consider the following special issues before upgrading your firmware to a more recent major revision. If a particular module or major revision is not listed then there are no special issues to consider. General Considerations If you use the XM Serial Configuration Utility, you will need to install and use the version of the XM Serial Configuration Utility that corresponds to the new firmware s major revision. You can download the appropriate XM Serial Configuration Utility from the XM Firmware Update page at the following URL: If you use Enterprise Online Configuration Utility or RSNetWorx with your XM modules, you will need to download and register the EDS files that correspond to the new firmware s major revision. You can download the appropriate XM EDS files from the following URL: General purpose master/scanner devices such as the XM-500 and 1756-DNB typically use the slave's major revision as one of the keys used to identify the slave module. So if you update the slave's firmware to a new major revision then you may need to update the configuration of any master/scanners that own this slave. Note that the XM-440 Master Relay module does not use the slave's major revision as an identification key so you won't need to update the XM-440 configuration for this reason.

5 XM Firmware Revision 4 5 XM-12X Firmware Upgrade Considerations Upgrading XM-120 Revision 1 to Revision 2 or Greater Any saved configuration will be lost and the factory defaults will be restored. The 23.8 Hz high pass filter that existed in the Series A hardware is no longer supported. If you have Series A hardware, the 23.8 Hz filter will be identified by the configuration software as a 40 Hz filter. DO NOT USE THIS FILTER because it will produce incorrect data. The other high pass filter selections are fine. The size of the I/O Poll Response message increases from 56 to 120 bytes. This means: If you are using an XM-440, then you need to upgrade the XM-440 to Revision 2 firmware or greater. The scan list of any XM-500 or any other Master/Scanner besides the XM-440 will have to be reconfigured to support the larger Poll message size. Any ladder logic programs that rely on the mapping of the scan list data may have to change to reference the new mapping in the modified scan list. Any PanelView monitor that may be listening for a 56 byte Poll Response message from the XM-120 will have to be changed to expect a 120 byte message. Upgrading XM-12X Revision 2 to Revision 3 or Greater If you have an XM-440 and plan to change the size of the XM-12X I/O Poll Response message from its default size of 120 bytes, you must also upgrade the XM-440 firmware to Revision 3 or greater. Upgrading XM-12X Revision 3 to Revision 4 or Greater The new Acceleration measurement is included in the Poll Response message, increasing the maximum size of the Poll Response message from 120 to 124 bytes. If you want to use the new Acceleration measurement data, then you may need to reconfigure the Poll Response Assembly instance and size so that the new measurement is included. If you are not interested in the Acceleration measurement data, then you may still need to reconfigure the Poll Response size in order to get all of the same data you were getting from the Revision 3 firmware.

6 6 XM Firmware Revision 4 The Acceleration measurement value is appended to the end of the Poll Assembly instances 101, 103, and 106. This means that the format of the first 120 bytes of these instances has not changed from Revision 3 to Revision 4. If your XM-12X is configured for one of these instances and you are not interested in the Acceleration measurement, then you do NOT need to change your configuration. However, the Acceleration measurement value is inserted into Poll Assembly instances 102, 104, and 105. This insertion increased the byte offset by 4 for all the measurements after the Acceleration measurement. If your XM-12X is configured for one of these instances, then you should revisit the Poll Response configuration. You may need to increase the size of the Poll Response message by 4 bytes to include all of the data that was in the Revision 3 Poll Response message. Any ladder logic programs that rely on the format of the Poll Response may need to be adjusted to match the new Revision 4 format. Any PanelView monitor applications that are listening for the Poll Response may need to be adjusted as well. XM-440 Firmware Upgrade Considerations Upgrading from Revision 1 to Revision 2 If you have any XM-120 slave modules, you need to update them to Revision 2 firmware as well. Upgrading from Revision 3 to Revision 4 or Greater If you plan to use the new Group Trigger feature, then you need to upgrade all of your slave modules to Revision 4 firmware. Revision 4 Corrected Anomalies This section describes anomalies corrected in recent firmware revisions. The corrected anomalies are organized by the firmware revision that corrected them.

7 XM Firmware Revision 4 7 XM-120/121 Firmware Revisions XM-120/121 Revision Table 2 Corrected Anomalies TACH LED not functioning properly. Possible performance issues. Reset/lock-up might have occurred while the module was detecting the DeviceNet baud rate. Possible erroneous tach fault in auto trigger mode. Reset service did not properly reset all the relays and could have led to a reset/lock-up of the module. The TACH LED was lit for Speed measurement alarms but not for Acceleration measurement alarms. The module did not perform well when all of the features, such as alarms, 4-20 ma outputs, and trends, were enabled. The module might have even reset and locked-up under extremely loaded conditions. If there was one device transmitting and there were no other devices online to acknowledge the transmitting device, the module might have reset and locked up when it attempted to autobaud. The module would require a manual reset. An erroneous tach fault in auto trigger mode could have occurred at very low speeds (i.e. less than 1 Hz) if there was a step change in the input signal frequency. The Relay object class level (instance 0) Reset service did not properly reset all of the relays and could have led to a reset/lock-up of the module. The XM software tools do not provide an interface for resetting all relays, just individual relays. So this anomaly would have been encountered only if you exercised this service manually (e.g. Class Instance Editor). XM-120/121 Revision Table 3 Corrected Anomalies Enabled alarms might have remained in the DISARM alarm state incorrectly. Unsatisfactory Speed measurement performance. Possible incorrect Acceleration measurement value. If the setpoint multiplier switch remained closed while the module transitioned from Program Mode to Run Mode then any enabled alarms might have remained in the DISARM alarm state incorrectly. Reduced the response time for the Speed measurement to better meet overspeed application requirements. The Acceleration measurement value may have been incorrect immediately after going into Run Mode due to improper initialization. XM-120/121 Revision Table 4 Corrected Anomalies Possible offset error in the Overall and Time Waveform measurements. If there was an external DC bias applied to the input signal at the moment the module was powered up with a saved configuration, an offset error may have been introduced into the Overall and Time Waveform measurements. This offset error was most noticeable when IEPE power was configured to be on for the channel s transducer.

8 8 XM Firmware Revision 4 XM-120/121 Revision Table 5 Corrected Anomalies Possible incorrect time stamp on triggered trend data. The time stamp for the triggered trend was incorrect if the trend data that was actually collected spanned more than approximately 71.5 minutes. XM-120/121 Revision Table 6 Corrected Anomalies Phase measurements not working properly. Triggered trend data was not always collected. Possible incorrect time stamp on triggered trend data. Possible reboot/lock-up after setpoint multiplier switch closed. Phase measurements did not work properly when more than 1 pulse per revolution was selected for the transducer. The triggered trend data was not collected if the module had not logged on to the DeviceNet network (the Network Status LED was dark). The time stamp on all subsequently triggered trend data sets was incorrect after the module had been in Program Mode for more than approximately 71.5 minutes continuously. The following combination of circumstances might have caused the module to reboot and lock-up after the setpoint multiplier switched closed. It was necessary to cycle power to recover from this lock-up. An XM-441 Expansion Relay module was attached to the module AND At least one of the expansion relays (numbers 2-5) was configured so that it would change state in response to the closure of the setpoint multiplier switch. This could occur in response to the closure of either the actual setpoint multiplier switch terminals on the terminal base or the virtual setpoint multiplier switch available via DeviceNet or the serial port. XM-120/121 Revision Table 7 Corrected Anomalies Product Service Advisory Measurement values stopped updating after days of continuous operation. Failed firmware update via Ethernet. All measurement values stopped updating after days of continuous Run Mode operation if the tachometer was disabled (Number of Pulses per Revolution set to zero). The Overall measurement stopped updating after days of continuous Run Mode operation regardless of whether the tachometer was enabled. Refer to Product Service Advisory ICM for more information. A firmware update conducted over Ethernet via an XM-500 module would fail if the XM-500 was simultaneously scanning the module. The XM-120/121 module would require a reset after the failure. This revision eliminates the need to remove the XM-120/121 from the XM-500 scanlist before attempting to update the XM-120/121 firmware via Ethernet.

9 XM Firmware Revision 4 9 XM-120/121 Revision Table 8 Corrected Anomalies Possible erroneous measurement values for spectrum related measurements (band, vector, etc.). Issue with accuracy of the Spectrum and spectrum related measurements. Waveform data might not get stored when trigger event occurred. The module might have produced erroneous measurement values for the spectrum related measurements (band, vector, etc.) when synchronous sampling was selected and the measured speed changed relatively fast. Improved the accuracy of the Spectrum and spectrum related measurements. Previously, for configurations with Fmax greater than 10 KHz and with the tachometer enabled, a low pass filter with a relatively large overshoot was used for the Spectrum measurement. This filter caused some spectrum amplitudes to be amplified by as much as 7%. Band and Vector measurements were also affected. Now, a better filter with a flatter response is used. Error resulting from the spectrum filter response is now less than 2%. The module would not store waveform data when the trigger event occurred if the two channels were configured for orbit data (synchronous sampling, same waveform period and number of points, like transducers, etc.). XM-120/121 Revision Table 9 Corrected Anomalies Speed measurement might not update. If a Tach Fault condition existed when transitioning into Run Mode, the Speed measurement value was not updated. This caused any speed alarms to remain in the DISARM status while the TACH FAULT status was inhibited. In this revision, the Speed measurement value of zero is produced after a short period and the speed alarm status will transition to NORMAL while TACH FAULT is inhibited. XM-122 Firmware Revisions XM-122 Revision Table 10 Corrected Anomalies TACH LED not functioning properly. Possible erroneous tach fault in auto trigger mode. Reset service did not properly reset all the relays and could have led to a reset/lock-up of the module. The TACH LED was lit for Speed measurement alarms but not for Acceleration measurement alarms. An erroneous tach fault in auto trigger mode could have occurred at very low speeds (i.e. less than 1 Hz) if there was a step change in the input signal frequency. The Relay object class level (instance 0) Reset service did not properly reset all of the relays and could have led to a reset/lock-up of the module. The XM software tools do not provide an interface for resetting all relays, just individual relays. So this anomaly would have been encountered only if you exercised this service manually (e.g. Class Instance Editor).

10 10 XM Firmware Revision 4 XM-122 Revision Table 11 Corrected Anomalies Enabled alarms might have remained in the DISARM alarm state incorrectly. Unsatisfactory Speed measurement performance. Possible incorrect Acceleration measurement value. If the setpoint multiplier switch remained closed while the module transitioned from Program Mode to Run Mode then any enabled alarms might have remained in the DISARM alarm state incorrectly. Reduced the response time for the Speed measurement to better meet overspeed application requirements. The Acceleration measurement value may have been incorrect immediately after going into Run Mode due to improper initialization. XM-122 Revision Table 12 Corrected Anomalies Possible offset error in the Overall and Time Waveform measurements. If there was an external DC bias applied to the input signal at the moment the module was powered up with a saved configuration, an offset error may have been introduced into the Overall and Time Waveform measurements. This offset error was most noticeable when IEPE power was configured to be on for the channel s transducer. XM-122 Revision Table 13 Corrected Anomalies Possible incorrect time stamp on triggered trend data. The time stamp for the triggered trend was incorrect if the trend data that was actually collected spanned more than approximately 71.5 minutes. XM-122 Revision Table 14 Corrected Anomalies Phase measurements not working properly. Triggered trend data was not always collected. Possible incorrect time stamp on triggered trend data. Phase measurements did not work properly when more than 1 pulse per revolution was selected for the transducer. The triggered trend data was not collected if the module had not logged on to the DeviceNet network (the Network Status LED was dark). The time stamp on all subsequently triggered trend data sets was incorrect after the module had been in Program Mode for more than approximately 71.5 minutes continuously.

11 XM Firmware Revision 4 11 Table 14 Corrected Anomalies Possible reboot/lock-up after setpoint multiplier switch closed. The following combination of circumstances might have caused the module to reboot and lock-up after the setpoint multiplier switched closed. It was necessary to cycle power to recover from this lock-up. An XM-441 Expansion Relay module was attached to the module AND At least one of the expansion relays (numbers 2-5) was configured so that it would change state in response to the closure of the setpoint multiplier switch. This could occur in response to the closure of either the actual setpoint multiplier switch terminals on the terminal base or the virtual setpoint multiplier switch available via DeviceNet or the serial port. XM-122 Revision Table 15 Corrected Anomalies Product Service Advisory Measurement values stopped updating after days of continuous operation. Failed firmware update via Ethernet. All measurement values stopped updating after days of continuous Run Mode operation if the tachometer was disabled (Number of Pulses per Revolution set to zero). Refer to Product Service Advisory ICM for more information. A firmware update conducted over Ethernet via an XM-500 module would fail if the XM-500 was simultaneously scanning the module. The XM-122 module would require a reset after the failure. This revision eliminates the need to remove the XM-122 from the XM-500 scanlist before attempting to update the XM-122 firmware via Ethernet. XM-122 Revision Table 16 Corrected Anomalies Possible erroneous measurement values for spectrum related measurements (band, vector, etc.). Issue with accuracy of the Spectrum and spectrum related measurements. Waveform data might not get stored when trigger event occurred. The module might have produced erroneous measurement values for the spectrum related measurements (band, vector, etc.) when synchronous sampling was selected and the measured speed changed relatively fast. Improved the accuracy of the Spectrum and spectrum related measurements. Previously, for configurations with Fmax greater than 10 KHz and with the tachometer enabled, a low pass filter with a relatively large overshoot was used for the Spectrum measurement. This filter caused some spectrum amplitudes to be amplified by as much as 7%. Band and Vector measurements were also affected. Now, a better filter with a flatter response is used. Error resulting from the spectrum filter response is now less than 2%. The module would not store waveform data when the trigger event occurred if the two channels were configured for orbit data (synchronous sampling, same waveform period and number of points, like transducers, etc.).

12 12 XM Firmware Revision 4 XM-122 Revision Table 17 Corrected Anomalies Speed measurement might not update. If a Tach Fault condition existed when transitioning into Run Mode, the Speed measurement value was not updated. This caused any speed alarms to remain in the DISARM status while the TACH FAULT status was inhibited. In this revision, the Speed measurement value of zero is produced after a short period and the speed alarm status will transition to NORMAL while TACH FAULT is inhibited. XM-123 Firmware Revisions XM-123 Revision Table 18 Corrected Anomalies Issue with the Speed Multiplier value. The Speed Multiplier was not handled correctly if its value was greater than 2000 or if the fractional portion included more than three decimal places. XM-123 Revision Table 19 Corrected Anomalies Possible performance issues. Reset/lock-up might have occurred while the module was detecting the DeviceNet baud rate. Possible erroneous tach fault in auto trigger mode. Reset service did not properly reset all the relays and could have led to a reset/lock-up of the module. The module did not perform well when all of the features, such as alarms, 4-20 ma outputs, and trends, were enabled. The module might have even reset and locked-up under extremely loaded conditions. If there was one device transmitting and there were no other devices online to acknowledge the transmitting device, the module might have reset and locked up when it attempted to autobaud. The module would require a manual reset. An erroneous tach fault could have occurred at very low speeds (i.e. less than 1 Hz) if there was a step change in the input signal frequency. The Relay object class level (instance 0) Reset service did not properly reset all of the relays and could have led to a reset/lock-up of the module. The XM software tools do not provide an interface for resetting all relays, just individual relays. So this anomaly would have been encountered only if you exercised this service manually (e.g. Class Instance Editor).

13 XM Firmware Revision 4 13 XM-120 Eccentricity Firmware Revisions XM-120E Revision Table 20 Corrected Anomalies Possible erroneous tach fault in auto trigger mode. Reset service did not properly reset all the relays and could have led to a reset/lock-up of the module. An erroneous tach fault could have occurred at very low speeds (i.e. less than 1 Hz) if there was a step change in the input signal frequency. The Relay object class level (instance 0) Reset service did not properly reset all of the relays and could have led to a reset/lock-up of the module. The XM software tools do not provide an interface for resetting all relays, just individual relays. So this anomaly would have been encountered only if you exercised this service manually (e.g. Class Instance Editor). XM-120E Revision Table 21 Corrected Anomalies Issue with the Speed measurement. Reduced the response time for the Speed measurement. Now the firmware meets a 40 ms requirement for the response time for a 500 Hz/second increase in speed from steady state. XM-120E Revision Table 22 Corrected Anomalies Product Service Advisory Measurement values stopped updating after days of continuous operation. Failed firmware update via Ethernet. All measurement values stopped updating after days of continuous Run Mode operation if the tachometer was disabled (Number of Pulses per Revolution set to zero). Refer to Product Service Advisory ICM for more information. A firmware update conducted over Ethernet via an XM-500 module would fail if the XM-500 was simultaneously scanning the module. The module would require a reset after the failure. This revision eliminates the need to remove the module from the XM-500 scanlist before attempting to update the module s firmware via Ethernet. XM-120E Revision Table 23 Corrected Anomalies 4-20 ma Outputs were not turned off while there was a fault condition. The 4-20 ma Outputs were not turned off while there was a Transducer Fault or Tachometer Fault condition on the corresponding channel.

14 14 XM Firmware Revision 4 XM-320 Firmware Revisions XM-320 Revision Table 24 Corrected Anomalies Reset/lock-up might have occurred while the module was detecting the DeviceNet baud rate. Reset service did not properly reset all the relays and could have led to a reset/lock-up of the module. If there was one device transmitting and there were no other devices online to acknowledge the transmitting device, the module might have reset and locked up when it attempted to autobaud. The module would require a manual reset. The Relay object class level (instance 0) Reset service did not properly reset all of the relays and could have led to a reset/lock-up of the module. The XM software tools do not provide an interface for resetting all relays, just individual relays. So this anomaly would have been encountered only if you exercised this service manually (e.g. Class Instance Editor). XM-320 Revision Table 25 Corrected Anomalies Possible incorrect time stamp on triggered trend data. The time stamp for the triggered trend was incorrect if the trend data that was actually collected spanned more than approximately 71.5 minutes. XM-320 Revision Table 26 Corrected Anomalies Triggered trend data was not always collected. Possible incorrect time stamp on triggered trend data. Failed firmware update via Ethernet. The triggered trend data was not collected if the module had not logged on to the DeviceNet network (the Network Status LED was dark). The time stamp on all subsequently triggered trend data sets was incorrect after the module had been in Program Mode for more than approximately 71.5 minutes continuously. A firmware update conducted over Ethernet via an XM-500 module would fail if the XM-500 was simultaneously scanning the module. The module would require a reset after the failure. This revision eliminates the need to remove the module from the XM-500 scanlist before attempting to update the module s firmware via Ethernet. XM-320 Revision Table 27 Corrected Anomalies Possible offset error in measurement. On rare occasions, the module might introduce an offset error into the measurement.

15 XM Firmware Revision 4 15 XM-320 Revision Table 28 Corrected Anomalies The Startup Period for the Setpoint Multiplier prematurely expired. The Alarm Startup Period for the Setpoint Multiplier feature expired in half the time that it was configured for. For example, if you configured an alarm for a 30 second Startup Period, the startup period would expire after only 15 seconds. XM-360/361/362 Firmware Revisions XM-36x Revision Table 29 Corrected Anomalies Issues with the RTD measurement. Reset service did not properly reset all the relays and could have led to a reset/lock-up of the module. Minor improvements to RTD measurement performance. The Relay object class level (instance 0) Reset service did not properly reset all of the relays and could have led to a reset/lock-up of the module. The XM software tools do not provide an interface for resetting all relays, just individual relays. So this anomaly would have been encountered only if you exercised this service manually (e.g. Class Instance Editor). XM-36x Revision Table 30 Corrected Anomalies Data units did not correctly match module level temperature units selection for the XM-361 and XM-362. The setting of the per-channel data units parameters did not correctly match the module level temperature units selection for the XM-361 and XM-362. This prevented XM-361/362 channels from being mapped through the XM Emonitor Gateway into a measurement in Emonitor Odyssey. XM-36x Revision Table 31 Corrected Anomalies Possible incorrect time stamp on triggered trend data. The time stamp for the triggered trend was incorrect if the trend data that was actually collected spanned more than approximately 71.5 minutes.

16 16 XM Firmware Revision 4 XM-36x Revision Table 32 Corrected Anomalies Triggered trend data was not always collected. Possible incorrect time stamp on triggered trend data. Failed firmware update via Ethernet. The triggered trend data was not collected if the module had not logged on to the DeviceNet network (the Network Status LED was dark). The time stamp on all subsequently triggered trend data sets was incorrect after the module had been in Program Mode for more than approximately 71.5 minutes continuously. A firmware update conducted over Ethernet via an XM-500 module would fail if the XM-500 was simultaneously scanning the module. The module would require a reset after the failure. This revision eliminates the need to remove the module from the XM-500 scanlist before attempting to update the module s firmware via Ethernet. XM-36x Revision Table 33 Corrected Anomalies Channel 1 measurement possibly affected by noise. There was an uninitialized variable that made it possible for the channel 1 measurements to be affected by noise. XM-440 Firmware Revisions XM-440 Revision Table 34 Corrected Anomalies No support for the XM-123 and XM-220 modules. Failed firmware update via Ethernet. Added support for the XM-123 and XM-220 modules. A firmware update conducted over Ethernet via an XM-500 module would fail if the XM-500 was simultaneously scanning the module. The module would require a reset after the failure. This revision eliminates the need to remove the module from the XM-500 scanlist before attempting to update the module s firmware via Ethernet.

17 XM Firmware Revision 4 17 XM-440 Revision Table 35 Corrected Anomalies Relay status bits in the COS Assembly (instance 100) did not clear. When the XM-440 transitioned into Program Mode, any activated but unlatched relays deactivate as expected, but the corresponding relay status bits in the COS Assembly (instance 100) did not clear like they should have. This gave the mistaken impression that the relay was activated when in actuality it was not. If the relay was disabled while in Program Mode then the relay status bit in the COS Assembly would remain set even after returning to Run Mode.

18 XM is a registered trademark of Entek IRD International, a Rockwell Automation company. DeviceNet is a trademark of the Open DeviceNet Vendor Association (ODVA). www. rockwellautomation.com Corporate Headquarters Rockwell Automation, 777 East Wisconsin Avenue, Suite 1400, Milwaukee, WI USA, Tel: (1) , Fax: (1) Headquarters for Allen-Bradley Products, Rockwell Software Products and Global Manufacturing Solutions Americas: Rockwell Automation, 1201 South Second Street, Milwaukee, WI USA, Tel: (1) , Fax: (1) Europe/Middle East/Africa: Rockwell Automation SA/NV, Vorstlaan/Boulevard du Souverain 36-BP 3A/B, 1170 Brussels, Belgium, Tel: (32) , Fax: (32) Asia Pacific: Rockwell Automation, Level 14, Core F, Cyberport 3, 100 Cyberport Road, Hong Kong, Tel: (852) , Fax: (852) Headquarters for Dodge and Reliance Electric Products Americas: Rockwell Automation, 6040 Ponders Court, Greenville, SC USA, Tel: (1) , Fax: (1) Europe/Middle East/Africa: Rockwell Automation, Herman-Heinrich-Gossen-Strasse 3, Köln, Germany, Tel: 49 (0) , Fax: 49 (0) Asia Pacific: Rockwell Automation, 55 Newton Road, #11-01/02 Revenue House, Singapore , Tel: (65) , Fax: (65) Copyright 2005 Rockwell Automation, Inc. All rights reserved. Printed in the U.S.A.