A new segment was required to store and access the ARM application required for the Rev G and higher 5386 board. This change reads the descripter table and populates the hardware structure so that the 5386 application can access the ARM application and program the ARM if required.

This is no longer the case. This change was removed prior to the software being released. The 5386 Watch Dog signal notifies the ARM chip that the 5386 Watchdog has failed.

The FM31265 will no longer be responsible for the 5386 Watch Dog on Rev G and higher boards. In the Rev H hardware the ARM processor will take over this responsibility with much more control and less 5386 overhead.

The 81000002 and 81000004 task errors get reported if an integer to string or integer to hex string function is called and the caller specifies to allow zero characters to be used for the conversion.

A customer mistakenly caused this by specifying zero characters to print a bundle number. This shut down their entire factory since they rely on this one machine for all of their production.

Rather than shut the whole controller down for a simple mistake, the decision was made to do what the function arguments said to do and use zero characters, in other words, set the string to zero length or add zero characters depending on if it was a copy or add string function call.

A customer complained that they would be missing gags on the first part when entering Run Mode. The gags were Expanded Gags that get sent to a PLC via MODBUS.

The customer had PLC strip data records that showed the gag would come on briefly at the appropriate time and then briefly at the end of the press cycle. Rewiring one of the affected gags to use a hardwired gag eliminated the problem for that gag.

The diagnostic data screen on the XL showed no blips on the affected gags.

A code review showed that there was a race condition when sending the Expanded Gags to the PLC. There was no Mutex protecting the time when the data was copied into the command buffer and when it was sent. This allowed a lower priority task (B) make a copy of the data but get interrupted by a higher priority task (A) before it could send it. Task A was able to modify the master data and send its copy. When task B was allowed to send its copy, task A's edits were overwritten in the PLC. If a third task (C, A or B) needed to send gags, since the master data was correct, it would fix the issue caused by the race condition. This led to the affected gags to flicker on and off at the beginning and the end of the press cycle.

We have no way to duplicate the timing of the customers machine. Something about the timing is making this race condition occur on the first part after entering run. This bug fix will most likely fix it but there is no way to absolutely know for sure until it is tried on that machine.

The Press Information diagnostic screen displays the state of the Expanded Gag IO. The display headers of each gag byte were supposed to display the Gag Id range contained within the byte. If more than one press was configured, this failed to be the case.

The gag number range in the header of each gag byte now represent the Gag Id numbers as are programmed into Tool records.

The Press Information screen now displays the number of Local and Remote presses and gags. It also displays the total number of presses and gags.

Persistent Memory, which is where the SERCOS settings are stored, had corrupted SERCOS settings. The Cycle Time setting was invalid, resulting in an invalid setting for the XL operating system timer. This is what caused the 80090270 task error to occur.

The controller will now test the settings on power up and configure them to valid default values if they are found to be out of range.

These changes are in the Boot Code. In order for these changes to be present the Boot must be updated to V2.05 or Higher.

Most of these changes were made by Jim with some changes made by me. They were made in response to issues with erasing and programming on the Rev H hardware, though there should not have been a difference.

Programming Improvements.

1. Check to see if a word location is already programmed before trying to program it. If it is already programmed correctly it must be due to a communication timeout retry. If it is not programmed correctly or not erased report a programming error back to FlashWizard.
2. Check for programming completion using the method specified in the Flash Part Spec sheet by doing two reads in a row.
3. The commands were doubled, duplicated in the command word with no explanation. This did not match the chip documentation. The Rev C hardware was presumably programming two chips at the same time. The High and Low Bytes may have been going to two different chips. We only have one Flash chip in the Rev D and Higher that operates in a Word Mode. Removed the duplication for clarity.

Erasing Improvements

1. Removed an Unprotect command. This command is not part of the erase process and should never have been in the code.
2. Added an erased test on the first word or each segment as a quick double check of erasure. Not a comprehensive test but simple double check.
3. The same command duplication that was removed from programming was removed in erasing, though erasing already had most of this removed.

The "simcon" command line argument to set the port for the simulation console failed to parse the correct port. The default port, 4002, was used instead.

This bug has been fixed.

IO Names can now be requested from the Simulation to allow a more user friendly IO interface to be developed. Details on the interface are defined in the XL200/Diagnostics OneNote.

Quality Audit Triggers and other custom lists allow 40 characters for the length of the name. These lists are displayed in table format in the Production Data screen and in the case of QA Triggers, in a dialog window. If the name is too long or uses lots of the wider characters like W, the name may not have room to display entirely.

This change addresses this issue for QA Triggers when they are presented in the dialog window. Instead of using a single line prompt to display the name it was changes to a multi-line Text Box that allows text wrapping. The entire name is now able to display when presented in this way.

