1. Two additional Item User Fields were added.
2. Two User Fields were added to each coil record. Elclipse Uart Commands were added to allow the user fields to be set.
3. A print macro was added to allow the coil user field to be printed on Bundle tags or the part.
4. The Coil User Fields can be viewed by pressing the F6 key in the Production Coil screen. The user fields for the selected coil will be didplayed.
5. The Title Headers for the new Coil User Fields can be programmed via Eclipse Uart Commands.

The DSP exception reporting was modified due to recent DSP communication errors related to Ethernet Communications.

Before any data is attempted to be read or written to or from the DSP, the DSP interface port is tested to see if it is reporting an Exception.

The DSP documentation recomends against allowing the compiler to generate Nested Hardware Do loops. This feature was disabled in the project compiler settings.

The following example could be used to duplicate the issue on a private network.

PC has DHCP enabled with an alternate static configuration PC Ip address: 192.168.1.2 PC Subnet Mask: 255.255.0.0 PC Gateway 0.0.0.0 XL IP: 192.168.2.1 XL Subnet Mask: 255.255.255.0 XL Gateway 0.0.0.0

Due to the PC's subnet mask the PC believed the XL was on its alternate address subnet. The XL believed traffic from the PC was from outside of its subnet and so it used its invalid Gateway IP to route traffic back. Eventually the DSP, which contains the ethernet stack, stopped responding to the 80386 and the controller reset with a task error 0x8F0000E.

If the XL subnet was edited so that the invalid gateway was no longer used, the task errors could no longer be duplicated.

The DSP ethernet stack was modified to test the validity of the gataway before responding to traffic not on its subnet. The XL will no longer respond or attempt to resolve routes to IP addresses not in its subnet unless it has a gateway address that is also on its subnet.

Based on internal request, the default value for the Eclipse Source setup has been changed to Ethernet.

Based on internal request the MODBUS communication defaults were changed to 38400 Baud, No Parity, 1 stop bit, config address 0

Mueller asked for an option that allways deletes the coil from inventory on a tailout. They have issues with operators selecting old coils from the controller inventoy, just to get running. The operators are not answering the Completed or Return to Inventory question correctly.

They asked that we don't even ask the question about Completed or Returned but this is 1) not generic and 2) seemed unsafe for their system. We are not sure that their system could handle a controller using a coil that had been reported as completed.

We decided that the real problem is the coils that are being left in the coil inventory. We added the Remote option to the Yes and No options. Remote works the same as Yes except that the controller will only have the currently loaded coil in its inventory. In addition, the operators are forced to answer the Completed or Return to Inventory question. This is required because the coil is going to be deleted and we need them tell us how to report the coil to Eclipse.

Parameters may now be edited in Phases 2, 3 and 4 instead of just Phase 2, provided the parameter is editable in the selected phase.

Selecting which parameter to edit is now possible without using the virtual keyboard to enter a string in the correct format.

Changed the Cancel button text to Close so that there is no longer the indication that any edits that were made will be backed out.

Incorporated diagnostic edits to improve the diagnostic capabilities using flash wizard. The messages for SERCOS can be toggled on and off by typing DS, short for Display Sercos in the flash wizard screen.

The Text Wrapping Feature of Text Boxes had a bug in it that revealed itself when trying to wrap long text strings. The calculation for how much text was left to wrap was incorrect resulting in some text at the end getting truncated.

An Open Loop, Non-Stop shear is now supported in the XL200CL model. The controller must be configured for a Punch and Non-Stop operation. The feature is enabled with DIP switch 13. It is not compatible with the Alternating Press option.

A summary of the internal code changes include:

1. The Manual Punch code and Manual Shear code were both rather lengthy and had a lot of duplication. The Manual Punch code supported an Open Loop press but the Manual Shear did not. Tthe Manual Punch actually supported a Closed Loop Manual Shear but not an OL manual Shear. Since they were both very similar, the Manual Shear and Manual Punch code were merged together into one routine.
2. A few edits to enable the appropriate parameters for an Open Loop Shear were required.
3. The reference variables required to support both Die Accelerators and the Shear needed modification to remove the assumption that the Shear resided on one of the Die Accelerators. Updating the reference for each Die Accelerator needed additional testing added for the same reason.
4. The Open Loop Encoder Task was modified to test all presses. Closed Loop Presses will not set bits indicating they have OL targets so it is safe to test all presses.

This change is actually only available in the V4 XL2CL project but it is included with the V4 XL2OL, V4 XL220 and the V3 OL and CL projects due to the extensive changes in common code required to implement it. Any bugs caused by these changes will may impact the other project as well.

This change allows the Order Tree To Be configurable. Up to 5 fields can be configured to be visible and editable in the Order Tree. The sequence in which they appear is also configurable. Configuration is available through Eclipse.

Required fields are Order, Material and PCode. Any attempt to leave out one of these fields results in all three of them being added to the beginning of the configuration, displacing any configured field that will no longer fit within the five allowed fields.

Only the first three configured fields are displayed in the Order Sort Window.

The configured field titles are displayed in the Order Tree and Order Sort Window headers.

In order to support this change the Order tree only has two levels of indentation instead of indenting each subsequent field. Each field after the first share the same indentation level.

