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.

We have a customer who cuts material off of their coils with the front shear prior to threading them into the machine. Because the controller has no knowledge of the coil, they are currently using a paper system to track that material. However, they want Eclipse to track it. They asked for a system where the controller would request the operator enter in the part length and number of parts after the new coil had been identified.

Here is what we did:

While the coil is Tailed Out we will count Manual Front Shear operations. When the coil is identified, if the number of Manual Front Shear operations is non-zero, we will display a screen that asks them what happend. It has three data entry fields, Number of Equal Length Cuts, Length of Equal Cuts and Sum of Additional Cuts.

The Number of Equal Length Cuts field is pre-populated with the number of detected Manual Front Shear operations. If they need to adjust the Number of Equal Length Cuts they have that capability.

If they are in the habit of making a number of equal length parts they can enter that length into the Length of Equal Cuts field and we will calculate and display a sub total by multiplying the number of parts by the length.

If instead, or in addition to, they have made other non-equal length parts they can enter the sum total of those parts into the Sum of Additional Cuts field. The sub-total of equal length cuts and the Sum of Additional Cuts are added together and displayed as the Total Sum of All Cuts.

When they have entered everything they can press the Done button on the screen and the controller will add the Total Sum of All Cuts to the scrap accumulator for the coil, in addition to all of the other scrap accumulators. A Manual Shear production record is also generated to report the material to Eclipse. The number of Manual Front Shear operations is then zeroed out to restart the process for the next Tail Out.

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.