RetroPrinter.com

Supporting more Industrial Applications

Maguire Gravimetric Blenders

The first is a company who needed to capture the data from various Maguire Gravimetric Blenders (WSB series with old 6811 controllers) which they use on their shop floor.

Originally, they were printing the reports onto paper, but it ended up generating hundreds of sheets of paper per day across the numerous machines.  The company also tried a different printer capture device, which connected to the centronics port on the machine, and store the data in a text file on a connected USB memory stick.  Unfortunately, the price was over €700 and proved too expensive for the company to justify adding one to each machine.

As an alternative, they purchased a Retro-Printer plus Raspberry Pi 3 Model B to trial capturing the data from the blender machines. After a few issues with working out the best configuration options to use for their device; not only could they prove that the Retro-Printer worked with their equipment and could provide the data which they required; but also that there was a further advantage in that they did not need to connect the Retro-Printer to their network as such and could attach a keyboard and monitor if required.

This also enabled them to realise that there was a serious mechanical problem with one dispensing unit; an issue which would not have otherwise been obvious.

The next steps will be to feed the data into a dashboard in order to highlight alarms on each machine – which is something we can help with also thanks to our experience in  creating SCADA dashboards for processes.  As a side project, we are also looking at releasing a USB-RTC module which will maintain the date when a Retro-Printer module is not connected to a network.

Sun Workstation

Another customer wanted to connect the Retro-Printer to a Sun workstation, so that PDFs could be created of the printed data.

Here we were faced with the issue that the Sun workstation defaulted to printing PostScript, rather than HP or Epson printer data.  We were quickly able to adapt the existing HP PCL emulation routines to handle PostScript as an alternative emulation.  This has now been added to the forthcoming v3.8 software release for the Retro-Printer Module.

GE Series One Junior PLC

Another customer wanted to extract the data from an old GE Series One Junior PLC and read it from their on-site PC.  This was equipped with a IC610PER151D printer interface with centronics connector.

The manual for the printer interface stated that it would with any printer where the character code 7Ch (124 decimal) should produce ‘/’.  This was a surprise as according to the Epson printer standard and most ASCII tables,  0x7C is normally a pipe “|” character.

We just had to make a small change to the software to allow for this character substitution and the v4 Retro-Printer module worked first time on being connected.

Packard Cobra II Gamma Counter Model 5003

This time, we were asked to supply an NHS Foundation Trust with a Retr0-Printer for testing with a clinical radiometric detector (radiation counter), a Packard Cobra II Gamma Counter Model 5003, made by Perkin Elmer in about 2007

The NHS Trust installed the Retro-Printer using our supplied manual and now collect the data electronically, rather than on environmentally wasteful paper; as well as allowing them to continue using this aged piece of equipment following problems with the supplied printer.

The Trust is now considering how best to use a second Retro-Printer for a room pressure monitor which has been hardwired using a 25 pin serial cable to connect to the serial port on an Epson LX-300 Dot Matrix printer.  We have been able to suggest two methods of how we can connect to this and are waiting on confirmation as to which method of connection they prefer; ensuring that the two Retro-Printers remain easily maintainable into the future.

HP E4407 Spectrum Analyzer Oddity

We have come across an issue with connecting the Retro-Printer module to a HP E4407 Spectrum Analyzer.  According to the online manuals (albeit for slightly different models), this outputs screen shots using PCL3 (HP printer data).

For some reason the captured data is normally corrupted, but other screens are processed correctly.

We have asked the customer for all of the captured data, so that we can try to determine what is happening here.

We managed to resolve the issue with the HP E4407 Spectrum Analyzer having reviewed the captured data from the customer.  It transpires that the machine was setting bit 8 on every character – it is a wonder HP printers could cope with this – although there was probably a DIP switch somewhere to set it to 7 bit printing.

At least the Retro-Printer software already allowed for this (thanks to having come across this same issue with a Siemens printer).

Chopin Alveolink NG

AlveoLink NG Printout

This machine is in use in a bakery to autonomously record and calculate air pressure changes measured during the bubble formation of the Aveograph. The alveographic curves of the five tested sub samples are simultaneously visualized on the screen, in different colors. The average curve is automatically drawn and the average parameters Pmax, G, L, Ie, P/L, W are calculated and displayed.

Originally this machine was connected to a HP OfficeJet Pro 6230 printer via the centronics port. However, when we connected the Retro-Printer module to the unit and captured data, we found that there were differences in the generated PDF and the original output.  This turned out to be a variety of reasons:

a) Raster graphics commands were being issued after the machine sent an “exit raster graphics” mode command.

b) The raster movement command (ESC * b -25 Y) was then being used to move up the page (when the PCL5 standard states that this command only supports values of 0 to 32767).  This caused the graph to break up when the key and index values were printed on the graph.  A command was therefore added to the capture process to change this to a different movement command which supported negative movements.

c) The key on the right hand side of the graph was showing an outline red square instead of a filled red square.  Oddly the raster graphics show just an outline but the printer somehow created a filled area.  Another command was added to the capture process which changed this to a filled square.

By adapting the software, the end customer was able to reproduce the required output.