Expanding or Collapsing Orders was seemingly erratic in the Status Screen. The "NEXT" order(status) and the order after it were the only orders to experience the issue. There was some errant code that was attempting to expand these two orders when the screen auto updates itself that was working against the Expand Collapse function. The expanded state that is saved with the order record was being modifed without also forcing a refresh of the tree. This resulted in actual state of the controll not being in sync with the state of the order and caused the flaky behavior.

Tool Configurations have been added very similar to Setup Configurations.

A Tool Configuration has an ID, a Name and zero or more Tools.

The Configuration Menu has been renamed to Setup Configurations. A Tool Configurations menu has been added. When the Tool Configuration menu is selected and the grid has focus, the user can add, delete, copy, edit and load tool configurations. Editing a tool configuration is comprised of creating, deleteing, copying or editing tool records that comprise the Tool Configuration. Loading a Tool Configuration deletes all of the exiting Tool Data tools and replaces them with the tools from the configuration.

By design, tools are not protected from being edited after a Tool Configuration is loaded. If a customer prefers them to be protected they can use the setup lockout input.

A Tool Config. ID field was added to the Product Code Definitions. The Config. ID field was renamed to Set. Config. ID.

A new setup called Enforce Tool Config. by PCode was added. It defaults to NO. When set to YES it enables the Product Code Definitions menu, unless already enabled due to Multi-Axis. When set to NO, the Tool Config. ID field in the Product Code Definitions table is disabled.

When entering the run mode, if Tool Configurations are being enforced, the controller will test to see if the currently loaded Tool Config ID is loaded. The operator will be asked if the Tool Configuration should be loaded if the configuration does not match the one specified in the Product Code Definitions table.

The existing Enforce Configuration by PCode parameter relating to Setups was not renamed in order to preserve backwards compatibility with setups backed up by Eclipse.

Because a Closed Loop DA controller can be configured with an Open Loop printer that may be a Non-Stop or Feed-To-Stop based on the print driver selection the Bump Time and Bump Tolerance parameters need to be Active anytime an Open Loop Press is present but only visible if one of the Open Loop pressses are configured for Feed-To-Stop.

The method for testing these conditions incorrectly made the setups visible any time ANY press is Open Loop and ANY press is Feed-To-Stop rather than testing if any press is Open Loop AND Feed-To-Stop.

The XL has some debugging capabillities built in that utilize the DB9 serial port. This port is also used for barcode scanners. On powerup the XL tests the state of the CTS pin to detect if a PC or a Scanner is connected. When a PC is detected the controller has debug code that monitors the serial port for commands from the PC that will execute or enable debug code.

The input task was the task that was doing the monitoring. If the debug code took to long to execute it could cause the input task to miss petting the Watch dog for too long and the 0x000F0001 task error would occur.

This was fixed by moving the monitoring code to the Peg task (user interface) which a lower priority task than the Input task.

Allowing any tool to have a negative X-Offset allows the shear to allways have a zero offset. Although this is not a requirement it is an easier concept for users to understand. In addition it allows any tool X-Offset, including the shear to be adjusted with respect to all other tools.

It is important to know that the controllers part calculation and queueing code must not access the tool offset directly from a tool record. The tool offset must be accessed via GetTool or FindMaxOffset. These methods return the X-Offset relative to the shear tool so that the 'effective' shear X-Offset is allways zero. This ensures that scrap handling during queue initialization allways works correctly.

To facillitate internal testing of Eclipse with multiple XL windows simulations all on one PC, the ability to configure the port setting via a command line argument was added.

When debugging on one PC, all instances of the windows simulation use the Loop Back IP address. The ability to set the port is therefore required to distinguish between instances and allow each instance to establish their own socket connections with the Eclipse application.

Since this is for internal use, the convention is very rigid. The keyword "port" is used, followed immediately by the port number with no leading space.

If the command line argument is used, both the Debug Window and the Application window will have "port:nnnn", where n is the port number, appended to their title names.

When a task error occurs, the task error code is supposed to turn off all IO. It should report the Task Error, important registers and stack data to the screen as well as save it in battery backed RAM for later retrieval. If a debugger is attached, the information is reported to the debugger also. Unless there is a debugger, all tasks are shutdown and the controller waits for a reset event. If there is a debugger, the debugger task is allowed to continue running and the task that caused and reports the task error is forced into an infinite sleep loop, allowing the cause of the TE to be investigated through the debugger.

However, over the passed couple of years, attempts to fix minor issues with this feature have caused other issues.

The Task Error Reporting feature was resetting in the middle of reporting task errors. From the users perspective this would look like a blue screen, with maybe a few numbers on the screen, followed by a quick reset. If they were not watching the screen at the moment of reset it would appear as if the machine stopped running on its own with no explanation.

Three main changes were made to resolve the issue:

1. The Operating System watch dog is now being reset within the loop that writes out the Task Error Data. The loop was too long not to have the reset occur within it. Earlier versions of the code had this but it was inadvertently taken out somewhere along the way.
2. There is a watchdog interrupt on the input task. If the input task does not reset the watch dog, the interrupt fires and initiates a task error. While resetting the OS watch dog the TE code is now also resetting the input task Watch Dog, which prevents a second TE from occuring while trying to report the first one.
3. Interrupts now remain disabled until all of the TE data has been reported to the screen and saved to battery backed ram. This prevents any interrupts from modifying the data we want to preserve or more importantly, causing another Task Error. If a debugger is attached, interrupts are then enabled to allow the debug task to run and interact with the debugger.

