Simple does not mean easy to use. It means that it uses a reduced(simplified) set of parameters.

On Closed Loop Models with the O(SERCOS) option, the SERCOS configuration screen now has a Simple SERCOS check box. When checked, any Die Accelerator or Feeder drive will only be interfaced using the Following parameters: Class, Ident, Name B S-0-0001 Tncyc A S-0-0002 Tscyc
A S-0-0003 T1min A S-0-0004 Tatmt B S-0-0005 T5 A S-0-0006 T1 A S-0-0009 Start address of master data telegr. A S-0-0010 Length master data telegr. A S-0-0011 Diagnostics Class 1 A S-0-0015 Telegram mode definition A S-0-0032 Main operation mode B-Vel S-0-0036 Velocity Command B-Pos S-0-0051 Position feedback 1 value
C S-0-0076 Position Data Scaling Type A S-0-0087 for slave more drives load Tatat A S-0-0088 Tmtsy A S-0-0089 T2 B S-0-0090 Tmgsg B-Vel S-0-0091 Bipolar velocity limit
A S-0-0095 Diagnostic Text A S-0-0096 Slave ident ? S-0-0103 Position Modulo Value

In addition the drive must support telegram type 3

S-0-0091 Bipolar Velocity Limit is still used to scale the maximum velocity.

The drive will be configured for ratational position units. It is up to the user to determine/calculate/convert the drives S-0-0051 Position Feedback Parameter to Die Resolution. S-0-0076 can be used to assist in this. Depending on how the drive is configured, the user will have to use drive documentation, gear box ratios, actuator pitch, belt gear tooth count...etc to calculate the Die Resolution. It MAY have an S-0-0079 Rotational Position Resolution parameter. Position feedback will be relative to the load. You configure how many counts per one revolution in S-0-0079. Once you have done this then you can calculate the die resolution as distance the die travels in one revolution divided by S-0-0079. For rotational style Dies, S-0-0079 and Max Die Count should be equal.

A new record chain for SERCOS parameters was added. This chain is provided for each velocity configured drive. Rockwell Drives don't remember their settings after a power cycle. Any settings that need to be changed from their default must be added to this new chain so that they can be configured in phase two as part of the drive run-up. This chain has the capability of being backed up by Eclipse. The chain can be found and edited in the diagnostic window as a sub-menu of the SERCOS menu.

Since Rockwell devices will be configured as Simple SERCOS drives and they lose their configuration/parameters on a power cycle we need to add a layer of protection. An unconfigured drive can damage equipment, mame or kill personel. Because of this concern, each Simple SERCOS drive will have an Configuration Status that defaults to "NOT Configured". It will default to this state after every memory clear. If the setup lockout key is OFF, the user may change the state to "Test Mode" or "Configured" for each Simple Axis. "Test Mode" prevents an Axis to be used in the RUN mode. It is expected that the user will have motor disconnected while in "Test Mode". SERCOS Parameters may only be edited, added or deleted from the Settings Chain when NOT in "Configured" state. Any attempt to enable the motor when not in "Configured" state will result in an error message indicating the motor is not configured. If the state is "NOT Configured" an additional popup will display, warning the user of the dangers, and will allow the user to place the state in "Test Mode".

While testing this change on Rockwell drives I found that I had to set/override the S-0-0079, S-0-0100, S-0-0-0101 and S-0-0091 parameters. S-0-100 is Velocity Proportional Gain. S-0-0101 is Velocity Integral Time. S-0-0091 is Bipolar Velocity Limit.

Modifying any SERCOS Setting or the Configuration State is prevented when the Setup Lockout is ON.

CRC Parameter Protection: A CRC is calculated when the user places a drive in the "Configured" state. Every time settings are sent to a drive, the CRC is tested to ensure a setting has not gotten lost or corrupted. If the CRC does not match, the Configuration Status for that drive is set to "NOT Configured". Eclipse backs up the Settings, CRC and Configured state on request from the user.

On a memory clear, Eclipse will send the backed up Settings, CRC and Configured State back to the controller. As long as the backed up Configuration State was "Configured" and the CRC matches the downloaded Settings, the drive Configuration state will be restored to "Configured".

When settings are downloaded from Eclipse, the settings will be sent down to the drive(s) the next time run mode is IDLE.

During testing with a Kinetix 6000 drive we discoved that it wants to do the phase runup twice or it gos nuts when it is enabled. When Simple SERCOS is enabled the controller will do phase runup twice after an XL power cycle or a break in the fiber is detected (power cycle of the drives).

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.

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.

