Print Driver memory records were identified and tested under the assumption that their record ID's would be unique and within a predictable range.

We have run out of ID's within the Part Printer range. The fix involved allowing Part Print drivers to use ID's out of the Bundle Ticket Printer range. This required several changes to places in the code that were using the ID to test the Record pointer.

A new print driver for the Keyence MK-U6000 printer has been developed. All information about the driver and the printers supported features are documented elsewhere in a One-Note at the following link.

https://amscontrols1.sharepoint.com/Products/XL200/_layouts/OneNote.aspx?id=%2FProducts%2FXL200%2FSiteAssets%2FXL200%20Notebook&wd=target%28Printers.one%7C0C18AF95-E5EC-472C-A9B9-4BE0B2D5B227%2FKeyence%20Driver%7C29C2CAB2-D4D8-41A2-9431-B14097FBC15F%2F%29 onenote:https://amscontrols1.sharepoint.com/Products/XL200/SiteAssets/XL200%20Notebook/Printers.one#Keyence%20Driver&section-id={0C18AF95-E5EC-472C-A9B9-4BE0B2D5B227}&page-id={29C2CAB2-D4D8-41A2-9431-B14097FBC15F}&end

The x370 printer boards have configurable RS485 baud rates and RS232 Baud Rates. The Print Driver configures both Settings.

A new setup called "Max x370 RS485 Baud" will configure the maximum RS485 Baud rate that the x370 boards will be configured for. The driver will now try to configure itself for the highest baud rate that the board is supported for. This new setup will place a limit on that baud rate. In addition, the FW version of the board places a limit on the supported RS 485 Baud Rates. The new setup defaults to 14400 as that is the maximum baud rate that would have been used for any installation prior to this change.

Fw Version Max Supported RS485 Baud Rate 0.00 to 2.00 9600 2.01 to 3.02 14400 3.03 28800

= 3.04 115200

Because the setup effects multiple drivers, Part and Bundle, the print drivers must be re-selected or the controller reset in order for a change in the new setup to take effect.

The RS485 Baud Rate that the XL is currently using to communicate with the x370 is now displayed in the Printer Status screen in the RS485 Prompt.

A couple of old Print Drivers needed to be modified because they modified the RS232 baud rate internally. They needed simple changes to maintain the RS485 Baud rate while doing this. We don't have printers to verify the changes with but they are extreamly simple and safe changes, they should work, or actually fix older problems.

The printers are the M2001 and Image drivers.

Prior to this change, in order to send one command to a printer the XL had to execute the following commands with a 6370. Each command requires the XL to wait for a response from the 6370

1. Clear the RS232 Receive Buffer
2. Send Print Message data.
3. Tell the 6370 to send it to the printer.
4. Ask the 6370 how many characters it has received from the printer
5. Ask at least one more time to make sure the printer has stopped sending.
6. Request the printers response from the 6370.

The protocol and communication has been changed for newer 6370 boards v3.04 to require fewer commands and less time waiting on responses.

1. Clear the RS232 Receive buffer, send the Print message Data to the 6370 and the 6370 starts sending it right away.
2. Request how many characters the 6370 has received from the printer. If the printer has received enough characters and has not received any more in some time, also return the characters to the XL.

The actual 6370 protocol has been updated and more details can be seen in the 6370 protocol spec. The XL has been updated to use the new commands so that it can spend less sending commands and waiting on responses.

Some printers require binary communication and some require standard ASCII communication. There were duplicate functions for each method of communication. With the addition of the new 6370 protocol commands, these functions were going to double again unless some restructuring was done to combine Binary and ASCII communication into one function.

The RS485 Auxiliary port (Port B) is used for printer and slave controller communication. The communication can now be selectively monitored using Flashdoctor.

Typing debug rs485 will toggle the debug output between three modes. The first and default mode is off. The second mode displays all communication. The third mode only shows failed communication.

The user should be aware that enabling the debug information does change the timing of the communication.

SCN 4138 was further improved upon to allow communication error retries to be non-destructive. In other words do no harm.

Communication errors occur in an industrial environment. If the response by the 6370 gets corrupted and the XL200 sends the command again, the retry must not do anything that would cause an error on the printer or the 6370.

The original 6370 commands all could be resent, with the exception of one, without doing any harm. For example, the 'T' or 't' commands could cause duplicate characters to be sent to a printer.

The new commands introduced in SCN 4138 are now all non-destructive, with the addition of a sequence number to the 'A' and 'a' commands. The sequence number is used by the 6370 to determine if a command is new or if it is a retry. If an 'A' or 'a' command has the same sequence number, the 6370 replies with the same response it replied with for the prior command, without actually doing anything because it already executed the command when it was sent originally.

Rondo paid a company to write an emulation of the videojet driver to convert between the VideoJet protocol to the Hitachi protocol so that they can use a Hitachi printer. The emulation has difficulty emulating the timing so we have modified the VideoJet drive to allow for more response time.

The VideoJet driver will now wait 500msec for a response to all commands.

