Control.com - Nerds in Control

http://pvbrowser.org
is a Software for Process Visualization, HMI and SCADA.
Now we are working on the integration of PLCs and Fieldbuses.

We already have interfaces to
- Modbus
- Siemens PPI / Industrial Ethernet
- CANopen
- Reflective Memory
But there are more out there.
e.g. Allen Bradley PLCs

These interfaces are implemented in our rllib
http://www.pvbrowser.org/pvbrowser/sf/manual/rllib/html/classes.ht ml

Who is willing to support us with extending this library?

License: rllib could be put under LGPL

That's a really good question.

Wouldn't it be great if all the various truly Open Automation projects could somehow manage to be reading off the same page to prevent the duplication and incompatibilities that burden the commercial efforts? Room for different philosophies, certainly but perhaps a framework that would insure compatibility and interoperability? At least on Linux where it's easiest to acheive? How could we achieve such a thing? This would pave the way for greater vendor involvement which wouls speed things up.

Regards

cww

The idea behind rllib is:
- have a OS independent lib for control/automation
- It works on Linux/Unix, OpenVMS and Windows
- All basic classes needed are contained there
(Socket, Mailbox, Shared Memory, Thread, Serial, ...)
- Communication to hardware may be implemented on top of Socket, Serial, ...

Now that we have all basic classes to communicate with our PLC, Fieldbus, CIF-Card...
we can put everything together:
We can generate a daemon program from a small ini file, which will write all inputs cyclic to a shared memory. Also the daemon will wait for outputs on a mailbox.

Because all input signals are available in the shared memory, several applications (visualization, soft plc, techn. model) could read from it simultaniously.
Also many processes can write to the output mailbox concurrently.

This is how I designed rllib.
Discussion welcome.

regards:
Rainer Lehrig

The concept makes sense to me, my little demo PLC and MAT also work this way, though not necessarily OO. The problem is that we now have several maps. What we need is a single schema that we could publish and vendors could write to, if they felt inclined to do so. Two common if not exactly identical examples are OPC and Modbus though at different
levels. A vendor can (at least theoretically) write one driver that interfaces to anything written for that common structure. Since all seem to agree that the logical interface between the solving software and tbe IO is a shared memory map, this would seem a compelling level to
standardize on. A POSIX shmem and semaphore synchronization scheme might be one way. My own preference would be for a "raw" mapping with sync flags in the map to make it easier for RT and hardware without memory management. But _any_ standard way would be better than each project rolling their own, even if it restricts portability. And the time to talk is now, before anything is entrenched. I feel the real goal for Open Automation should be to learn from and correct the errors and
difficulties that the proliferation of proprietary "standards" have so painfully demonstrated. And yes, this is an excellent topic for discussion. We have to make it as easy as possible for people to do the right thing.

Regards

cww