A CLF with Multiple Presses on one die, Stitching Parts by omitting shears, Phantom shears, are all scenarious where a press gets disabled. It is prevented at a low level from firing.

A customer with an XL202CLF with two presses on one die reported that they had internittent issues with the Shear press not firing on a Manual Shear. After a deep code review, since we were not able to duplicate it, the following theory was formed.

Under some conditions, the run code is likely disabling the shear press. It enables or disables it when it processed each target. There are most likely conditions where the controller exitt the run mode with the press disabled. The Manual Shear Code is expecting the press to be enabled all the time.

The fix, in case this theory is correct is to enable the selected press during any Manual Shear or Press operation.

The display in the Windows simulation was not updating durring the Toggle input R command. This command is used to simulate the toggling of a home sensor.

The issue was the Toggle R and all other windows simulation commands were executing in the PEG graphics task, which updates the display. While executing the Toggle R command, the PEG task could not also update the display.

Now the commands will execute in their own task, which will allow the display to update during any lengthy command like the Toggle R command.

There were several tasks in the windows simulation that were not identified with catalogs.

A customer is complaining about a 0x81000003 task error. The error is being generated while building the response back to the Office PC. The string has gotten too large despite having a check for size just prior to when the error occurs. There appears to be memory corruption or a timing problem with shared memory involved.

While troubleshooting, it was noticed that the task errors seemed to occur only during periods of time when the entire Eclipse network of machines were experiencing high rates of communication failures, indicating a network wide issue. It is believed that this network issue sets up the environment when this occurs.

The buffer for parsing a command and then building the response is a shared buffer. When the RS485 network is used, the buffer is protected by disabling the RX interrupt while building the response. There is no such protection with Ethernet which, in theory, may be the source of these task errors. The theory is that the network issues setup the environment where a new command can come in and corrupt the response as it is being built. The new command is written to the buffer in an interrupt.

To eliminate this as a possible cause, the following changes are being made. The interrupt will save the command in a temporary buffer. The UART task will copy this temporary buffer to its processing buffer so that if a new command comes in, it will no longer be able to corrupt the response. The new command will be copied and processed only when the UART task is ready for it.

Some additional changes were made to minimize the damages if the UART Tasks buffer corruption is still somehow occurring after adding the temporary buffer. Rather than using copy string functions, the buffer copying code has been modified to use sub string functions that will only copy as much memory as the target string buffer can hold.

Edits to the QTY on a DONE item were being converted to Remake (Scrap) parts, with no scrap code. This makes no sense. Edits to a partially complete item don't do the same thing, which makes this behavior even more surprising and confusing. In addition, we have a remake function that will explicity do this, and prompt for a scrap code to boot. If the user wants these extra parts to be remake parts, they can use the remake function.

Edits to a DONE order will now clear the scrap qty and the scrap code in the item.

SCN 5059 already attempted to resolve this issue but a source code cut and paste error meant the fix was not actually implemented and the fix actually was potentially corrupting some memory.

The code was using BuildPart1.BPressID rather than BuildPart.BPressID to enable the press. BuildPart1.BPressID could have been any one of 255 possible values rather than for the actual press that neede to be enabled.

Using the keypad there was no way to cancel an Increment Qty other than canceling all Increment Qty with the CE key.

The F5-Dec Qty key can now be used to undo a single Increment Qty part.

We have a customer who doesn't believe the controller is testing for the Y-Axis to be in position and stopped before firing the press. They have Local SERCOS Y-Axis drives that do the positioning. There is a position tolerance and a stopped tolerance. It is possible that the stopped tolerance or position tolerance could be faulty.

We have added debug prints in the test when it is determined that it is OK to fire. We are printing the Position and Velocity tolerance for each SERCOS Y-Axis. In the tolerance printount we are printing the current line position, the cmd Y-Axis position, the actual Y-Axis Position and the Current Y-Axis velocity.

If we don't get the debug prints, we know it isn't testing. If we get the debug prints, we will know if it is testing for each press fire and, with some backwards calculateing, we will know if the correct Y-Axis position has been commanded and the presses fired at the correct X-Position.

