Test Report Processing
We have been asked a few times about the best method of capturing data from test equipment.
JetDirect
A lot of test equipment expects to print to a HP printer, which is normally fairly straightforward, however, we recently came across an instance where the output was sent to a HP JetDirect 500 print server and from that unit to different PostScript printers.
This posed a slightly different issue which took some time to investigate, as the handshaking setup was different to when printing directly from the original test equipment, but after various test runs and comparing the captured output, looking for errors in the code, we managed to resolve the issue. However, having fixed that and the customer being pleased with the results, they realised that screen dumps of the test equipment controls were not working.
This turned out to be a macro embedded within the generated PostScript, where it attempted to judge whether there was sufficient memory available to generate a view of the PostScript document. The code for the macro included a call to vmstatus which returns three integers describing the state of the PostScript interpreter’s virtual memory (VM). For some reason, this call appears to crash the PostScript interpreters in wide use on the internet as well as on the Raspberry Pi.
Having identified that this macro was causing the issue, we were able to write a special filter within our software to look for calls to this macro and simply remove them from the PostScript before we attempted to convert it to a PDF document.
Parsing the Report
We have also been asked now by a couple of companies to parse the data from the report as we capture it. For example, one company wished to save on printing costs, by only printing reports where the outcome of the test was a failure. Another company needed to allow for long delays between printing of each test result, so that they could all be combined into one document.
In order to achieve this, we implemented a custom type of parser within our software, which reads in each line of plain text sent from the test equipment, and then looks for specific strings, to extract information, such as serial numbers, or dates, and whether or not the test undertaken was a success or failure so that the failures could be printed immediately and be visible to the operators. This saved quite a bit of paper as the original EPSON TM-U220D receipt printer was printing out the result of every test including all passes which did not need any further work on the test boards.
Further, by identifying speific strings which always appear at the end of a test run, we were then able to add these to the parser to indicate that the test is over, and the captured data is ready for conversion to a PDF by one of our printer emulators. For example, this can be very useful where a set of tests can take between 5 minutes and an hour, dependent upon the outcome of each test and the materials being tested.
These are just a few examples of where we can quickly adapt our Retro-Printer software to handle real-world situations, saving the end customers both time and money.
