Asynchronous Printing capability was added to the Keyence printer Driver.

The Hole correction feature has been enabled on the Open Loop XL202, XL206 and XL212 models.

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.