In SERCOS phase 4, the behavior when the Fiber Optics Cables were removed was not consistent with the behavior of powing cycling a SERCOS drive. Both conditions effectively block communication with the drive so consistency is to be expected.

Disconnecting the fiber cables caused the XL controller to reset back to SERCOS Phase 0. Power cycling resulted in the controller remaining in phase 4 with no diagnostic information that anything was wrong.

On a power cycle, the SERCOS code was getting stuck in the PHASE4_C1D_ERROR state. Using the Flag that I added for Simple Sercos to detect a drive power cycle I was able to force the controller back to phase 0 so that it was consistent with a fiber break.

In both cases the controller will bring the drives back up to phase 4 once communication is re-established.

If Eclipse communication is enabled in the XL, every XL originated error or warning message is supposed to be logged via production records. There were reports of these production records having invalid data in them that would cause Eclipse or Express problems in parsing the message. This resulted in the controller going offline until the offending production record was manually deleted from the controller.

This problem was originaly reported in reference to the Error text provided by PLC error or operator messages. The code was trusting that PLC programmers would follow the spec. Careless programming could result in NULL, STX, ETX or dollarsign characters being in the production record in unexpected places.

Validation code was added to protect from careless programming. The XL code was also reviewed for other conditions that could result in unexpected data being logged in a production record. This resulted in additional changes.

The error text is validated and modified in the following manner.

1. PLC's are supposed to tell the XL the length of the string followed by the string characters. If they mistakenly use null terminated strings, the NULL character, if not removed, can cause issues with production record parsing. The location of any found NULL character is used to override the length of the string sent by the PLC.
2. Any character, besides a carriage return, having an ASCII value less than 0x20 (the space character) is replaced with a space character. This eliminates STX, ETX characters an other non-human readable characters. Carriage returns are left for formatting purposes.
3. Dollar signs are also replaced with spaces since the Eclipse protocol uses dollar signs as a field delimiter.

For some unkown reason the error text was being truncated at the first period encountered. This truncation was removed.

The production record was being generated after the operator cleared the on screen error. This was not a bug but it gave a false sense of event order in the production record log. It also contributed to the likelyhood of a different design choice becoming a bug that could have resulted in corrupted data. The production record is now generated imediately prior, effectively at the same time as, the error message being displayed on the screen

The error text from the PLC was being stored in static variables. A pointer to the static variable was being sent to the User Interface task. Multiple errors in rapid succession could have resulted in the error text being modified before or during the UI displaying the error and before or during the production record being created. The error text is now stored in dynamically allocated arrays that must be deleted by the UI task after they are no longer needed. This eliminates any race conditions the use of static memory variables allowed.

If a Setup Configuration was loaded and the controller imediately power-cycled, the setups within the Configuration would revert to their prior values. If any setup was modified prior to the power-cycle, the setups within the Configuration would then be locked in and a power-cycle would have no effect.

This bug has been present since the Setup Configuration feature was added. I think it has not been detected until now because things like Trim Correction would Mask the problem.

Setup Values are stored within a structure that is protected with a checksum so that corruption may be detected. There are two copies, each with a checksum, to ensure we always have a valid copy of setups if power is turned off in the middle of the calculation. When a setup is modified its value is written to copy 1, the copy 1 checksum is calculated and then the entire copy1 structure, including checksum, is copied into copy 2.

The issue was that when a configuration was loaded it was loading the setup values for Configuration Setups into copy 1 but it was not calculating the checksum. On a power-cycle the checksum error was detected and since copy 2 still had a valid checksum, the setups reverted to the values in copy 2.

There was a complaint about when a user pressed the F2-Add button while in the Order or Pattern Programming Screens. Nothing would happen if there was no Order or Pattern in their respective programming screen and the right side, grid side, of the screen had focus.

Under this condition the focus will now be switched to the left side, tree side, of the screen and a blank Order or Pattern will be created. This is the equivalent of the user pressing the F1-Next Window and then pressing the F2-Add buttons. We are just doing it for them.

In addition, when editing a Pattern Number on a pattern with no operations, the focus will be switched to the grid and an empty operation will be added. This imitates the same behavior that the Order Tree and Item Grid already exhibited when editing the last field within the Order control.

These are all edits intended to guide a newer operator along the path of editing Orders and Patterns if they are unfamiliar with how to navigate the screens.

The Coil Unload window pops up when a new coil is detected by the Tail Out input. The window title is "Unload Current Coil". It shows the coil number and footage of the coil we believe was unloaded, or used up, to make room for the new coil that was just detected. The window also has three buttons.

1. Return Coil to Inventory
2. Coil was Completed
3. Cancel

When you consider that the user just loaded a new coil and is now being presented with a window titled "Unload Current Coil", it may skew how they interpret the meaning of the three buttons. What we really want to know is what happened to the coil that was previously loaded prior to us detecting this new one. We believe the title of "Unload Current Coil" was leading new operators to mistakenly select the Cancel button. The Cancel button is intended for any situation where a coil was backed off of the Tail Out sensor and then rethreaded.