We ran into an issue on a customer install. We were incorrectly informed that Diax02 drives support the Drive Internal Interpolation mode that we have historically used on multi-Axis installs. It turns out this is incorrect.

Rather than relying on the Drive to calculate the Position Profile Setpoints for an axis move, we had to add the capability for the controller to generate them.

These are 30-year-old drives, SERCOS is also an obsolete technology. The customer’s line is down, and they have several more lines with these same drives. With all these things in mind, some compromises were made to speed up the implementation.

The setpoint generation requires our operating system to be in sync with the SERCOS Bus. We already do this by using the SERCOS chip to run our OS on SERCOS Closed Loop Controllers. For this and the previously stated issues, this support is only available on the Closed Loop models with the SERCOS option.

A new Driver Type called "Local SERCOS Diax02" has been added.

A new Check box in the SERCOS Settings window "Diax02 Operation" is available on the Closed Loop controller with the SERCOS option. When this box is checked all SERCOS drives will be configured in operation modes known to work on Diax02 drives. For Multi-Axis drives, the Local SERCOS Diax02 driver type must be used. . The Local SERCOS Diax02 drive can be used on a more modern drive Diax03 or higher as it still uses settings and operating modes that are available in those drives.

Only SERCOS drives with the appropriate drive type will be visible in Diagnostics. A Run Mode entry test will display an error if the wrong type has been selected.

Other than the Driver Type, the only visible difference between a "Local SERCOS" and a "Local SERCOS Diax02" driver will be the Diax02 type will have an Acceleration parameter that is required in order to generate the motion profile.

The Diax02 version does not support S-Curves. Those were provided by the Drive Internally when it generated the motion profile.

A bug was found in the Diax02 drives we had available to test with. The Velocity parameters were found to only work reliably in the drives when configured for RPM. We chose to use Preferred scaling, where the drive chooses its own prefereed scaling.

Velocity drives, for Feeders and Die Accelerators still operate in the Velocity mode they have always used. Velocity will be in RPM so drive scaling will require some new math to RPM instead of Inches/minute.

Multi-Axis drives now operate in Position Mode where we have to send a postion setpoint on each drive sample. The XL is generating the motion profile with these setpoints.

Additional help for configuring these drives can be found in the Support One-Note.

If there were more than 1 SERCOS drive, sometimes clearing an error using the F3-Clear Error function key did not work.

This has been resolved.

The controller default part print message has a rotation of 270 degrees. The Keyence Print driver only prints one character of the default part print message. The single character that does print, prints horizontally instead of vertically. Because the message gets rotated by 270 degrees, the rest of the message is hidden in the screen and does not print on the part..

It is too late to change the default message for the driver. This will break existing customers installs that may use the default message. It is also too late to completely adjust the driver’s interpretation of the rotation property so that the default message prints properly. Again, any general adjustment will impact existing customers of the printer.

A new setup has been added that is enabled when the Keyence Part Print drivers are selected. It is called Adjust Part Print Rotation. The parameter has two options, 0 and 90. It defaults to 0 degrees for legacy reasons. When set to 90, it will add 90 degrees to the rotation found within in any print message definition. This effectively converts 270 degrees back to zero. All the other rotation options are shifted by the same amount.

In the future we will be creating a Software Licensing feature that allows a controller to be sold without functioning software. The Software will be sold seperately and licensed. The license will contain and select the Model that the controller is supposed to function as.

A new model has been created for controllers that have not had a software license enabled. This Model will be be selected by the software when a software license has not yet been enabled in the software.

The new model will be functional enough to be configured to communicate with Eclipse, which can provide the license in the future. In the future it will also provide the ability to configure the license manually.

Starting from a functionally controller the following changes have been made to create this model.

Disable all inputs to the controller so that it cannot function. No presses or motion configuration is defined.

The XL2OL controllers will have XL200-Unlicensed as their Model. The XL2CL will have XL200CL-Unlicensed as their Model. The XL220 will have XL220-Unlicensed as its Model. The XL220CL will have XL220CL-Unlicansed as its Model.

There is currently no way to configure a controller as Unlicensed. That will come in a future SCN.