Release Notes
iTRAK System, Firmware Revision 3.003
Bulletin 2198T
This publication contains release notes for the iTRAK® system, firmware revision 3.003, when used with the Studio 5000 Logix Designer® application.
Topic |
Page |
Considerations |
1 |
Restrictions |
2 |
Enhancements |
3 |
Corrected Anomalies |
14 |
Known Anomalies |
14 |
Additional Resources |
15 |
Considerations
When using this firmware, consider the following.
•The example Logix program file is being deprecated and may be eliminated in a future release of the firmware. You are encouraged to use the ICT Libraries to write your Logix programs for your iTRAK systems.
•When upgrading from a previous revision of firmware, and your Logix program is based on the example Logix program, the following items must be imported or copy/pasted:
-P01_iTRAK_Communications
-P01_Main_Program
-P00_Faults_Version_and_CIP_Messaging
-UDT_iT_Faults
-UDT_iT_Fault_Array
-UDT_iT_Fault_Strings
-Controller Tag iTRAK_Faults (Copy/Paste)
-Controller Tag iTRAK_Fault_Strings (Copy/Paste)
•To make the EtherNet/IP™ connection and complete initialization, the following conditions are required:
-The controller must be on.
-The Logix program must be running.
-If iTRAK Power Supplies (iPS) are being used, the associated Diode Front End (DFE) must be ready and communicating.
•Headway checking is done only in the gateway. The Logix program no longer performs this task.
•Changes to the track configuration that are made while the track is enabled do not take effect until the track is disabled and reenabled. If configuration changes do not match the actual track configuration, faults are generated when the track is reenabled.
•The default timing model is for the ControlLogix® 5580 controller.
iTRAK System, Firmware Revision 3.003 Release Notes
•The 400-byte configuration packet is required for both ControlLogix 5570 and 5580 controllers. The first byte represents the timing model of the controller. The default is 2, to represent 2-cycle timing in the program.
-For the ControlLogix 5570 controller, which is not supported, the controller tag Gateway_Movers0to15:C.Data [0] must be changed to 1, to represent 1-cycle timing.
-For the ControlLogix 5580 controller, the controller tag Gateway_Movers0to15:C.Data [0] is set to 2 (default), to represent 2-cycle timing.
•Unicast Ethernet Communication is the only communications method that works with networks other than 192.168.x.y.
•Multicast Ethernet Communication is required for the second and succeeding I/O modules (more than 16 movers).
•The only support for more than 16 movers is a 192.168.x.y network.
•The mover torque percentage range is 0…125%.
Unless updated in a section for a later revision, these restrictions apply from their revision of introduction.
•In order for the iTRAK system to function properly, a USB-IIRO-4 device from Access IO Products, Inc, must be connected to the gateway via a USB connection, regardless of the Power Supply Mode (PCM or iPS) that is specified. This hardware does not have to be used in any other way. However, failure to connect this hardware to the gateway prevents the gateway from fully initializing and running.
•This firmware release supports the third-generation gateway hardware. Only V3.xxx versions of firmware will run on the third-generation gateway.
•The Position Loop and Velocity Loops are synchronized and run in the same period.
•When more than five movers are present on or seen by a single motor module, the minimum time that the motor module requires to process the movers is 1000 microseconds. This forces the minimum Position Loop Period to be 2 milliseconds. If your application can guarantee that no more than five movers can be seen at any one time on any given motor module, the iT_MPM AOI can be used to set the maximum number of movers-per- motor module that is used by the motion profile, and ease the 2 millisecond restriction.
•When a program is downloaded, the time or master time is changed, or the EtherNet/IP™ connection is broken and restored, the following can occur:
-The iTRAK_Control.StatusGatewayRunning tag is set to 0 for several seconds. If there are more than 16 movers on the system, the time that iTRAK_Control.StatusGatewayRunning tag dwells at 0 can be longer. The system auto-restarts the gateway to make sure that there is communication between the controller and gateway.
-If the iTRAK system was enabled, a FaultCode 9 is generated and displayed when the
iTRAK_Control.Status.GatewayRunning tag returns to a value of 1.
-If motion was being performed, the motion stops, and faults are generated depending on the stopped position of the movers.
-If there was a program download and an iTRAK power supply was in use, the power supply must be reset and the FaultCode 30 cleared.
2 |
Rockwell Automation Publication 2198-RN001P-EN-P - February 2021 |
iTRAK System, Firmware Revision 3.003 Release Notes
These enhancements correspond to the iTRAK system firmware revision when used with the Logix Designer application.
Table 1 - Enhancements with Revision 3.003
Enhancement |
|
Description |
|
|
|
|
|
|
|
|
|||
Support for Additional Movers |
|
The iTRAK firmware and associated example Logix file have been modified and tested to allow up to 104 movers on a track, |
|
|||
|
|
with a potential of up to 250 movers in the future. |
|
|||
|
|
|
|
|||
New Fault Codes and New Fault Code Structure |
|
The complicated set of gateway fault codes and section fault codes has been replaced with a simplified single fault code and |
|
|||
|
|
extended information. Please see Table 2 for details about the new set of fault information. |
|
|||
|
|
To accommodate the new set of faults, members of UDT_iTRAK_Status have been changed. |
|
|||
|
|
The following members have been removed: |
|
|||
|
|
• |
GatewayFaultCode |
|
|
|
|
|
• |
SectionFaultCode |
|
|
|
|
|
• |
SectionNumberFaulted |
|
|
|
|
|
• |
SectionDeviceFaulted |
|
|
|
|
|
• |
SectionFaultData |
|
|
|
|
|
• |
FaultMessageLine1 |
|
|
|
|
|
• |
FaultMessageLine2 |
|
|
|
|
|
The following new members have been added: |
|
|||
|
|
• |
ERR |
DINT |
New fault code |
|
|
|
• |
EXERR |
DINT |
New extended numeric fault information |
|
|
|
• |
FaultDescription |
STRING |
New fault description |
|
|
|
As before, the new fault-related fields in the controller tag iTRAK_Control.Status will contain information on |
|
|||
|
|
the first fault that is generated when fault conditions occur. |
|
|||
|
|
The fault information is not persistent. When the controller tag iTRAK_Control.Cmd.FaultReset is |
|
|||
|
|
latched, all fault information is cleared. |
|
|
||
Ability to View Multiple Generated Faults |
|
Frequently on the iTRAK system, several faults are generated when fault conditions occur. However, only information about |
|
|||
|
|
the first generated fault would be sent to the Logix controller. Often this meant that the most relevant fault would not be |
|
|||
|
|
displayed. |
|
|
|
|
|
|
To address this issue, the User-defined type UDT_iT_Faults and the associated controller tag iTRAK_Faults have |
|
|||
|
|
been added. This array of 64 elements of type UDT_iT_Faults supplies information about the first 64 faults that occur on the |
|
|||
|
|
iTRAK system whenever fault conditions happen. The following members belong to UDT_iT_Faults: |
|
|||
|
|
• |
TimeStamp |
DINT |
Relative timestamp in nanoseconds from the first reported fault |
|
|
|
• |
ERR |
DINT |
New fault code |
|
|
|
• |
EXERR |
DINT |
New extended numeric fault information |
|
|
|
• |
FaultName |
STRING |
New fault name |
|
|
|
• |
FaultDescription |
STRING |
New fault description |
|
|
|
This array of faults is neither cumulative nor persistent. When the controller tag |
|
|||
|
|
iTRAK_Control.Cmd.FaultReset is latched, all fault information is cleared, and the information is stored in |
|
|||
|
|
the persistent, cumulative fault log file that is maintained internally on the gateway. |
|
|||
Persistent Fault Log |
|
The iTRAK system now maintains a persistent, cumulative fault log file that is stored internally on the gateway. This comma- |
|
|||
|
|
separated value (.csv) file contains the following information about each of the faults: |
|
|||
|
|
• |
Timestamp |
Absolute Eastern Daylight system date and time (in year, month, day, hour, minute, second, and |
|
|
|
|
|
|
nanosecond) when the fault was generated. |
|
|
|
|
• |
ERR |
New fault code |
|
|
|
|
• |
FaultName |
New fault name |
|
|
|
|
• |
FaultDescription |
New fault description |
|
|
|
|
• |
EXERR |
New extended numeric fault information |
|
|
|
|
Whenever the controller tag iTRAK_Control.Cmd.FaultReset is latched or the gateway is reset, any |
|
|||
|
|
faults that currently exist are added to the fault log file. |
|
|||
|
|
The fault log file is limited to a maximum size of 100 megabytes. If an attempt to save additional faults would exceed this limit, |
|
|||
|
|
the faults are temporarily saved and a fault 249 (‘Fault Log File too Large to Add Faults’) is generated. This gives the user one |
|
|||
|
|
last opportunity to retrieve the fault log from the iTRAK system before resetting the faults once again. On the fault reset |
|
|||
|
|
immediately following the fault 249, the fault log file is removed, and the faults generated prior to and including the fault 249 |
|
|||
|
|
are stored in the newly emptied fault log file. |
|
|||
|
|
The fault log file can be retrieved using the V3.003 version of the iTRAK Log Retrieval Tool. |
|
|||
|
|
|
|
|||
|
Rockwell Automation Publication 2198-RN001P-EN-P - February 2021 |
3 |
iTRAK System, Firmware Revision 3.003 Release Notes
Table 1 - Enhancements with Revision 3.003 (Continued)
Customer Log File Simplification |
As fault reporting on the iTRAK system has been significantly improved, the amount and kind of data that is supplied in the |
|
standard iTRAK log files has been greatly reduced and simplified. The resulting log files are much easier to read and |
|
understand. |
|
These log files can be retrieved using the iTRAK Log Retrieval Tool. |
|
|
Addition of Developer Log Files |
The iTRAK system now generates very detailed log files for use by Customer Support Engineers, Motion Solution Consultants, |
|
GOTCs, Firmware Developers, and other Rockwell Automation employees. These encoded log files can be retrieved using the |
|
V3.003 version of the iTRAK Log Retrieval Tool and sent to the appropriate Rockwell Automation employees whenever |
|
additional assistance is required. |
|
|
Improved Initial Connectivity between the Logix |
With the introduction of the third-generation gateway hardware, the gateway often had to be restarted automatically to |
Controller and the iTRAK System |
establish solid and robust Ethernet/IP communications between the Logix Controller and the iTRAK system. Firmware |
|
modifications and improvements have been made such that the automatic restart is no longer required. |
|
|
Addition of Clean Startup Capability to Simplify |
The iTRAK system maintains information about the last position and status of all movers when the system was shut down. In |
Commissioning, Static Addition and Removal of |
certain instances (for example, when initially commissioning a track, when replacing motor modules, and when adding or |
Movers, and Motor Module Replacement |
removing movers), this mover position and status information may be invalid, and must be regenerated from information |
|
obtained from the track. |
|
To assist in this “scratch build” of mover position and status information, a Clean Startup capability has been created, and the |
|
member “CleanAndResetGateway” has been added to the user-defined type UDT_iTRAK_Cmd. |
|
When the controller tag iTRAK_Control.Cmd.CleanAndResetGateway is latched, the stored mover |
|
position and status information are removed, and the gateway is reset. This causes the gateway to rebuild the stored mover |
|
position and status information from new information obtained from the track. |
|
To ensure that the stored mover information gets reconstructed cleanly and accurately, it is best to adhere to the following |
|
rules regarding mover positioning during a Clean Startup: |
|
1. No Movers on Curves |
|
2. For tracks with more than 8 motor modules, no movers next to curves. |
|
3. No more than five 50 mm movers, three 100 mm movers, and two 150 mm movers on a single motor module. |
|
4. No movers on or within +/- 3 mm of motor module transitions. |
|
To assist in following these rules, faults are generated for any violations. However, the new stored mover information is |
|
still generated, and may be valid, despite any faults. |
The usual procedure for a Clean Startup is as follows:
1.Shut down the track.
2.Make all the mover adjustments, additions, removals, and motor module replacement.
3.Restart the track.
4.When the track comes up, if the correct number and position of all movers is displayed in the controller tag iTRAK_Control.Status.ActualPosition, the process is complete, and any faults that may have occurred can be ignored and reset.
5.Otherwise, issue the iTRAK_Control.Cmd.CleanAndResetGateway command.
6.After the system comes up completely, if the correct number and position of all movers is displayed in the controller tag iTRAK_Control.Status.ActualPosition, the process is complete and any faults that may have occurred can be ignored and reset.
7.Otherwise, make appropriate mover position adjustments as any faults may recommend, and repeat steps 5 and 6 until iTRAK_Control.Status.ActualPosition accurately reflects the state of the track.
4 |
Rockwell Automation Publication 2198-RN001P-EN-P - February 2021 |
|
iTRAK System, Firmware Revision 3.003 Release Notes |
|
Table 1 - Enhancements with Revision 3.003 (Continued) |
||
|
|
|
Relaxed Restrictions on Motion Polarity and |
The controller tags iTRAK_Control.Data.MotionPolarity, |
|
Numbering Order Tags |
iTRAK_Control.Data.ReverseMoverNumbering, and |
|
|
iTRAK_Control.Data.MoverNumberingOffset no longer require a First Scan condition to take |
|
|
effect. However, the track must be de-energized for these tags and the |
|
|
iTRAK_Control.Data.PositionOffset tag to take effect. |
|
|
|
|
Power on self-test (POST) on Demand |
The power on self-test (POST) no longer runs as part of the initialization sequence at power-up or gateway reset. Instead, the |
|
|
Controller tag iTRAK_Control.Cmd.RunPOST has been added to allow you to choose when the POST is to be run. |
|
|
The POST can only be run when the track is not energized. When the POST completes, the Controller Tag |
|
|
iTRAK_IPSSupport.POSTDone is set to ‘1’. This tag is used for both PCM and iPS power supply modes. If the |
|
|
POST fails while it is running, the appropriate faults indicating the problem are generated. |
|
|
It is recommended that the POST be run during the application's power-up sequence, as soon as high-voltage power is |
|
|
available. Otherwise, motor module problems that could cause damage to the track and/or tooling, such as a bad motor coil |
|
|
or driver chip, go undetected until the damage occurs. |
|
ECO Current Mode |
Eco Current Mode decreases the amount of current used by the iTRAK system as the movers cross transition between motor |
|
|
modules. However, Eco Current Mode also has the side effect of significantly decreasing performance across the track. |
|
|
Eco Current mode is OFF by default. It can be turned off or on using the Controller Tag |
|
|
iTrak_Control.Cmd.ToggleEcoCurrentMode. |
|
|
Toggling this tag causes the Gateway to reset. |
|
Table 2 - Fault Code and Fault Code Structure
ERR – Fault Name |
Fault Description |
EXERR |
Details |
|
|
|
|
1 – Internal Error |
Internal gateway error during initialization. |
|
The gateway failed during initialization due to an internal error. Check all |
|
|
|
power and communications cables and connections. Then, power-cycle |
|
|
|
the system. If the problem persists, contact ICTSupport@ra.rockwell.com |
|
|
|
for assistance. |
2 – iMF Initialization Failure |
Track initialization failure. |
|
Initialization of the gateway failed. Check all power and communications |
|
|
|
cables and connections. Then, power-cycle the system. If the problem |
|
|
|
persists, contact ICTSupport@ra.rockwell.com for assistance. |
|
|
|
|
3 – Internal Motor Module Failure |
Internal error in motor module EXERR. |
Motor |
The motor module specified in EXERR had an internal error. Check all |
|
|
Module |
power and communications cables and connections. Then, power-cycle |
|
|
Number |
the system. If the problem persists, contact ICTSupport@ra.rockwell.com |
|
|
|
for assistance. |
|
|
|
|
4 – Power-on Self-test Internal |
iPS fault-clearing failure caused POST failure. |
|
The Power-On Self-Test failed due to the inability to clear an iPS fault. Make |
Error |
|
|
sure that all the DFE and iPS modules are functioning correctly. Then, |
|
|
|
power-cycle the system. If the problem persists, contact |
|
|
|
ICTSupport@ra.rockwell.com for assistance. |
|
|
|
|
5 – Bad Motor Module Coils |
Bad coils on motor module EXERR during POST. |
Motor |
One or more bad coils on the motor module specified in EXERR were found |
|
|
Module |
during the Power-On Self-Test. If power-cycling and a subsequent rerun of |
|
|
Number |
the POST does not eliminate the problem, the motor module should be |
|
|
|
replaced. |
|
|
|
|
6 – Motor Module Coil Overheat |
Coils overheated in motor module EXERR. |
Motor |
One or more coils has overheated in the motor module specified in EXERR. |
|
|
Module |
Shut down the system, allow it to cool down for 10…15 minutes, and then |
|
|
Number |
restart it. If the problem persists, contact ICTSupport@ra.rockwell.com for |
|
|
|
assistance. |
|
|
|
|
7 – IRAM Error Threshold Exceeded |
Recoverable IRAM errors on motor module EXERR |
Motor |
Recoverable errors on the IRAM board of the motor module specified in |
|
exceeded threshold. |
Module |
EXERR have exceeded the allowable threshold. If power-cycling and a |
|
|
Number |
subsequent rerun of the POST does not eliminate the problem, the motor |
|
|
|
module should be replaced. |
Rockwell Automation Publication 2198-RN001P-EN-P - February 2021 |
5 |