We have changed the window title to "Unload Previous Coil".

Also, the "Cancel" button text was changed to "Coil was NOT Unloaded".

We believe both of these changes will clarify the purpose of this window and help operators select the correct option.

When requesting a remake, the remake quantity was defaulting to the done quantity within the item. It was too easy for an operator to instinctively or accidentally hit OK without editing the quantity and remake a much larger amount than actually desired.

Based on customer request, the remake quantity now defaults to zero so that an operator is forced to enter in the quanty desired before anything will be remade.

The PLC Powerup Delay allows PLC's that take longer to powerup than the XL does to establish communication with the XL. The XL will wait this amount of time before trying to communicate with the PLC.

We discovered that the upper limit of 60 seconds was not long enough for some PLC's.

The Upper Limit of the PLC Powerup Delay setup parameter was increased from 60 seconds to 255 seconds.

Many of the MODBUS features are initiated or Handshaked by Setting and Clearing Coils(Bits) in the PLC.

In order to improve the troubleshooting capability when features are not working we have added Diagnostics to the XL to show the Coils(Bits), we call them Function Coils, as the XL sees them.

The diagnostics are accessed in the PLC Communications screen by pressing the F3-More Data key until the Screen data heading changes from "Configuration Data" to "Diagnistics. The coils are shown in 8 bit( 1 Byte) groupings. If bit 0 is ON within a group, the group will show a '0' for the first bit. Otherwise, it will show a '-' for the first bit. If bit 7 is ON the group will show '7' for the last bit. Each group has a heading showing the upper and lower coil number within the range. You can determine which coils are ON by adding the individual bit number to the lowest coil number shown in the group header. For example: If the group header is 15-8 and the group shows "-6----1-" then Function Coils 9 and 14 are ON.

In important detail to know about the screen is that it shows the state of the coils as read out of the PLC. If the XL turns on a coil that is imeadiately turned back off by the PLC, that coil will never show up in the screen as ON because it will get cleared before the XL can read it.

If enabled, the current value of the Remote Run Velocity Speed Pot is now shown in the PLC Communication Diagnostic Screen. If not Enabled, the value will show as "Disabled".

The part queue is a concept that causes frustration for some operators that have difficulty understanding the need for it, especially if they switch from a line that is shear only to one that is not or the line they have run for years is suddenly equipped with a printer. They don't understand why they can't instantly switch from one part to another with incurring scrap or having to wait for several "unwanted" parts to be produced.

Over the years, whenever possible, there have been special cases added where we have been able to make a line that has mutliple presses function as if it was Shear Only when it comes to the Queue. The most prevalent special case is when part printing is enabled but the printer is asynchronous.

A new special case is being added. If a controller that is configured with Gags or Multiple Presses has only one tool record, assumed to be the shear tool, the controller will manage the queue as if the controller is configured to be Shear Only.

A customer can then use Tool Configurations to automatically configure the line for Shear Only operation on a Product Code change or manually, any time they wish.

This feature is being added in response to a customer with a tube mill who has enabled the open loop press option to trigger a non-integrated printer. On products that don't require printing they can turn the controller back into Shear Only.

The V3 XL controllers executed Leap Year one year late. The V4 controllers executed Leap Year, effectively, two years late.

The cause is related to the Real Time clock chip in the hardware. The chip only stores two digits for the year and has a range 00-99. The software adds an offset to the year when reading the chip and subtracts an offset when writing to the chip. In an attempt to utilize the full date range of the chip the software was using an offset based on when the Real Time Clock driver was written. For V3 controllers a 2001 offset was being used. For V4 controllers a 2006 offset was being used. In order for the leap year function within the chip to work correctly the offset year needed to be a leap year.

The solution involved using 2000 for the offset in both cases. However, simply changing the offset would cause the customer issues in the same way that the Leap Day bug did. After an update the date stored in the chip would be interpreted as a date in the past.

The solution also includes attempting to detect controllers that have invalid dates stored in the clock chip. This is done by comparing the Year that XL200 Application was created to the year stored in the clock chip. The year stored in the clock chip should never be older than the application creation date.

V3 controllers that have invalid dates may have a year that is one year older than it should be. If the controller date year is less than the application creation year. The controllers date is updated to the year the application was created.

V4 controllers that have invalid dates will have dates that are 6 years older than it should be. If the controller date year is less than the application creation year, six years is added to the controller date.

In both V3 and V4 controllers, the Set Year setup parameter can no longer be programmed with a year that is older than the year the application was created. This prevents the controller from erroneously detecting an invalid date and trying to correct it.

The detection solution relies on the fact that we have regular releases. Usually new releases occur minimally every few months. If a customer updates to a release, with the bug fix, that is older than one year, we will not be able to detect if their controller has been affected by the leap year bug and we will be unable to automatically correct the date. In addition, if they update to a release that still has the leap year bug, they are re-infecting that controller with the bug.

The 0x8000012 task error is an indication that the DSP did not initialize correctly.

The 80386 processor must program the DSP after every power cycle or reset. This requires a lot of handshaking between the DSP and the 386 and also assumes that the DSP has been reset.

