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.

There is a customer who is having an issue with MODBUS Expanded gags. In order to isolate where the problem is we need to add some method of displaying the state of Expanded Gags as the controller understands them.

The most expedient method of doing this is to optionally add them to the Press Information Diagnostic Window when enabled. The screen displays the range ie. 19-12 as a header for each 8 bit/gag group. As an indicator for each group the controller represents a bit/gag that is ON as a number 8-1 with the least significant bit/gag represented as a 1. Any bit/gag that is OFF is represented by a dash.

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.

This change affects any of the XL VideoJet drivers that use the ESI command interface. Currently those printers are:

1. 170I
2. 178I
3. Excel 1510
4. Excel 1520
5. Excel 2000
6. Excel 273

Prior to this change these printers only supported the 3 of 9 barcode font. They now support EAN8, EAN13, EAN8 with Human Readable Txt and EAN13 with Human Readable Txt.

Eclipse needs to be modified to allow selection of these fonts. The following characters are used in the driver to select these fonts:

1. EAN13 'F'
2. EAN13 with HRT 'f'
3. EAN8 'G'
4. EAN8 with HRT 'g'

In order to use these new fonts, the Eclipse print message must be configured to Select the font rather than using the printers default. The print message must also specify either 16x24 or 10x16 in the Barcode/Logo Font selection.

We do not have a printer to test these changes with but they are straight forward assuming the original barcode 3 of 9 selection worked correcty.