Further Industrial Applications via PLC Interface

We were recently contacted by another industrial company who needed to replace an ageing printer on their multi-million pound industrial system.

The system was running on a Siemens PLC S7 with a CP340-RS232C interface to send report data from the process to a dot matrix printer.  Printed data was important as proof of the process having been undertaken and its measurements.

Now, you would think that with a modern PLC, still supported by Siemens, and the need for an RS232 inkjet printer, this would be fairly easy.

However, the company also wanted to store all of the printed reports as PDF files which could be forwarded to a network or USB printer, so that the printed proofs could be stored long-term for regulatory bodies without needing masses of printed paper (and scanning).

The software had been developed by an industrial controls firm but the existing solution used by the client to print via Ethernet or USB printers (the ipcas GmbH printer convertor) was no longer available and the industrial controls company were unable to offer a replacement.  This module would also have not allowed for creation of the electronic PDF version of each printout automatically.

Thankfully, the Company had come across our Retro-Printer module as a possible solution.

Our first step in the conversation was to ask the client to ascertain what printer the PLC software was set to print to – this was a HP Deskjet printer (although it was simple plain text), so we could confirm that we already emulate that type of printer without requiring any changes to be made.

The next step was to supply a Retro-Printer module and relevant software pre-configured with a fixed IP address so that the client could test the solution.  This had to be done through an existing third party supplier to the client (a method we have used before to overcome rules around the need to be an approved supplier for a small purchase).

The client received the Retro-Printer module and were please to confirm that the test runs to a connected USB printer worked immediately, but there were a couple of issues to be addressed:

a) The default font did not match the original printout.  We already support various font options (using our own custom fonts) and were able to advise the client how they could easily change the font and default font size to get a printout which closely matched the original.

b) The page header was printed at the top of the next page.  This took a little investigation on our part into the raw files which were indeed plain text, except for having a form feed character just before the page header was printed.

It was therefore apparent that the original solution assumed that the very first page did not have a header, but because continuous paper was being used on the dot matrix printer, the header could be output at the end of a print job to get the next page ready for printing (and presumably make it easier to tear off!).  Unfortunately, this would not work with a modern single sheet printer – the report page would be printed on page 1, and then the header printed on its own on page 2 which is then printed when the printer times out.

We therefore confirmed with the client that the reports never exceeded a single sheet of paper, and we then made a small custom change to the conversion software so that a form feed character actually moved the cursor to the top of the existing page, and then only acted as a form feed when the next line feed character was received.

This bespoke software change was implemented quickly and meant that the header was now printed at the top of the current page, and therefore appeared at the top of the report again.

By using a custom configuration option to turn this on or off, this means that if we issue a future update to the general Retro-Printer software, it can be installed and still work as designed for this client.