Free HMI/Process control software

J

Thread Starter

Jim

<b>Moderator's note: Control.com does not usually post messages promoting products or product announcements. This looks to be a real open source product where no one is making money so I am making an exception.</b>

Hi,

after this announcement is related to a product which is completely free and where sources are available to the public. I hope it is not misunderstood as commercial/spam.

Several years of development now leaded to an almost complete version of the free HMI/Process Control/Visualisation software package OpenAPC. It offers several applications that contain probably all features that are necessary for professional or advanced usage. Within this package "ControlRoom" software components cover the HMI/process control part:

- easy to use GUI-designer: the HMI can be created within a WYSIWYG editor directly, all relevant UI-elements are supported, additional elements are available via external plug-ins

- integrated support for data logging

- integrated and easy to use support for user management: users can have different roles and privileges

- support for touch-screens: input via integrated on-screen-keyboard is included

- integrated plug-in mechanism: many ready-to-use plug-ins and drivers for motion controllers, robots, field buses and other hardware are already included

- simple programming: elements can be concatenated via an easy to understand, graphical wiring diagram

- script programming: processes and logic can be controlled via included Lua and IL (Instruction List) interpreters

- advanced programming: several possibilities to attach own applications, plug-ins and device drivers in different languages like C, C++, Java and others

- open architecture: all programming interfaces are open and fully documented; the SDK contains several plug-ins and drivers as source that can be reused for own applications directly; creation of own plug-ins that integrate seamless into the whole application and that access special/own hardware can be done easily

- platform independence: the software is available for x86, ARM, x86_64 platforms and Windows and Linux operating systems

- slim, customizable runtime package for usage also on weak embedded hardware

More information are available at http://www.openapc.com , the software, manuals, example projects and the SDK can be downloaded for free at http://www.openapc.com/download.php

But more than this the full OpenAPC package contains some additional, specialised tools:

CNConstruct - a CAD-application to create complex CNC data easily that can be used within an OpenAPC project

BeamConstruct - a specialised CAD-application that can be used for laser marking applications and which can be used for all kinds of laser processing (like laser engraving, welding, cutting, 3D rapid prototyping,...); more information about BeamConstruct can be found at http://www.lasermarkingsoftware.com

Comments, feedback, suggestions and contributions are highly welcome!

Kind regards

Jim Hart
 
Hi,

I already know PVBrowser, we checked it out earlier to find out if both applications could work together or at least could be connected via a special interface.

But to be honest: we did not made very much progress there, until now I (personally) didn't fully understand how/where PVBrowser accesses the hardware to perform its control tasks/how it communicates with the outer world/how special hardware drivers could be added.

Jim
 
> until now I (personally) didn't fully understand how/where PVBrowser accesses the
> hardware to perform its control asks/how it communicates with the outer
> world/how special hardware drivers could be added.

We use a daemon (background process) for handling hardware interfaces. The daemon(s) will read the hardware (PLC/fieldbus system) and write the result to a shared memory. For sending we use a mailbox between our pvserver and the daemon.

See:
http://pvbrowser.de/pvbrowser/pic/prinzip.png
 
> See:
> http://pvbrowser.de/pvbrowser/pic/prinzip.png

I do know all these broad descriptions and pictures. But where is a exact specification of the interface? A specification that describes the structure of the shared memory and the messages detailed?

Or in other words: where can I find a description that really goes into detail and therefore would be helpful when I want to implement an own daemon that communicates with PVBrowser?

Jim
 
> Or in other words: where can I find a description that really goes into detail
> and therefore would be helpful when I want to implement an own daemon that
> communicates with PVBrowser?

We have a C++ library for serverside programming.
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classes.html

There you find the classes for the shared memory and the mailbox.
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSharedMemory.html
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlMailbox.html

Also a class for modbus is in there.
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlModbus.html

And a convenience class for connecting the data acquisition to a pvserver (encapsulating shared memory and mailbox)
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlDataAcquisition.html

You will find more classes there also for other protocols than modbus.

Now we have the package
http://pvbrowser.de/pvbrowser/tar/pvbaddon.tar.gz
This package includes "daemons" for fieldbus systems and some more additional software.
The daemon for modbus can be found in directory
pvbaddon/daemons/modbus/client
in the above package.

This daemon is build on top of the rllib (see above). It will read an INI file which describes what you want to read from modbus.
You can now simply start
"modbus_client your_inifile.ini"
and it will cyclically read modbus and write the result to the shared memory.
A second thread within modbus_client will wait on the mailbox for data to be send to modbus.

Also read starting from page 96 "Data Acquisition" in
http://pvbrowser.org/pvbrowser/doc/pvb.en.pdf

For further protocols you might use modbus_client as a starting point for your own daemon.
You will probably use rllib in there.
rllib also provides a class for communicating over serial lines, network communication, portable thread support, handling ini files, ...

From your pvserver you will use
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlDataAcquisition.html
(also from rllib) to read the shared memory and write outputs through the mailbox into the daemon and from there to the fielbus.
 
Sourcecodes with comments are not exactly what I would call an interface specification but ... well, we'll try to dig through the code to see what is possible to interface it to components of the OpenAPC package...

Jim
 