Two extra gags are allowed on the XL244CL. DIP switch 14 enables them. No more than one OL press may be defined. If DIP 14 is ON DIP 8 mut be ON as well. This option is only available on Version 4 controllers.

Based on a customer request, Auto Crop is now enabled on Continuous Press Controllers.

A new Setup called "Enable Auto Crop" was added. It defaults to NO. When set to YES the Auto Crop Length parameter becomes visible and the Auto Crop feature becomes enabled. The parameter is locked with the Setup Lockout input.

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.

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.

The MODBUS spec now allows a PLC to remotely control and inform the XL of the Press Speed for a Continuous Press Controller. The MODBUS Communication spec describes how in version level 114.

On SERCOS controllers, the change in encoder count is sent to the DSP from the 80386. The 80386 reads the position from the SERCOS ring and converts that data to encoder counts. On other controllers, the encoders are hardwired the controller and DSP reads the encoder count via specialized encoder chips.

The 80386 to DSP communication on the DSP side is done via DMA. The data is sent one 16bit word at a time. The change in encoder count is sent to the DSP as a 32bit double word value.

The Rev C hardware has one input, 24, that has an interrupt tied to it. The Rev D hardware has three inputs that have interrupts tied to them. We use these inputs for hole detect controllers to capture the encoder count on an interrupt when the input turns on or off. These hole count interrupts are active all of the time. The controller simply ignores the information if it has no use for it.

The hole count interrupt was using the SERCOS encoder count change directly when it read the encoder count and then cleared the SERCOS encoder count change to avoid counting it more than once. However, this opened up the possibility that it could get cleared in the middle of the DMA transfer. If the change was a small negative number, clearing the least significant word caused the value to become a large negative number equivelent. For example 0xFFFFFF(-1) becomes 0xFFFF0000(-65536)

When the loop tries to correct such a large error it results in the analog maxing out. This is reported as a Drive Not Responding error.

This error was much more likely to occur on a Continuous press controller that uses input 22 (Feed OK) rather heavily. Input 22 is one of thre inputs that has an interrupt tied to it.

The Closed Loop Data Screen has always required the controller to enter the run mode and attempt a shear pior to any data being captured.

At times it has been desireable to begin capturing data right away or to capture the data prior to some sort of drive fault that may occur infrequently.

In the capture menu two new options have been added.

Immediate: This begins capturing 32 seconds of data imediately. This allows a user to start the capture and capture during a die reference or while jogging the motor.

= Fault: This option captures data forever as long as the drive enable is ON. As long as the enable is still ON, at the end of 32 seconds the data capture will begin again. This is usefull if there is a drive fault that occurs infrequently.

There is obvious room for improvement in these features but they were implemented as is while troubleshooting a problem. There are other higher priority issues to work on at this time now that their initial use has been fulfilled. There is no reason to wait for them to be perfect before providing them for others to use.

Via MODBUS, a PLC can now control which encoder the controller closes the loop around. This is only relevant when the XL is configured for two encoder feed to stop operation.

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.

Assuming the controller has been configured correctly and the machine does not have mechanical issues that allow the feeder to slip on the material, none of these changes will matter because the conditions they are testing for will not happen.

Prior to this change, the Feed Angle input was tested after the move to ensure that the feed did not arrive late to the target. Depending on the configuration of the controller and the type of move, losing the Feed Angle input during the move is sometimes expected. Those conditions will not be covered here. The rest of this SCN concerns itself with the cases where the Feed Angle input is expected to be present during the entire move.

We have a customer that has requested that we monitor the Feed Angle input through out the entire move and stop both the Press and the Move if the Feed Angle input is lost.

Their Press Controller, and apparently others, have a Press Stop input. This input tells the press to stop imediately as somehow simply turning off our Press output allows the press to continue through the current press cycle.

On Continous Press controllers output 3 is now the Press Stopped output. We monitor the Feed Angle input during the entire move. If the Feed Angle input turns OFF unexpectedly we will turn ON the Press Stopped output, turn OFF the Press output and display the Press Miss-Feed error. The Press Stopped output remains ON until the user acknowledges the error by clearing it. Entering the Run mode is also prevented until the error is acknowledged.

This change increases the likelihood that the Feed Angle input may not be ON when attempting to enter the run mode. A test for the Feed Angle input was added as a permissive for entering the run mode. If the Feed Angle input is OFF an error is displayed indicating that the Feed Angle input must be ON.

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.