SCN 4046 added a Bundle ID Warning Message/Informational Prompt. This change created a memory leak of 192 bytes every time the Bundle changed. On some lines this can happen quite frequently and use up all of the controllers Heap memory rather quickly.

The 800102FF task error gets reported when a corrupted Free records is encountered on the Heap. Unfortunately, it also reports the same error if it gets to the end of the heap without finding a record of sufficient size.

XL2OL and XL2CL Roll forming controls V4.60.00 through V4.62.01 have this issue. XL220OL and XL220CL HVAC controls V4.15.00 through V4.16.00 have this issue.

Since extra the extra communication and printer status tests have been added to various drivers, the controller has reporting two errors for every one status or communication error.

Steps have been taken to eliminate this issue for all drivers going forward.

The original VideoJet driver had no Communication or Status checks of the printer operation, SCN 3955 and SCN 4093.

Rondo recently asked for them to be added to ensure printer reliability. They appear to be functioning correctly on all of their VideoJet printers.

Another customer has recently updated and these test are now randomly failing on their printers. We believe that these random errors are actual occurrences of the printer system failing to respond appropriately, most likely due to incorrect installation practices or localized interference. The addition of the tests are now catching these issues as intended. However, customers don't see it that way.

Because these issues weren't caught from the beginning, they want us to help resolve them. On this old driver we are going to disable the test by default and allow them to turn the tests ON if they choose.

The new setup is called "Status and Communication Tests" the setting defaults to No, which disables the tests. This default value minimizes the number of potential phone calls after an update.

The only reason we are adding this setting is because we haven't had these tests from the start so that each of the installation of the printer was tested. In addition, this setup is only available on the VideoJet driver. It is the only driver that has had the tests added after a long period of release. All new drivers will have the tests by default, with no way to turn them off.

The new refactored communication code (SCN 4139) had a failure mode that fell through the cracks during testing. It caused the string to get too large and generate a 81000003 task error while trying to add a Hex string.

This has been resolved.

Asynchronous Printing capability was added to the Keyence printer Driver.

The SERCOS code would cycle through the phases, from zero to 4 and then back down to zero, if the controller was powered up with a drive fault present. Specifically if an Emergency-Stop Active fault was present. This is undesirable as the fault gets cleared, which updates Flash, and then come right back. One customer was complaining that this was wearing out the Flash memory on the drive.

AMS configures an E-Stop to be a Warning, which is why it was never caught until now, when it was brought to our attention.

This issue has been resolved.

If a class 1 fault was detected, the SERCOS code no longer responded to a loss of fiber connection or drive power cycles.

This was found after fixing the issue with E-Stop faults in SCN 4156. The code that tests for class 1 faults needed to consider a loss of Fiber Optic connection as a higher priority fault.

The Keyence printer prioritizes some user interface interaction over the serial communication interface. When this happens, the printer responds with an error on the serial interface but not on the User Interface.

Sine this could prove to be very confusing, the print driver has now been modified to test for this error response from the printer. When this error response is detected the controller will halt the line and direct the user to return the printer to the main screen.

Any Print Driver that requires a Minimum x370 version in order to operate is now able to report an Error when entering the Run Mode or when entering the printer diagnostic screen if the minimum version is not present or the version has not been detected.

It only does this test if the x370 has been found with the version command so that is has a version to test against.

The error will show the minimum version required and the current version.

The only driver that currently has a minimum version requirement is the Keyence driver. It requires a minimum version of 3.04.

Modified the PEG graphics (User Interface) library to support 5386 Rev E and higher boards.

The x370 Status in the printer diagnostic screen is supposed to display the status of x370 communication, it does not know about printer communication errors. It was being given the printer communication error codes, which it did not know how to process so it displayed "Unknown Error". This has been resolved.

The Max x370 RS485 Baud setup no longer requires the printer drivers to be re-selected after an edit to the max baud rate. A change to the value will now trigger an update to the RS485 baud rate of all printer boards, Part or Bundle, without having to de-select and re-select the print driver of each.

Our driver communication methods never used to return an error for a missing printer response, as long as communication with the x370 was succesful.

SCN 4139 added an error if the printer failed to respond.

Through a lot of digging through code and the VideoJet ESI protocol it has been discovered that the printer, using todays driver, will very rarely respond to a new print message, which was now getting interpreted as an error.

"SCN 4152 - Selective Disable of VideoJet Communication and Status Checks" was supposed to prevent communication errors with the printer from halting the line (keep the driver working as it had before the addition of the communication and status checks) but it failed to consider the new error that had been added.

This issue has now been addressed. When the Communication and Status Checks are off, a communication timeout with the printer will be ignored. Communication errors with the x370 will still halt the line as they did prior to the addition of the setup parameter.

While researching the cause of "SCN 4177 - XL2; VideoJet bug with SCN 4152 Disable of Communication and Status Checks." an additional issue was discovered.

If the parameter is set to Yes, the printer must always respond to a new print message command. Through extensive review of the ESI printer protocol I discovered that unless certain things like logos are being configured, it will not respond.

The printer is now being configured to return the ASCII hex characters [07][21] when a new print message is received so that it always returns a response no matter what is included in the print message.