The 0x80000012 task error was added in an earlier change to detect cases where the DSP is not initialized correctly.

We have a customer that is complaining about these errors. The most likely cause is due to the DSP not getting reset correctly. Since we don't know the cause the following changes have been made.

The DSP is now being reset at the beginning of initialization. In addition, if we detect an initialization issue the DSP is reset and we try again. We will try three times before giving up and reporting the 0x80000012 task error.

Years ago we added the Shear Encoder Distance 2 parameter. The feature requires an Encoder Switcher to switch between two encoders based on a sensor at a known distance from the Shear, the Shear to Encoder Distance. This feature assumed that both Encoders and Encoder wheels were identical.

In practice no two encoder wheels are identical. At the time customers were happy with the scrap savings that the two encoder system provided but they are now experiencing some part quality issues due to the variation in the encoder wheels.

We have added a second Resolution parameter to allow the resolution of the second encoder to be different. The parameter defaults to zero. Setting it non-zero enables the second resolution, otherwise both encoders are assumed to be identical. It becomes visible when the second Shear Encoder Distance is enabled.

If the length passed the shear is less than minus Shear to Encoder Distance, Encoder counts are assumed to be coming from the second encoder. The ratio between the two resolutions is used to convert encoder counts assumed to be coming from the second encoder to counts equivalent to what the first encoder would produce.

This approach preserves the operation of all other features relying on the resolution of the first encoder.

Since Resolution 2 is used to convert Encoder Counts to Encoder 1 resolution it is not possible to calibrate Resolution 2 directly. The best way to calibrate the Resolution2 parameter is to force the Encoder splitter to use Encoder 2 and Run parts as if using Encoder 1. Save the initial correction factor and resolution for Encoder 1. Calibrate normally. After good parts are being produced, multiply the correction factor by the Encoder 1 resolution and save that value into Resolution 2. Restore the original Encoder 1 resolution and correction factor. Remove the wiring that is forcing the selection of Encoder 2.

!!!!Calibrate Trim cannot be used and does not correct Encoder 2.

!!!!Changing Resolution 2 will not change Length Passed the Shear like Changing Resolution does. This is because Resolution 2 is used to convert encoder counts from Encoder 2 into counts as if they came from Encoder 1, as they come in. Changing Resolution 2 will adjust how new encoder counts are treated not existing ones.

We have a potential customer who wants to program one line item for all of the parts they may produce in one day. They expect to produce about 17000 but we have traditionally limited the maximum Qty to 9999.

We would prefer to add one extra digit and allow values up to 99,999. However that would require changing the size of the variables used to store and manipulate Qty, Done and other internally used variables. This would be very risky due to the likelyhood of missing the size change on temporary variables or one of the arguments or return values for functions and methods used to manipulate and use these fields.

We can very safely allow the maximum Qty to go up to 32767 which is the maximum value that can be stored in the 16bit signed integers that are used today.

The UART version is being bumped to 3.44 to allow Eclipse to know if it can use the larger upper limit.

Changes were made to Increase Qty, Remake and Decrement Qty to handle the larger upper limit on Qty.

When a coil tails out on an Open Loop controller, the encoder count is supposed to be reset to zero. When the new coil is loaded the controller resets the encoder count to minus the Shear to Encoder Distance.

This was an intermittent issue related to DSP communication. The Tail Out told the DSP to set the encoder count to zero and then executed code to Unload the Queue. The Unload Queue code executed code that told the DSP to Decrement the encoder count. The DSP timer did not run until after the Decrement was requested. The Decrement request overwrote the Set request which resulted in a bad encoder count value.

This bug is purely a display issue. No material gets miss-reported. Everything gets resolved when the next Coil is threaded.

Planning for future development that is common between Open and Closed Loop projects 16 more DIP switches were added to the configuration screen.

There were no more free DIP switches that the Open and Closed Loop projects had in common so 16 new ones were added.

Queue initialization was restructured when the SCN 2726 New XL200 Scrap Part Mode Setup Parameter was added. When the punch queue is being initialized, the controller is supposed to ignore/remove all negative punch targets when the Scrap Part Length is Zero and Scrap Part Mode is set to Default. This was not being done on controllers configured with only one press.

An additional Line Encoder port was added in order to eliminate the use of an Encoder Switcher and Dual sensors when two line encoders are used for scrap savings on coil threadup and tailout.

DIP switch 17 enables the second line encoder. Open Loop controllers will use port 2 for the second line encoder. Closed Loop controllers will support this feature with port 3.

At this time, only Closed Loop Die Accelerators support this feature. Single Encoder Feed to Stop will never support it. Two Encoder Feed to Stop will support it in a later SCN.

Only Version 4 controllers have the available DIP switch and encoder port. Much of the source modified for this change is shared between the Version 4 and 3 controllers so they are included on the change.

To support Trim Correction of the second encoder, two new setups were added. Trim Correction Encoder and Correction Factor 2. Trim Correction Encoder has two settings, Exit(1) and Entry(2). This setting indicates which encoder was used to produce the Last Measured Length part.

