Linux / Unix OPC?


My former customer needed to talk to their PAC controllers via ethernet from Linux. We accomplished the task by connecting to a predefined controller port and reading / writing to it from the Linux PC. On the controller side we ran a couple of charts collecting and setting the required data. Basic client/server - read stuff, dump it into an array, ship it over when requested. It works reasonably well but I consider it somewhat clumsy. And we haven’t found any better way so far. We considered using the scratchpad for brief period of time but it became very clear that was not a viable solution.
It appears that one ought to be able to write (any OS) native application able to connect to the controller via ethernet and get / set any data in memory with MMP (
So, 2 questions:

  1. Is there a better way than what we did? Linux Opto OPC server perhaps? Other existing Linux commercial software?
  2. Before I dig any deeper - I am curious whether there are any Linux / Unix users interested in having a native application capable of talking to PACs.




Hello Jiri,

Welcome to the forums! A few questions to try to get a 10,000 foot view of what you’re doing here:

[INDENT]0) What kind of data are you trying to get in/out of your Linux box? (What’s the big picture?)

  1. When you say “it became very clear that was not a viable solution” (using the scratchpad), do you remember how you determined that?

  2. Do you need OPC in particular? (I suspect there are better ways of approaching this problem.)
    Have you seen this OptoMMP/Linux toolkit?

There are a few other options that come to mind too, but I’d like to hear more about your “end goal” before I toss too much at you!

Thanks for the question.



Hi Mary,
the customer is using Gensym G2 ( to run a plant. G2 is a rule based environment bordering AI level of decision making. Their choice is to run Linux (robustness, stability, configurability, speed). The plant is 2000+ digital/analog points, in & out. They need to get all the data from the plant in a regular interval and control the process. G2 does most of the decision making. They run a few PID loops but most of the calculations and decisions are done in G2. They also need to gather historical data, again, G2 can interface to Oracle and store the data there.
I can’t exactly recall why the scratchpad didn’t cut it but at the time it was pretty clear. I think (really I think) that it had to do with having to move the data to scratchpad and then move it again through the port. So why not just open a port and run it straight through it, no middleman? I think.
I don’t need OPC and frankly, the idea scares me but it seems there are people fond of having a ‘generic’ interface to ‘any hardware’. I have had enough bad experiences with COM/ActiveX/Corba to make me a bit uncomfortable. I like simplicity, from my very quick glance OPC specs do not seem to fulfill that wish.
I have stumbled upon the MMP specs my post links to (your OptoMMP/Linux toolkit link errors out for some reason, I think it probably points to an obsolete driver from 2003 - does it?). MMC doc appears to be a complete spec one could use to write a complete “PAC to anything” bridge, including the ability to configure the hardware as well as read/write the IO.
My history - I have seen Opto for the first time in 1994, using serial Mistics and dos software with yellow boxes :). Even then I thought it would be cool to port it to Unix but never had the time to do it. Chances are I may have time in foreseeable future, I am expecting such effort would probably take at least 12 - 18 months full time (I am well versed in software design as well as several high and low level languages). My former customer would probably jump on the opportunity to use such bridge, I am not sure whether it would be usable to others. I wouldn’t expect Opto official support but having full specs would just be awesome. That’s where I am coming from - reasonable for a 10k view? :slight_smile:
Thanks for the reply, feel free to throw as much at me as you want, I can take it :slight_smile:



OK, as soon as I pushed the button - I found the OPTO MMC Linux toolkit - seems very promising - from a quick glance through the MMC protocol doc - there are 2 parts of the memory, the processor (that’s where the charts run?) and the IO memory. This toolkit - does it let you talk to both parts? In another words, can you configure as well as read/write IO.




Hi Jiri,

Thanks for the additional details. To answer your question about configuring and doing a read/write to I/O: both of those are done via the mem map. In fact, that’s how the “part that runs the charts” accesses and configures the I/O: a built-in chart that initializes I/O by writing appropriate values to the mem map.

