When a Setup Configuration gets loaded into setups, the changes to setups should bet backed up to Eclipse. However when the configurations got loaded, the Backup bit for Setups that Eclipse relies on was not getting set. This has been resolved.

Edits to Setup Parameters that are part of Setup Configurations can now automatically be saved into the currently selected configuration.

A new Setup has been added for Backwards compatibility. The new setup is called "Save Setup Edits to Configuration". It defaults to No, which results in no changes to the controller operation. If the user determines that they would like their edits to configuration parameters to be saved in the configuration they can set it to Yes.

When set to Yes, the values of the configuration parameters will be saved in the current configuration just before loading a new configuration.

The new setup can be found in the "Operator Preferences" setup group.

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.