When two line encoders are enabled, only one sensor is required to handle threadup and tailout. When the tail out input comes on, the coil does not actually tail out until some distance later. When the tailout input turns on, the location of the trailing edge of the material is captured and when the trailing edge travels far enough, the controller then tails out. The controller internally switches from the Entry(2) encoder to the Exit(1) encoder on thread up or tail out based on a new setup called Main Encoder.

The new setup Main Encoder has two settings, Exit(1) or Entry(2). It defaults to Exit(1). When set to Exit(1), the controller switches to the Exit(1) encoder during threadup. When set to Entry(2), the controller switches to the Exit(1) encoder when the tail out input turns on. Several new setups were added to support threadup and tailout.

Shear Tail Out Distance is the distance from the shear where the material is considered to have tailed out. This distance should be longer than the shear to encoder distance so the controller tails out while still in contact with the Exit(1) encoder. Many times a rollformer is not able to drive the material beyond the Exit(1) encoder. In this case a slightly longer distance, measured from the shear, where the material stops, should be entered. While running or jogging forward, the run status will display TAILING while the material is moving to the Shear Tail Out Distance.

Shear Encoder Switchover Distance is the distance from the shear where the controller will switch from the Entry(2) encoder to the Exit(1) encoder when the Main Encoder setting is set to Exit(1). This distance should be shorter, as measured from the shear than the shear to encoder distance. This parameter replaces the Shear to Encoder distance parameter. A value smaller than the distance between the shear and Exit(1) encoder should be entered.

Additional effects of the Main Encoder Setting. The encoder that is not selected is considered the Auxiliary encoder. The controller calculates encoder targets and other internal variables based on the resolution of the Main Encoder. When using the Auxiliary encoder, the Auxiliary encoder counts are converted to counts as if the controller were running on the Main Encoder so that the rest of the software is unaware that the Auxiliary Encoder even exists.

As part are being run, the controller keeps track of the Last Programmed Length and also which Encoder was last used to produce a part. This information is used to prepopulate the Last Programmed Length and Trim Correction Encoder settings.

It is best practice to only perform a Trim Correction on parts that have been run using the Main Encoder. The ratio of encoder counts between the Exit(1) and Entry(2) encoders is expected to be relatively constant once it is known. Using this knowledge a trim correction of the Main Encoder is also able to trim correct the Auxiliary encoder at the same time.

The controller uses two methods to determine the ratio between the two encoders.

1. When the encoder resolutions are hand entered. The ratio between the two resolutions is used.
2. While running, the controller monitors both encoders and calculates a filtered ratio of encoder counts between the two encoders based on the number of encoder counts coming in on each port.

Because the machine will operate on the Main Encoder most of the time and operators typically Trim Correct periodically, the Main Encoder effective resolution is expected to be accurate.

A new setup called Auto Correct Auxiliary Encoder has two settings, Enable and Disable. When Enabled, the controller uses the filtered encoder count ratio and corrected resolution for the Main Encoder to automatically correct the resolution for the Auxiliary encoder.

A Trim Correction on the Main Encoder preserves the ratio between the two encoder resolutions. A Trim Correction on the Auxiliary Encoder establishes a new ratio. In other words, A Trim Correction on the Main Encoder also corrects the Auxiliary Encoder. A trim correction on the Axillary Encoder, only corrects the Auxiliary Encoder. However, when Trim Correcting the Auxiliary Encoder, two wrongs can make a right.

Best practice is to leave the Auto Correct Auxiliary Encoder Enabled and only Trim Correct the Main Encoder. Following these practices should result in an accurate resolution for the Auxiliary Encoder on all but its initial use.

If Auto Correct Auxiliary Encoder is Disabled, best practice is to Trim Correct the Main Encoder prior to Trim Correcting the Auxiliary Encoder.

For machines that use a front shear to cut blanks or have an alternate shear where the Entry(2) encoder is temporarily not used during threadup or tailout, a new setup called Tail Out Configuration was added. It has two settings, Single and Double. It defaults to Double, meaning both encoders are involved in threadup or tailout. When set to Single, only the Main Encoder is used for threadup and tailout. The controller will tailout immediately when set to Single. Also, when set to Single, the Auto Correct Auxiliary Encoder setting is effectively Disabled.

The ability to select between Encoder Ports was also added via an Extended MODBUS input, input 45.

Trying to implement two resolutions using a single encoder port and an external encoder switcher proved to be too difficult to configure. Correcting for encoder tracking was very unfriendly and caused much confusion.

This option is being removed and is being replaced by the changes described in SCN 2935 - Addition of Dual Line Encoders.

This means that any customer using a version 3 controller that wants dual resolutions for their line encoder must upgrade to a version 4 controller.

The XL requires scrap codes on Manual Shears when Scrap Codes are enabled and the length of the Manually Sheared material is longer than the Manual Shear Scrap Length.

One customer discovered that when two manual shears are executed in succession, one Manual Shear production record had the Scrap reported and the next production record had no Scrap but it did have a scrap code.

A code review revealed that on the first manual shear, the controller detected that a scrap code was required, zeroed the length past the shear, asked for the scrap code and delayed reporting the manual shear until the scrap code was entered. The second manual shear had no material past the shear so it executed a manual shear and reported the manual shear, which also reported the footage. When the operator later entered a scrap code, a manual shear was reported but the footage was zero because it had already been reported in the earlier production record that had no scrap code.