The Allow Coil Override setup was unintentionally being hidden when Allow Coil Inventory was configured to "Remote". This bug was introduced when the "Remote" setting was added Allow Coil Inventory. It has now been resolved.

A customer requested that we be able to send the XL Line Speed to the PLC via MODBUS. They are unable to add an Analog card to their PLC to get this information via analog.

This feature sends the speed as an integer in inches per 100 seconds. This is easily converted to inches per second and provides two decimal places of resolution.

The update rate can also be specified by setting a field in the MODBUS configuration structure. This field indicates how many times per second to update the field. Care must be taken by the customer to only update it as often as required to prevent excessive slowing of other MODBUS features.

Explicit details on how to use configure the feature in MODBUS can be found in the XL200 Series PLC Interface Spec.

Code is being moved around and restructured on the 386 CPU to account for differences in the ARM and the DSP co-processors.

While in Blanking mode there was a bug in the code that prevented edits to the Front Shear Kerf from being used. They would not get used until the next transition from Standard Mode to Blanking Mode.

This has been resolved.

The ARM ethernet stack on the Rev H 5386 board assumes a different byte order than the DSP.

The most convenient place to handle it was in the Ethernet Setups, common the V4 and V5 XL2 software.

Added conditional assembly to allow ARM processor to share the main functional portions of the code with the DSP processor.

The Close Loop Brake and Hump controllers already have had the Short and Very Short outputs and Delay after Shear times. We have started to do some Open Loop brake and hump style lines and these features have been requested.

This change adds the Setups, Outputs and the Delays to the Open Loop controller. The outputs require Expanded IO (PLC/MODBUS IO). All of the setups to control the two features require the PLC (I) option in order to be visible in the Open Loop.

Short Part is on output 33. Very Short Part is on output 34.

In the Windows Simulation Die Accelerators would sometimes have dips in command voltage or report Drive Not Responding errors. This was tracked down to a simulation only issue.

In the windows simulation the press operations were being logged to the console window to make watching the simulation easier. These debug prints were sometimes causing the press task not to run and generate new Set-points but the timer interrupts, encoder simulation and Loop still did run. This caused a dip in the command signal as the Loop tried to follow the instantaneous stop in the Set-points and then a Drive Not Responding when the Set-points instantly started again.

The Die Test would run a maximum of 9999 cycles before stopping.

9999 cycles is usually enough but during some testing we want to leave it running longer.

The issue was that the Die Test was keeping track of parts that it filled into the queue. It would only fill 9999 parts, which is what the hidden Die Test, test part is programmed to. No production is tracked against this part, keeping track of how many items for this part were filled into the queue was not necessary.

SCN 3575 and SCN 4426 provide history and context for this change.

With the "Lag on Die Return" set to NO there have been disturbances in the command signal (Analog) when switching the Lag ON and OFF.

The command signal is made up of proportional, integral, Lag and Feed Forward components. If any of those components are suddenly removed or added, they will cause a disturbance (Jump) in the signal. When the Lag is turned ON or OFF during the Die Cycle, this is what happens. These disturbances are especially bad if they result in a jump in the opposite direction than the signal is already trending.

The solution is to switch the Lag ON and OFF when the Lag and Feed Forward components are as close to zero as possible and when any necessary jump will be in the same direction as the signal is already trending.

The motion profile (Set-point) code knows when it wants the Lag to switch ON and OFF. The Loop code knows when it is safest to do the switch. The Loop code will now delay the switch until the best time to do so.

When switching the Lag ON, the Loop will wait until the Filtered Set-point velocity is at or above zero.

When switching the Lag OFF the Loop will wait until the sum of the Acceleration Feed Forward and the Lag are less than 0.5% of Maximum Analog. This point in time happens during the deceleration of the die before it comes to a stop. The Set-point code now requests the switch at the start of the deceleration ramp.

SCN 4049 created the Selective Closed Loop feature. It describes how the feature works.

Two bugs were found in the feature, both related to Coil Tail In.

1. The original change included the ability to switch from Closed Loop to Open Loop on the fly during a Coil Tail Out. However, the code failed to prevent switching from Open Loop to Closed Loop on the fly, which would only happen on a Tail In. The Tail It causes a jump in the Command signal due to the loop error that accumulates while in Open Loop. A large enough loop error results in a Drive Not Responding Error. The solution was to force the controller to stay in Open Loop until the material stops and the motor is disabled. Switching to Closed Loop only occurs when the material is stationary while enabling the motor.

2. The motor Set-Point was not being set correctly during a Tail In. This resulted in a Slip Test Error because the Selective Closed Loop performs a Slip Test by making sure the loop error does not become excessively large. The incorrect Set-Point was resulting in loop errors large enough to trigger the Slip Test failure.