Control.com - Nerds in Control

I have a new release in the Free/Open Source (GPLv3 license) automation software project that I have been working on that may interest some people here. This release is a demonstration version of a web based HMI. I call it a "demonstration" version because it isn't integrated into the main MBServer automation platform yet. This version uses a stand alone server that is intended to support web page development. Integration into MBServer will be in an upcoming release. This should be of interest to anyone interested in web based HMI systems.

What is included in this release is the following:

- A stand-alone web server less than 200 kbytes in size. The server also supports an AJAX protocol to communicate with a web browser to provide continuous live updates.

- A sample client web page.

- A set of Javascript libraries for the web client to provide the client end of the protocol as well as control of the screen elements.

The web client demonstrates push buttons, pilot lights, numeric displays, text displays, dial and column indicators. It also has a pair of tanks with liquid flowing back and forth between them.

There are also event and alarm screens. The tank demo creates events, and the push array creates alarms.

The graphics (pilot lights, tanks, pump, piping, gauges, etc.) are done with SVG. The push buttons are done with XUL. The events and alarm screens are done with HTML. Client scripting is done with Javascript. There's no Flash or Java involved.

The package can be downloaded from Sourceforge at:

http://sourceforge.net/projects/mblogic/

Click on the Download Box, and either pick
"mbhmi_2008-10-26.tar.gz" from the "additional files" list, or go to the "Browse all packages" link and select it from there.

If you go to "Browse all packages" you have a choice of "tar.gz" or "zip" versions. The "tar.gz" version uses Unix new line characters, while the "zip" version uses "MS-DOS" (Windows) newlines. This only makes a difference if you want to view the source code.

Unpack the files into a directory. It will unpack a bunch of Python (".py") files. That's the server. It will also create a subdirectory called "hmipages" which contains the web page and associated files.

To run the server, you need Python 2.5. If you don't have that, it can be downloaded (for free of course) from http://www.python.org To run the server, type:
python hmidevserver.py