There was technically two bugs here:

1. The actual history of events was not being accurately reported. The time when the Manual shears actually took place was actually being distorted by delaying the production record.
2. The Scrap was being reported separated from the scrap code instead of together.

Both bugs have been fixed by preventing the manual shear from occurring until the Scrap Code is entered. This is consistent with preventing the line from entering the run mode until a delay code is entered.

Controllers with SERCOS and issues reaching phase4 due to improperly configured cable lengths, faulty fiber optic cables were most susceptible to the 0x8F000012 task error. This task error is generated if an IRQ 7 interrupt is generated when not expected.

IRQ7 is the receive interrupt that is generated by the DSP to indicate it has response data ready.

This bug could readily be duplicated by tying the receive and transmit SERCOS ports together with a single fiber optic cable.

The problem was caused by a bug in the controllers Operating System API functions for installing, enabling and disabling interrupt vectors. These functions were allowing interrupts to occur during the function.

Additional restructuring of when Interrupt Vectors were enabled and disabled was done in the SERCOS task.

Prior to this change the user was NOT asked what happened to the previous coil until the next coil was threaded. This does not tend to matter unless you have Eclipse and Eclipse is keying off of the Unload production record to do something important like printing a new coil tag. The delay in the production record generation delays the generation of the coil tag.

The XL will now ask what happened to the previous coil when the coil tails out. If the operator answers promptly, the delay of the new coil tag is eliminated.

This also impacts the Decrement Qty screen since it asks which coil the dec qty parts were produced from. The screen used to default to the currently loaded coil which now may no longer be loaded. It now displays the last loaded coil, The last loaded coil becomes and also is the currently loaded coil when a new coil is loaded.

The "Set Next" function has been added to the list of XL Controller functions that can be disabled by Eclipse.

SCN 2274 allowed Eclipse to disable certain Order and Pattern modification features.

When SCN 2274 was implemented, no ability to override the Disable was added. Some features like "Set Next" or "Remake" are essential for expeditiously recovering from expected production events like parts that get damaged or don't meet quality expectations.

The ability for the Disable to be overridden at the controller by a manager that has a Setup Lockout Key has now been added. Each of the features that can be disabled are also capable of selectively being able to be overridden by the Setup Lockout.

The override capability is configured within Eclipse.

The "F3-Skip/Ready" function can be disabled by Eclipse.

The initial release of Dual Line Encoder capability calculated the ratio and Auto Corrected the Auxilliary Encoder Resolution backwards. For example, if the Auxilliary Encoder is reading half the encoder counts as the Main Encoder, over the same distance, the Auxilliary resolution should be corrected to double the resolution as the Main Encoder.

In the example above, the controller was incorrectly coming up with an Auxilliary Resolution that was half of the Main Encoder resolution

Years ago when we ran out of space in the V2 XL200 code we disabled all of the QC100L and related code with a Compile Time Switch. Work is being completed on a new version and this code needed to be enabled in a test build. Some of the code no longer compiled or caused compiler warnings so all of these issues were fixed. None of the edits should impact production code.

SCN 2696 provided the ability to completely delete an order, even if it was an order that had items in the queue.

The limitation was that the recall had to happen when the controller was halted. This resulted in Eclipse halting the line for every order recall.

The OD1 command has been modified to only require halting the line if the order is in the Queue. Even if the line is running, if the order is not in the queue, the XL will now delete the order rather than reporting that it is running.

In order to do this the UART task has to temprorarily raise its priority to prevent the run task from adding new items to the queue while the queue is being tested. In attempt to minimize how long the UART task is searching, a newer, more bounded search method was added to limit the amount of records that are searched.

When Eclipse communication was configured for Eclipse it was possible for the XL to get into a state where the Eclipse task got stuck in an infinite loop, using up all of the CPU time. When all of the CPU time is used up, the Operating System detects the condition and throws the 800004FF task error.

The Eclipe task was modified to fix and exit this state on a power cycle and during normal operation.

Prior to SCN-2947, the Unload Coil Screen was displayed on Tail-In when the next coil was threaded. Any manual shear that occurred after a tail-out was tracked against the coil that just tailed out. When Eclipse is enabled, a Coil is required to allow manual shears.

Now that the Unload Coil screen is presented on tail-out, if the operator answers the question indicating they no longer have a coil loaded they are not allowed to do a manual shear until they thread the next one up and enter the coil number in. This prevents them from using the shear to make a good part out of the remaining scrap.

To counteract this new limitation the software has been modified to allow a manual shear against the previously loaded coil up until a new coil is detected by the sheet detect switch. They are then prevented from doing a manual shear until they enter a coil number into the load coil screen.

After a tailout it is common to do a manual shear to cut the tail end of the coil into recoverable pieces. These manual shears should not report the accumulation of any new material. This change prevents prevents that.

If no sheet is detected, a Manual Shear will not add material to the scrap accumulator. Ultimately this means that any encoder movement while material is tailed out will not be counted as actual material used.

The Changes made in SCN 2947 to display the Unload Coil Screen on Tail-Out and the Load Coil Screen on Tail-In prevented the F2-Load Coil button in the production screen from being able to enter a coil. The F2-Load Coil button is now active all of the time again.

