Purpose and Goal: The RPI serial buffer is meant to replace the large buffering we had with the older Digiboard serial processors. Short story.
Longer story: This product is meant to supplement the existing serial data processing of the Clarios/ColorQuick in-press color measurement and control systems. Initial problem to fix is to allow successful operation of closed loop control of GOSS Omnicon V3 press consoles. These press console contain a 3rd party control interface with an enhanced version of an older Harris Graphics control protocol called TeleColor II. HWS, later acquired by GOSS International, expanded this protocol to be more flexible and included many more advanced features. The data exchanges between the press console and the controlling system required many messages to be exchanged to allow the features to function properly. Timely replies from both systems will allow the exchanges to function within a very short time. However, if either side misses any data from the other, the process must start over again, more data to be exchanged again.
Any issues with AT messaging with Ov3 consoles seem to come from the large amount of serial data blasted from press console. The coalescing factor in the Ov3 system does help with this timing, but the new serial processing PCBs are just not big enough to grab ALL of the messages completely, thus creating at a lot of retrying of the correct message sequences on both sides of the communications. Ideally, the HW hand shaking would take care of this large amount of data from the press. I don’t think we can count on this feature to work correctly from Ov3 console and the new serial processors. What the older Digiboards allowed us to do is capture EVERYTHING from the press console and then deal with the press messages as quickly as we are able to in the Clarios server.
The new RPI serial buffer is going to repeat this feature we lost from the older Digiboards (many kilobytes of buffering). It will capture EVERTHING and meter the Clarios server the serial data to the new serial processors as they are able to consume with their limited serial data buffering.
This is a little different from the filter computer. It listened to the same data stream and filtered out all of the garbage dampening system messages we did not need. This brute force solution was good for things we don’t use and allowed us to focus on messages we do need.
The solution required with advanced Ov3 systems is we need EVERYTHING and we are not getting this from the new serial processors. This product sits between the Clarios App Server and the Ov3 console. Configurable is number of bytes transfered at one burst and the time period of data stream is paused before another burst is sent to the Clarios App Server. This is to allow any serial processor PCB to be used in the Clarios App Server and maintain a steady pace of communications, without excessive number of retries.