Or, if you are using just about any OS except MS Windows, you can make the file directly executable (for Gnome, right click, choose "permissions" and select "Allow executing file as a program) and run it as:
./hmidevserver.py
or just double click on the file.

The web page is compatible with Firefox and compatibles. I've tested it with Firefox 3.0.3 and Epiphany 2.22.2.

The url for the web page will be:
http://localhost:8503/hmipages/hmidemo.xhtml

Make sure you have Javascript enabled.

It *won't* work with Microsoft IE, as that doesn't support SVG graphics (Microsoft's web browser technology is still about 8 years behind the rest of the industry). There's not much point to a web based HMI that's limited to text only, so IE is not a realistic support target.

Documentation is at: http://mblogic.sourceforge.net/MBHMI-Intro.html

When this is integrated into MBServer, the potential applications for this include its use as a stand alone web based HMI that can be interfaced to PLCs or other devices. When the soft logic libraries (currently under development) are integrated, this will be the HMI component for a complete soft logic control system.

If you haven't seen something like this before, this is a *live* web page that updates itself continuously, not static text. It uses a special protocol to update just the parts of the page that need to change, without reloading the entire screen. It's all based on open web standards, and doesn't need a special development or programming software to modify it.

Comments, suggestions, criticisms, etc. are appreciated of course.

Awesome. I hope to get a chance to check it out.

"It *won't* work with Microsoft IE, as that doesn't support SVG graphics."

What happens if you add the (no longer supported) Adobe SVG plug-in?

-James Ingraham
Sage Automation, Inc.

With regards to how IE handles SVG, the answer is a bit more complicated. There are two ways of using SVG with a browser. One is as external graphics files which you load just like a PNG. This gives you high quality scalable graphics in a very compact form. The other is as in-line graphics which exists directly in the web page.

For this sort of application, the in-line SVG is the easiest and most practical I'm not even sure it could be be made to work the other way.

HTML 4 doesn't support in-line SVG (that's scheduled for HTML 5). You need to use XHTML for that today. MS IE doesn't support XHTML (according to the W3C FAQ). There are ways of tricking it into loading XHTML, but I doubt the Adobe plug-in would then know how to intercept the in-line SVG. Renesis also has a plug-in, and I imagine it has the same limitations. I also don't know if you can manipulate the SVG after it has been loaded into a plug-in.

I thought about the plug-in issue, but my own conclusion is that if you are going to download and install a special plug-in (assuming it can be made to work given the above), you might as well just download and install a browser that doesn't need a plug-in. Given the applications that I envisioned for it (machine HMIs), that's not an unreasonable requirement.

There's two other minor areas that would be a compatibility problem. One is that I used XUL buttons for the push buttons. These are Gecko specific, and so would only work on Firefox, Epiphany, and Flock. However, they are easily replaced with more SVG and a change in the command used. It basically involves modifying one line of HTML for each button. I didn't do this because using the XUL button was easier than trying to draw a push button that looked like a push button as opposed to another type of pilot light. That is more of an artistic shortcoming on my part than a technical issue.

With this minor change, it should work with web-kit browsers (Apple Safari, Google Chrome, newer versions of Konqueror), and with Opera. It *may* work on mobile phones, but I don't know enough about that area to know what limitations those browsers may have other than that many of them support some form of SVG.

Another area that can be a compatibility problem as far as MS IE is concerned is that there are basically two types of Javascript - Microsoft Javascript, and the standard form that everyone else uses. That can be coded around, but I didn't do that (since there was the SVG problem anyway).

Cross-browser support is a good idea in general, but there are some practical limitations. It is probably feasible to make a web based HMI that works in all browsers except MS IE without too much effort. There is a limit to how much effort it is worth putting into it though.

Professional web developers despise MS IE not just because it does a poor job of following the W3C standards, but also because every version of it is different from every other version.

Typical practice for a web developer is to develop the web site using Firefox. It follows standards closely, documentation is good, the development tools are good, etc. When they are done they then test against Safari and Opera, and possibly against Konqueror and a few others. If they know what they are doing, they usually just need just a few minor CSS tweaks. Then comes the hard part. They have to test against MS IE and come up with different hacks for each version. IE 5.5 is different from IE 6.0 which is different form IE 7 which is different from IE8. It's a mess. Have a look down at the bottom of the this page an you will see a like to "Internet Explorer 6.0 Fix". It looks like Control.com has a problem with MS IE 6.0.

Having said the above, in the end it is just a web page. For that matter, you don't have to use SVG. You could just just plain HTML. You just wouldn't get the fancy graphics. That's how the events and alarms screens work.

What SVG does for you is it gives you graphical elements that you can develop with just a text editor. You don't need any special programming software. If you want to add a pilot light, you just cut and paste one or two lines of text, and add two lines of Javascript to the web page.

You could also use Flash. I was working with the Likindoy SCADA team on this concept. We each worked on our own implementation however. I used SVG while they were working on using Flash. The Likindoy team has put their end of the project on the back burner for now, so they don't have anything to demonstrate, but their approach is completely feasible as well. You have to know more about what you are doing to use that approach though. It may be better for really graphically intensive screens however.

I wonder what happened to the Rockwell patent that purports to cover any use of a browser with PLC data?

Regards

cww

"With regards to how IE handles SVG, the answer is a bit more complicated."

Wow. No kidding. I'd have settled for, "No, the plug-in doesn't work." Interesting stuff.

"...if you are going to download and install a special plug-in... you might as well just download and install a browser that doesn't need a plug-in."

Good point. I was just curious.

"...I used XUL buttons for the push buttons... However, they are easily replaced with more SVG... That is more of an artistic shortcoming on my part than a technical issue."

Would a button drawn in Inkscape work? One of my guys is pretty darn good at that kind of thing, and we'd be happy to build a button for you.

"Cross-browser support is a good idea in general, but there are some practical limitations."

Indeed.

"Typical practice for a web developer is to develop the web site using Firefox."

Funny, it seems like a lot of websites STILL haven't heard of Firefox. I always find it especially hilarious when they tell me my browser isn't supported so I should get Netscape.

"When they are done they then test against Safari and Opera..."

I would say they SHOULD, but I doubt that too many developers test against Opera. Even Safari is often left out. It's shocking how many sites won't even TRY to load if you're not using IE.

Granted, this has gotten better as Firefox's popularity has risen. I find that most sites that work in Firefox will work in Opera (my browser of choice), though I still occaissionally have to tell Opera to identify itself as Firefox or IE.

And I frequently find that having my screen set to 120 DPI screws up even sites that otherwise work well in multiple browsers.

"IE 5.5 is different from IE 6.0 which is different form IE 7 which is different from IE8..."

Yeah. Although I get the impression that most web developers work to what is current and anyone using an old or beta version can go hang.

"What SVG does for you is it gives you graphical elements that you can develop with just a text editor."

This is a double-edge sword. I've made GUIs from text based code and from a form designer, and I'll take the form designer every time. Text certainly has it's advantages. Like it's sometimes easier to create widgets programmatically if you've got a gazillion nearly identical ones. This kind of goes back to my earlier question of can you use an SVG file created in e.g. Inkscape?

From a market perspective, I doubt that you could get serious traction against WonderWare / Intellution / RSView / etc. without a GUI designer.

"You could also use Flash."

Flash has the distinct disadvantage of not being FLOSS. They're working on it, with ActionScript being opened up and all. But I'd rather an open format like SVG. Plus, like you said, it's nice that it's just built in to the browser and doesn't require a plug-in.

Pretty impressive work you've done there.

-James Ingraham
Sage Automation, Inc.

In reply to James Ingraham: I'm not 100% sure the plug-in won't work for this, I just have serious doubts.

Oh, and in the news today, Mozilla has started development releases of a version of Firefox where SVG works directly in regular HTML rather than needing XHTML. There's not much difference between the two other than XHTML is (by design) a lot fussier about not accepting any markup errors.

You mentioned that you liked Opera. I just downloaded and installed it and pointed it at the dev server. Everything seems to work, except of course there's no push buttons (because of the way I did them). All the SVG and HTML shows the same as it does in Firefox, and the Server Message ID numeric display is incrementing as it should (which tells me the client is scanning the server). The menus works, and the normal start-up events are in the queue on the events page.

I looked at Opera once, some years ago. I've never used it for anything though and I didn't do any of this work with it in mind. However, there it is looking just the way I expect it to and with everything working except for the one thing that I knew wouldn't work (the XUL buttons). That's how web standards are supposed to work. It's too bad that Microsoft can't figure out how to write a browser that's half as good as Opera or Firefox.

If you want to try drawing a button in Inkscape, I would like to have a look at it to see if I can figure out how to cut it out of the Inkscape file to use it. By the way, as well as the four push buttons on the main screen, I need a push button for acknowledging alarms on the alarm screen (that's a XUL button too) if you feel like being creative.

The problem with drawing something in a drawing package like Inkscape though is that you end up with about 50 lines of XML to define a circle. That's why I did everything by hand with basic shapes. Event the toothed graphic gizmos in the background and in the heading were made that way before being converted to PNG files. I'm actually better at drawing things that way than I am using a drawing program.

Here's an example of what is involved in replacing the XUL with SVG.

Here's the original XUL button, which you can see that I've commented out.

<!-- 
    <foreignObject x="100" y="35" width="200" height="200">
       <html:div>
      <xul:button flex="1"  onmousedown="MBHMIProtocol.WriteImmediate('PB1', 1);"  onmouseup="MBHMIProtocol.WriteImmediate('PB1', 0);" label="PB-1"/>
      </html:div>
    </foreignObject>
 -->

Here I've replaced it with a circle drawn in SVG (I copied this from a pilot light). I've just tested it, and it works. The problem is that it looks exactly like a pilot light.

    <svg:circle cx="125px" cy="45px" r="35px" fill="violet" stroke="black" stroke-width="5px"
     onmousedown="MBHMIProtocol.WriteImmediate('PB1', 1);"  onmouseup="MBHMIProtocol.WriteImmediate('PB1', 0);"/>

I think I would also want to animate it somehow by changing the fill or stroke property, so that you see it do something when you click on it. That should be possible, especially if I add another simple Javascript function to handle push buttons. If it wasn't for the need to give operator feed-back to a click, even a photograph of a push button would work.

To address your comment about making the web page with SVG in a text editor, what I meant was you don't need a special IDE and compiler. You don't have to be a software developer to figure it out. To do the quick push button experiment that I mentioned above, I just opened the page with a text editor (Bluefish), and did a quick cut and paste and then clicked "reload" on the browser. It took me less than a minute. If you know how to make a web page (and I think that's a skill we all need to learn anyway), you can make a web based HMI.

I talked to a professional web developer (someone who does this for a living) about drag and drop web development tools. I wanted to use something like that if it were available. He couldn't recommend anything. Apparently, that's just not how web pages and web sites work these days. They're generated dynamically from templates and style sheets.

You may have noticed that most of the "look and feel" in the demo page that I made isn't in the web page itself. It's all in the CSS file. That's *why* the same web page works in both Firefox and Opera.

However, you wouldn't have to create a whole new web page for every application. You would take an existing one and modify it. You might customise it a bit, but most of the work is deciding how many buttons to put on it and where to put them.

Having made the demo web page, I can say that what I would really want is something to tell me what the coordinates are for the mouse pointer while I am laying out the page. That I know is just some simple Javascript to track the mouse movement. I plan to add something like that to the demo page where it can be commented out when it's not being used.

As for whether I could compete directly against Wonderware or RSView or WinCC, that's not what I'm trying to do. This is more directly comparable to the small HMI panels used with PLCs. I need something like this to provide a simple HMI capability for the overall MBLogic project that I am doing. It's also useful as a stand alone HMI in typical machine control applications. In other words, this is directed towards what 95% of people want rather than the 5% who need all the features of Wonderware.

I appreciate your comments on this. I'm looking for feedback and suggestions. If you come up with a push button drawing, I would like to put it into a new release to replace the XUL buttons. Then if anyone has a Mac and can test the revised page on Safari, I will be able to list all the major browsers (bar one) as supported.

Way to go Michael!

Regards

cww

Hi!

I have been working on something similar based on ruby on rails. Your work is very interesting and very impressive - a very clean and in-depth implementation imho.

I do believe that there is a future for free open-source HMIs based on Linux clients with Firefox in kiosk mode, connected to free open source web servers.

My thought regarding connection was to write all PLC tags to a database (like inductive automation) and serve all HMI pages off this database. Separate IO processes will connect to PLCs using Modbus to update the database in the background (only option as of yet in Ruby). Using python of course it seems you have some more options (Modbus, OPC...).

My solution is geared more towards splicing together different svg images created in Inkscape with a simple code backend to create animations.

It seems your project is a lot more mature than mine, but I think the point is proven that this is a architecture that can provide similar or improved performance compared to top HMI systems today.

I'm not sure about python, but with rails you get redundancy and scaling for almost free. In both systems you get version control of your files (being text based, using git), tools for deploying, monitoring your servers, automated testing frameworks, language translation and much much more.

I have thought about replacing the PLCs as well, but I guess this is too controversial at the moment. ;-)

I will be watching your project closely, feel free to contact me if you like. You'll find an address at http://osterhus.no

My implementation will be to add this as another protocol to the MBServer package. I don't run a separate web server. It will be built directly into MBServer. I already have two web servers built into MBServer, one for the on-line help, and one for an existing web service protocol. If you have a look at my web site at the very bottom of this page,

http://mblogic.sourceforge.net/AppExamples.html

you will see a block diagram of MBServer under the title "Stand Alone Soft Logic System". The logic engine and HMI modules aren't integrated in yet, but otherwise that's what it looks like at present. The logic engine is currently released as a separate library, and the HMI protocol will be copied from the package that is the subject of this discussion.

The common data table is a memory structure, not a database. I am basing the concepts on a PLC rather than on a large SCADA system. One of the software modules in the dev server translates the tag names used by the client to data table addresses (that's the purpose of the config file). The modules in the dev server were written with the intention of being able to integrate them into MBServer with little or no change.

I am emphasising simplicity and ease of installation over scalability. Scalability is not a real problem in the areas of application I am focused on. As it is, using the Modbus protocol it can transfer about a million registers per second when connecting to localhost on a fairly low end single core PC. It would be slower than that over a real network, but it still has plenty of capacity for typical applications. When used to support an HMI, server load would be negligible (probably too small to measure).

MBServer is based on Twisted, which is a communications framework. That lets me integrate everything into one program, which I think simplifies things a lot.

I've used Inkscape to create SVG graphics. The diagrams on the web page that I've pointed out above were created with Inkscape and then converted to PNG (so that people with archaic browsers can see them).

I think that using a drawing program will work for static graphics such as creating backgrounds or overlays that don't change. It's not so good for animating or changing properties though. You end up with a bunch of "path" statements that don't give you anything obvious to grab onto. I think that for things like pilot lights it's actually easier to create simple SVG in a text editor using basic circle, rectangle, polygon, text, etc. commands.

All the graphics in the demo were created by hand out of simple elements. Even the dial gauge was created that way. It's not actually that hard to do.

You could of course combine the two approaches. You could create the static parts using a drawing program and then add the basic geometric shapes that you want to change the properties of.

Here is another Open Source HMI/SCADA system.
http://pvbrowser.org

"pvbrowser is an application framework. It provides a specialized browser for the client computer and an integrated development environment for creating servers that implement your visualization. It also provides data acquisition programs (daemons) for a lot of protocols that connect the real world with your server.

You can surf these visualizations as you do with an ordinary web browser. Many users from different places can use the visualizations at the same time. This can be limited to your local area network or across the internet."

SVG graphics is one of it's capabilities
http://pvbrowser.de/pvbrowser/doc/manual/en_p33.html