It is common for an operator to un-thread the coil to clear a Jam and then re-thread the same coil. As a convenience, the Unload Coil window has a "Coil was NOT Unloaded" button to handle this occurrence. This allows the operator to continue on without having to look up and re-enter the coil number.

The screen has been changed to prevent the operator from selecting the "Coil was NOT Unloaded" button until a coil is sensed by the Tail-Out input. If the Tail-Out input is ON the only appropriate responses are "Return Coil to Inventory" or "Coil was Completed".

There is an exception to this rule that should rarely come into play due to the unlikely nature of the situation to occur. After a tail-out, if a coil number gets entered with a barcode macro or the production screen and an operator then mistakenly tries to enter a new coil or delete the current one, they are given the opportunity to change their mind and select "Coil was NOT Unloaded" regardless of the Tail-Out state.

SCN 3007 Forces the coil number to be unloaded via prompt selection on a tail-out. We do not expect a coil number to be loaded on tail-in unless the operator has entered it via the GUI or via barcode macro. When encountered, the most likely scenario is that they intended this to be the next coil and it would be annoying and possibly error prone to prompt again. For this reason a Tail-In is ignored when a coil number has already been entered.

All of the triggers based off of changes in the current item, like Order Change, Item Change, PCode change ... etc Trigger prior to any production occuring on the next item or order. Setting the trigger to prevent run, in order to force the data entry, prevented the item they wanted measured, to be ran.

Several customers have asked to be able to Halt the line after the first piece of an Order, PCode change, Material Change ... etc. This will allow them to force an operator to measure and report characteristics of the first part produced, where as the currently the Trigger occurs and the line halts on the last part.

With the Exception of the Time Based, Part Based and Footage Based Triggers, all triggers now have a Part delay that defaults to zero for current operation. If set to a non-zero value, the trigger be delayed by the specified number of parts.

If a customer wants the last part of a PCode run measured they can configure the trigger delay to zero parts and the halt after to zero parts. If the customer wants the first part of a PCode run to be measured they can configure the trigger delay to 1 part and the halt after to zero parts.

The allowed field size for coil numbers in the XL200 controller has increased from 16 to 30. To utilize the full character size requires a corresponding update to Eclipse.

Adding safeguards to use an new controller with an old Eclipse and prevent data entry errors could prove to be annoying and also not be bullet proof. We are expecting that users who obtain this update and are using an Eclipse that does not support the extra characters will continue to use their existing data entry practices. We also consider the likely hood of an existing user entering more characters than an old Eclipse can handle to be very slim.

Eclipse has the ability to disable most, if not all, of the Order and Pattern modification features. An additional feature has been added to this configuration to further improve the elimination of invalid material usage.

When configured, jogging material forward and manual shears are prevented under the following conditions when material is detected in the machine:

1. If no coil is loaded as the current coil.
2. The coil is invalid for the current order.
3. There are no incomplete orders.

The purpose of these limitations are to force coil validation sooner to prevent completely threading an entire roll former full of material that is invalid for the current order. A sheet detect sensor should be installed as close to the beginning of the roll former as possible.

In addition, it can be used to prevent theft during off hours. Assuming user data entry of orders is also prevented, recalling all of the orders will prevent an unscrupulous operator from jogging material through the machine and manually cutting it off.

In addition, it can be used to prevent theft during off hours. Assuming user data entry of orders is also prevented, recalling all of the orders will prevent an unscrupulous operator from jogging material through the machine and manually cutting it off.

The XL will now generate a new production record, Type 2, Reason V, to request a coil validation of the current coil. This production record will be generated anytime the controller detects that the coil is not valid for the current order. However, it will only create the production record if the version of eclipse it is speaking with can support it.

After Tool Configuration edits, the XL code was not clearing the Tool Configuration chain status bit to indicate that the chain needed backed up.

This change also requires a corresponding Eclipse release as Eclipse was not backing up or restoring this chain until now.

The legacy functionality of the XL100 and XL200 was that the first coil in the controllers coil inventory was the Current Coil. Now that we have changed when the operator is prompted to deal with Tail-outs to the Tail-Out event rather than the Tail-In event, this legacy code is causing confusion.

The customer who complained, for some reason, unloads the machine every night at end of shift. They are prompted what happened to the coil and many times, it stands to reason, they will say return to inventory. It also stands to reason that they may load the same coil again in the morning.

When the coil tails out and the operator selects to return the coil to inventory, there will be at least one coil in the XL's inventory. Then the coil load prompt is displayed. If the operator selects cancel, the controller is then setting the current coil to the first coil in inventory, which may very well be the coil they indicated that they unloaded. Then in the morning, when a coil tails in, they are asked again what to do with a coil they already indicated that they unloaded, which could also be the coil they are loading again. Not confusing at all(sarcasm added).

To eliminate this confusion the software will no longer automatically set any coil to the current coil. The user will always need to explicitly tell the controller when a coil is the current coil.

A Tail-out was inconsistent about prompting for a new coil. If the previous coil was returned to inventory it would prompt. If the coil was completely used it would not prompt.

The software has been modified to never prompt for a New Coil on Tail-Out, unless a coil has tailed back in prior to the operator processing the Unload Current Coil prompt.