Programming Video Games in Industrial Machine Controller PAC/PLC

RFB PROTOCOL

RFB or "Remote Frame Buffer" protocol was created in the Olivetti Research Laboratory to manage graphic interfaces remotely. The idea was to create a protocol as simple as possible, so as much hardware as possible (thin clients) could deal with it. One of its simplest function is to draw rectangles specifying basically 5 parameters: x position, y position, width, height and color. In that way an image can be composed of multiple rectangles, sending only 5 parameters per rectangle and there's no need to send desktop image pixel by pixel to the thin client, saving bandwidth.

Some components used for building & testing:

• Low cost network thin client.

For more info visit: Absolutelyautomation.com

Here is the list for the required components for this project with the absolute lowst prices! If tou find something cheaper somewhere, please msg me!

• Industrial Ethernet switch ► ( http://goo.gl/CZKVHz )

• Ethernet flat cable ► ( http://goo.gl/CZKVHz )

• Low cost ethernet network thin client ( http://goo.gl/tSu5yB )

• Industrial 5 V rail mount power supply - Controller Power ► ( http://goo.gl/CZKVHz )

• Industrial 24 V rail mount power supply - Switch Power ► ( http://goo.gl/CZKVHz )

• Opto22 PAC R1 Controller ► ( http://goo.gl/CZKVHz )

• Opto22 4 Position PAC RACK ► ( http://goo.gl/CZKVHz )

RFB SERVER

The main use today of RFB servers is to take an actual image of a desktop (windows, menus, icons, apps, etc.) and send them to the remote client, also capture client actions ( mouse movements, clicks, key press) and send them to the desktop. However, due to the protocol independence from any operating system, this can be used to generate content for the client that not necessarily exists in a graphical form in the server. A classic example is a game server, where the server doesn't have screen, graphic card, controllers or keyboard, only data processing and a communication channel, it's on the client side (player) where the graphic card, monitor and keyboard are installed.

IMPLEMENTING RFB IN PAC

To develop an app RFB server two things are needed: some kind of network connectivity and some platform to write programs than can send/receive network packets. There are some examples of RFB apps, in this case a counter that can be compiled on any system with a suitable C compiler, and an extreme case where an ESP8266 module is used as an RFB server.

A PAC (in this case an Opto22 SNAP UP1 ADS) has these characteristics. If there is no PAC available, a free simulator PAC Sim can be used.

OPTOSCRIPT AND FLOWCHART PROGRAMMING

The game was developed using free PAC control for Windows suite. There isn't an official tool to program an Opto22 PAC using Linux, however, due to the control strategies sent to the PAC are text files with content coded in FORTH shouldn't be very hard todevelop an alternative.The programming language uses flowcharts. Several charts could be created and run in parallel, in that way the game's logic could be split from RFB protocol implementation. A big advantage of PAC vs PLC (the gap is closes a bit every day!) is the ability to use basic network primitives, that can be used to build new protocols not included like RFB. In this case the primitives are very close to the client/server socket functions of familiar programming languages.

The game's logic, paddle positioning, ball movement, collision detection and scores were programmed in an independent flowchart, in that way the game could be accessed by other means or protocols like digital or analog I/O, or using a SCADA with Modbus, etc. The game is for a single player and there's a small "smart" algorithm that plays as a computer opponent.

In the implementation of RFB protocol some shortcuts were taken, a lot of client requests are ignored, a very simple color palette was transmitted and a very crude rectangle encoding were used, so the game have not very advanced graphics!

CONCLUSIONS

• It is possible to implement the RFB protocol in an Opto22 PAC. A possible use for it is to develop "less fun" apps like remote SCADA or HMI accessible via VNC client, as a different alternative for IoT apps.

• The game only allows one single client connected, however, is possible to modify it for two or more simultaneous remote players.

• Rectangle based games where the screen doesn't scroll or changes often (i.e. Pong, Tetris, Breakout) are easier to develop using RFB.

• The control strategy works with a real PAC or with a PAC SImulator.

For more info visit: Absolutelyautomation.com