For more info visit:

Linux support for industrial hardware like PAC or PLC, in the case of the big and well known brands is basically non-existent. Some hardware is based on "exotic" architectures, however the vast majority have in their guts an x86 or ARM based system (Linux friendly architectures!), but the development and management tools remain developed for Windows operating system!

There are so many reasons (commercial, technical, philosophic) that perpetuates same situation. Searching on the web, we can find some PLC/PAC related applications developed for Linux, but practically all of them are communication drivers (for the open and well documented protocols!) , developed by enthusiasts


Some time ago, developing a little implementation of RFB protocol in an PAC, in a Wireshark session deliberate unintentionally left open, when uploading a new program, some clear text strings were visible, probably control commands or parts of the program being downloaded!

Digging a bit more in the application for program loading, an interesting option was discovered: "Download FORTH File". Searching in the web "Opto22" and "FORTH" throws some papyri scanned manuals: How to program Opto22 LC2/LC4 (very outdated hardware!) controllers in FORTH!

With that document, the next natural thing was to open all the generated files with a HEX editor and search some FORTH code inside. The results of the analysis were:

* Manufacturer's application generates many types of files (config, initializations, program code)
* All files were encoded in clear text.
* The programming language used wasn't strictly FORTH

Finding that not a single standard programming language was used to program a PAC is a little pitfall, however, finding that all files were encoded in clear text are good news for programming PACs from non factory supported operating systems like Linux, Mac, etc.


The first step for an approaching to an alternative programming tool, is to know how the original application download an already created program. A simple blink application was used and the way the application talks with the PAC was analyzed using Wireshark. After downloading many different programs, the event sequence was discovered:

  • A F (Handshake?) commands sent
  • AcquireLC (Session Lock command?) sent (probably to avoid other applications accessing the PAC while downloading)
  • .crn1 file sent line by line
  • .crn2 file sent line by line
  • .ccd task files sent line by line
  • .crn3 file sent line by line
  • DATESTAMP sent (control strategy file last modification date)
  • TIMESTAMP sent (control strategy file last modification time)
  • CRCSTAMP sent (seems like 00112233445566778899AABBCCDDEEFF value means: "ignore" or "don't use" CRC)
  • MAKECHECK, CLEAR.BREAKS, [ ABORT (Finishing commands?) sent
  • ReleaseLC (Session unlock command?) sent
Also, there are a couple of additional commands like get PAC info (available memory, errors, etc), stop program, start program, erase program, etc. that were investigated and implemented!

A python app named O22termeng was developed, is capable of downloading programs to the PAC and send the aforementioned commands


Now, having a very basic PAC management tool, the control strategy files were studied in detail, and the info gathered is the following:

  • All files with extension .crn1, .crn2, .crn3, should have the same name as the "main" program
  • .crn1 file contains the line : FILENAME ." PNAME " ; where PNAME is the "main" program name. The rest of the lines of this file never changed when different programs were created
  • .crn2 files contain the tasks or "charts" names than composes a program, the variables to be used and I/O pin assignation
  • .crn3 files contains initializations for: tasks, variables and I/O hardware
  • There should be a .ccd file for every task that composes a program, the name should coincide with the information contained in the .crn2 file

A sample control strategy "BLINK"... Read more »