Which leads me to my next questions: if you’re getting rid of middlemen, and your G2 does most of the logic, do you need the charts? Because, as it sounds like you discovered, to access the variables in your charts, the official recommended way is by writing those values to the mem map’s scratch pad area to be read by your G2, etc., which is an extra step. If you DO use the charts for logic… that logic could also PUSH data to your Linux box (which might be something like what you did in your earlier client/server app).

There are several ways to push data, including the method behind our site that’s been running in one form or another since circa 1999. Go to, ignore the security warnings and check out the “Concept” tab to get a feel for what I mean. Keep in mind the code is much simpler now.

You could also use the built-in UDP streaming feature to send I/O data at regular intervals and have your G2 parse that stream packet. Depending on how much and what data you need from your SNAP-PAC-R1 (I’m guessing?) I could throw a few more options at you!



Hi Mary,
do I need the charts? Hmmm, questionable :). Yes I do - there are tasks to be performed on the controller itself or even down on the IO (PID loops, simple logic: if temp > 70 the close the steam valve, etc.). For the usual reasons of 1) why not run stuff on processor when one is available, 2) if the network pukes we better have a failsafe system that can self-regulate or shutdown if need to. Which brings me to the next question/dilemma: so I can get and set any IO I want to through the memory map and I am assuming that’s how Opto Control and MMI does it (fastest, most efficient way). How about the actual programming? Do the charts live at the same place, are they readily accessible? In another words, with the available documentation, could I emulate the IO config as well as writing/downloading/running my own strategy? I believe in the old days this used to be accomplished by using Forth words, is it still the case? I know, I am digging too deep now but I am curious whether it would be doable to create a complete Linux / Unix based programmable system, no Windows needed? Well, I know that anything is doable, would it be doable with the available open documentation? Yes, it was R1 I have dealt with the last time :slight_smile:



Hi Jiri,

Excellent, I’m glad you’re taking advantage of the distributed logic for just the reasons you mention: network could go down, self-regulation, etc. If you were NOT using chart logic at the I/O then you could (in most cases) just use a brain, like and SNAP-PAC-EB rather than your SNAP-PAC-R1.

Since an R1 is a controller + brain, the answer to your “do the charts live at the same place” is yes, they’re both on the R1. And the mem map is the glue that connects them. (If you had an S1 + EB1 the answer would be no: charts run in the S1, IO including PID loops happen in the EB1.)

You certainly would NOT want to write your strategies using anything but PAC Control, which is only Windows, so you can’t get away from Windows completely and keep your charts/strategies. Once they’re written, however, you could download and start your strategy/strategies via Linux without too much programming. The strategy is still Forth as you mention, underneath, although not EXACTLY the same Forth as what you might’ve used in OptoControl (since how we handle communication, I/O, etc. has changed). So Forth words or init files or custom drivers that worked w/OptoControl would NOT work with PAC Control.

Pretty much the only thing Forth-wise that’s officially supported/documented in PAC Project would be setting values for variables, which goes with what you might’ve seen when configuring a variable, the: “Initialize on strategy download” option. The corresponding Forth code is described in form 1700 (just search for that number on our website or it’s also under Help->Manuals->User’s Guide in PAC Control). If you search for “download options” in that form then scroll up a bit, you’ll see where all that syntax is documented:

A note on your MMI question: PAC Display has an option to access I/O either through the control engine or directly through the I/O Unit’s mem map (which is “better” varies depending on your situation).

Keep those good questions & ideas coming!



Hi Mary,
thank you for your excellent help. Although I think you’re somewhat taking the fun out of it by saying than one definitely should NOT write the strategies by using anything else but Opto Control (real programmers chisel their bits straight into silicon). It might be fun to get hands dirty with FORTH, it’s a worthy environment. You are a gold mine of good info, thanks a bunch. It definitely looks like a project I would like to pursue once I have time to do so. A simple IO bridge (get/set) would probably be a good start and a good way to get closer to the hardware. Then upload / start / stop strategies and by then I may feel dangerous enough to throw in some real programming.
Now, for the million $ question - am I the only one (other than my former client) who’d like to see Unix/Linux version of Opto Control?