P
May I suggest that the issue with free software is often the documentation and support. If your project is a cheap one, you should
still ask the question about the cost of problems and the time to fix them as well as the longevity of the application. Computers and equipment breaks and the replacement is not quite the same. In addition, changes are required and I have seen it take a lot of time for the original programmer to get into the code, let alone someone else.

What is fun in the beginning can be a pain in the long term. I have seen this so often.

--
Peter Clout
Vista Control Systems, Inc.
[email protected]
http://www.vista-control.com

 
T

Tallak Tveide

I would see this the other way around.

Many large open source projects are both better technologically and better documented than their non-free counterparts.

In general the quality of the software, including documentation, depends more on the number of users than the commercial model behind it. So for example Ruby on rails would be quite equal to Microsoft .net and their web offerings in terms of quality and documentation, both being systems with a large user base.

When we are talking about automation we are unfortunately somewhat on the other side of the spectrum. There is a lot of fragmentation due to vendor lock in and proprietary hardware that makes this even worse.

What this means is that you $100.000 system is likely to have poor documentation and also quite a few deficiencies and even bugs, and you will be reliant on a good relationship with the provider of your software to achieve your goals. Should you provider fail to provide this service you are basically f*^**^*d.

Some reasons that this could happen is: 1. The provider lost market share and is no longer able to maintain its support organisation. 2. As you enter the sustaining phase of a project there is no sound business model to ensure that you get support and that the software provider is still making money (the reason why you must buy yearly expensive 'upgrade' packages that provide little value in the upgrades themselves) 3. The provider is bought by a competing system and the software discontinued. 4. The provider is unable to build the necessary organisation to provide adequate support

Open source software does solve these issues, but you do get other issues instead, mainly the cost of maintaining competency in house when you enter sustaining.

In any case a difficult decision to make...
 
> May I suggest that the issue with free software is often the documentation and support.

Yes, but that's where we try to be different to the other projects:

- we provide a solution in free software too

- we offer a (hopefully) complete users manual at http://www.openapc.com/download/manual.pdf

- we offer a complete programming interface specification at http://www.openapc.com/download/sdk_manual.pdf

- our (programming) interfaces are backwards-compatible until version 0.1 of the software (which is the very first release of it)

- we plan to offer a "stable" branch which will be a special release that does not offer any new features but contains bug fixes (so that customers do not have to fully verify that version again before going to production)

Did I forget anything that is important for professional end-users?

Kind regards
Jim
 
P
I still maintain that sufficient documentation in a software product, as opposed to software that is installed as part of a project, is in the interests of the vendor as otherwise the user will not succeed in
building their application.

Of course users come with all levels of computer knowledge and skills. There are some that are very comfortable with any software and like to have the sources. In fact they could write the application using basic languages and programming facilities. At the other end of the spectrum, there are users with little such knowledge and skills and these users need someone who will answer the phone and talk them through the issue. We have even had a user who needed to be told what and where the TAB key was on the keyboard. Thus the level and quality of support also depends on the user. If the open software is on the Red Hat model, then the support is there and people are paid to provide it.

I like the idea of bug fixes only. Of course, it is essential to ensure compatibility between releases and also that network communication will work across releases. However, stable feature versions will likely get harder and harder to maintain as the number increases with time.

Sometimes upgrades that can not be avoided in the operating system or
the hardware force changes in the application and this usually means a new release.

So, no one solution is right for all as the original email made clear. Some people are lucky to have the time and salary that allows them to write, support and distribute open software.

--
Peter Clout
Vista Control Systems, Inc.
[email protected]
http://www.vista-control.com

 
Hi,
Do you know PROVIEW ?

you can take a look at http://www.proview.se/v2/

very nice HMI/ web HMI/ soft PLC/ soft multi-loops Process controller /scada free and open source (under linux)

I use it for one year in my laboratory with my students with processes like for instance Eurotherm T2500 controller of a distillation column over modbus TCP

Regards
/Bruno
 
Hello,

-it is possible to access Remote OPC using pvbrowser OPC client?? I have RsLinx Gateway OPC Server from Rockwell Automation and I want to access that OPC server from a PC that is in the same network with the PC running Gateway. (the Manager wants to see process trends on his office computer).

best regards,
Alin
 
>Do you know PROVIEW ?

Yes, we checked this out before but until now we don't see a possibility to connect both projects to interoperate between them. Maybe somebody has an idea where both could benefit from each other....
 
I am very glad to find this thread and, and would like to leave a brief opinion.

I have been for some years working in ScadaBR ("powered" by the excellent mango M2M) and think that, although there are still a lot of failures to point at, open-source scada is evolving very fast and already has many success stories.

Unlike commercial SCADA which necessarily need to fight one another, open-source tools can "mix & merge" in a very positive and productive way. I can cite Luciol, mango and OpenScada which all had huge contributions to ScadaBR. In the same way, we wish to have Siemens, CAN and Profibus drivers incorporated very quickly, also because of open-source "mass effect".

By the way APC looks a nice piece of work. Thanks for the posting.
 
J
Even if late, I'd like to chime in and mention there is also Eclipse SCADA (http://eclipse.org/eclipsescada/), the successor of the openSCADA project (http://openscada.org), written in portable Java.

Totally free to use, even if you would integrate it into commercial projects.

The head developer is the guy who developed the Utgard OPC library, which for instance is also used in ScadaBR.

There is also now a very nice 60870-5-104 implementation (both master and slave), which can be used standalone.
 
Top