One exception to this is the case of a Videojet printer emulation that Rondo has had written. Since it is not an actual VideoJet printer, they may need to have their emulation modified in order to use this new software change so that it responds in the same way an actual printer would. It should support the ESI [1B][01][06][xx] command where xx is a field that specifies what status reports to generate. We are sending [1B][01][06][04] in order to receive the Message Received Ack [07][21] status report.

The controller was resetting when selecting the Operator Preferences setups or scrolling/paging down in the Controller Settings setups.

The problem was ultimately caused by code that was trying to remember the language selection on a memory clear, which also happens after a program update.

The previous selection may be invalid after a program update due to memory mapping differences. The code that decides what current language to display would detect the invalid language selection and default to displaying English. However, the language selection setting index was not updated. When the Language Selection setup was placed on the display, the selection caused invalid memory to be referenced when looking up what was supposed to be the current language string. This caused the reset.

The XL200 serial number will now also be displayed in the Setup Screen to the right of the where the Switch setting is displayed.

These changes involve removing unessesary code that no longer applies to Version 4 or 5.

They also involve changes to common code that must differ between Version 4 and Version 5.

Elimination of the DSP programming in Version 5 since it has an ARM processor that will no longer be programmed by the 386 processor.

Decrease Quantity converts Scrap material to Good Parts. It is used to recover/convert scrap parts or material into good parts. It makes no sense to do this on a Scrap Item that will always be reported as scrap if it gets run. In fact, the Decrement Qty will do exactly the opposite of what the user is trying to do. It will take a scrap part, intended to be scrap and be reported as scrap and report it as good material.

A Decrement Quantity on a Scrap item is no longer allowed.

As windows does updates it apparently begins to use more stack space in the Windows API calls. If it uses more that the Windows simulation has allowed for, it cause the simulation to crash. It seems to only happen on selected PC's. So far no windows compatibility mode has been able to fix it all the time.

The Stack space for the Peg_Task has now been doubled from 0x3000 to 0x6000.

Added code to protect from MPERIA plugins returning mor characters per display line than the XL allows for from the Version command response.

Disabled the MPERIA simulator communication so that the driver can be selected and used by laypersons in the Windows Simulator.

One customer defined 827 Product Codes, many of which are actually duplicates.

The line they did this on is a Purlin Line that has logic in the PLC to compare the recipe between two product codes to determine if they are actually different.

They were hesitant to redefine all of their product codes and recipes so we created this backdoor solution to allow them to Bypass all of the PCode comparison code in the XL.

In MODBUS version level 121 a new configuration bit was added to enable a Product Code Comparison Bypass mode. Enabling this mode disables the Product code comparisons that halt the queue or enforce setup or tool configurations. The settings controlling those feature get forced to disabled and the settings get hidden from the user.

This feature and a Multi-Axis controller with PCode setup Axes defined are incompatible with one another. The user will be forced to disable one or the other with an error message if they want to run.

In SCN 4139 the code printer communication code was restructured. The restructuring was successful except for printers that respond with strings longer than 10 characters. An errant line of code mistakenly informed the communication methods that it could only receive a maximum of 10 characters. The communication method was waiting for and seeing the characters in the x370 receive buffer but it would not request them since it believed it did not have enough room in its receive buffer to hold them.

A customer complained of Intermittent Run Input issues. The Controller would appear to intermittently not respond.

The issue was tracked down to a memory leak related to the Bundle Ticket option and deleting orders.

The scenario to reproduce the problem involved a long period of time where orders were deleted immediately after production completion. When this happened, the orders were able to be deleted from the user interface or Eclipse but they are only hidden. The final deletion of the memory was not able to take place due to an invalid Memory Record Id test that failed to consider records that are marked for deletion. Eventually the number of orders and item records needing memory deletion resulted in a statistically significant(noticeable) chance that the run mode would be locked out when the user attempted to enter run.

The invalid Record ID test was fixed.

To prevent small run lockout times from causing random Run Input failures, the run lockout test now allows a 100msec delay. If the lockout is released within 100msec the controller will continue into the run mode, otherwise the run mode will be forced to HALTED (as displayed on the screen).

The PC simulation would sometimes crash during a shear operation, depending on who configured the simulation.

If the Order, Material or PCode were left blank, the simulation would crash during a shear operation.

The cause is related to shared strings in the XL. An empty shared string results in a null pointer. When copying strings, the source pointer gets tested and considers a Null string as an empty string. The Sub_String and Add_String functions needed the same code.

A PC has OS protection to detect using Null pointers. The XL hardware does not. Some users have gotten in the habit of not programming the order fields, which works on the XL hardware due to lack of OS null pointer tests. This habit caused this bug to be detected in the PC Simulation due to the addition of new code that used the Sub_String function.

When the standard XL200 controller PCode field size was increased to 20 characters, the HVAC controllers stayed at 5 due to other limitations in the UART spec that have since been resolved.

The HVAC PCode field size is now 20 characters. Moving forward, the size will always match the size of the standard controller.