In reply to RK Sastry: What you've described is I think more closely related to "augmented virtual reality". Although in this case, it has more "reality" and less "virtual". It also has some resemblance to remotely guided vehicle systems.

That's about as far as I would care to speculate on it. I wouldn't be surprised though if someone at some university has created a system that as an experiment.

 

In reply to pvbrowser: Do you create the SVG artwork completely as custom art for each application then? That is, do you start from a clean page each time, or are you re-using anything?

I just had a look at your documentation, and you have some examples:

d->svgAnimator.svgPrintf("HelloObject", "fill=", "#000"); // set a property

You're modifying the "fill". That's what I do to control a pilot light.

d->svgAnimator.setMatrix(const char *objectname, float sx, float alpha, float x0, float y0, float cx, float cy);

You're doing a rotate, which is how I do a selector switch. I do an actual rotate transform instead of a matrix operation, but the end result is the same.

One difference in the approach that I am taking is that those code details are hidden out of sight of the person actually configuring the system (unless they want to open the file with a text editor and dig into the source code, of course). They just decide what tag they want to monitor and what sort of behaviour they want from it (pilot light, selector switch, dial gauge, etc.). Behind the scenes though, it's working with properties via the "id".

However, I think the actual SVG symbols that I've made would probably work with your software. When I've got everything running with the new system we may want to see if a common symbol format is feasible.

 

In reply to William Sturm: It works with user defined graphics. I got started looking into this because a user had a large project where he had drawn process diagrams (tanks, pipes, pumps, etc.) which he intended to use as backgrounds and was going to simply put the conventional operators on top. It was all very impressive looking. He was using Inkscape to draw the diagrams because that was the drawing program that he uses.

He sent me a drawing to look at because he had some questions about the application. I had a look at it and figured out that he could just animate the drawing itself instead of putting stock symbols on top of it. I made a quick demo out of the drawing and he liked it, his customer liked it, etc.

I've taken this to the next step, which is to repackage the symbols I've created for Inkscape. That's mainly just a matter of pasting the XML I already had into files with common XML boilerplate around them (a complete pilot light definition file is about 750 bytes, including comments).

As for using tag names like HTML, well that's how SVG works. It's just part of the web page. You interact with it the same way you do HTML. SVG has some attributes that regular HTML doesn't have, but for example, you can use CSS (style sheets) with it just like you do with HTML. In fact, some of the special effects that I use for SVG push buttons depend on CSS.

I'll explain some background about how the system works, as then my answer to your question may be more understandable.

Something to keep in mind during this explanation though is that the user interaction with the HMI web page isn't anything like how you would interact with a public web site like Control.com. There isn't any of this click a button, get a whole new web page interaction. Once you've loaded the web page once, you stay on the same page until you close the browser or deliberately reload it. The page simply changes itself dynamically just like a conventional desktop GUI program would. If you run the web page full screen (press F11) to hide the address bar, the user would have no way of knowing that the HMI is running in a web page.

There's several parts to the HMI. The server program sends you the web page, and it also communicates with the field device (e.g. PLC). The web browser runs the visible part of the HMI and talks to the server via an AJAX style protocol which runs in the background.

The HMI web page consists of several parts:

1) An HTML web page which acts as a container. This would be provided as a set of templates in different sizes and layouts. You can use these as is, customise them, or replace them with your own.

2) An SVG part which contains the graphical elements. This is the bit I've been talking about here. Again, a set of blank drawings (sized to fit the HTML templates) would be provided.

3) A Javascript library that implements the communications. The web page polls the server for new data, and writes any commands (e.g. push button presses) back.

4) A Javascript library that implements the HMI SVG object control. It has functions for things like pilot lights, dial gauges, tanks, etc. I'll get back to this shortly.

5) A Javascript library that handles alarms and events. There are pre-defined alarm and event "screens" or "layers" in the HTML part of the web page. You just give it a list of what alarm and event zones you want to monitor, and it takes care of the rest.

6) Some CSS files which provide overall styling (colours, fonts, etc.) and layout control. Again, you would use these as is, customise them, or replace them with your own.

7) Some files which act as data files to contain things like the texts of the event and alarm messages.

8) Some logos and icons are linked in from the web page template. You would provide your own (e.g. your own company logo, or something application related).

Up to now, you would have had to use it by cutting and pasting text from the documentation into the provided web page. I can now remove the need for that by using Inkscape to insert and position the SVG, and a form based program to connect the SVG to the Javascript. The part I was stuck on until recently was how to make the SVG layout easier.

The animation is done by the Javascript libraries. It takes two function calls to connect each SVG object to the communications system. One call to create a Javascript object, and one to add it to the "display list" and associate it with the address tag (the field device address). Since this is very simple routine boilerplate, this can be auto-generated from a form. That is, it just needs the name of the address tag with the data, the SVG id, and the behaviour (pilot light, dial gauge, tank, etc.). The system can then assemble all the parts together. I haven't written this part yet, but it's a pretty routine data entry type application so it won't take me too long.

However, when I say there is a function that controls a "pilot light", I'm really saying that there is a function that control the "fill" property of an SVG object. The "fill" property is the colour. The pilot light function doesn't really know anything about the SVG object, except that you want to change the "fill". I'm calling it a pilot light because that's what people can relate to.

If you draw a picture of a widget and associate it with the pilot light function with blue for off and red for on, then when the bit in the PLC turns on the widget is going to turn from blue to red.

There is nothing special about the pilot lights that I'm providing. They're actually just circles, squares, etc. with a decorative nut drawn around them. The pilot light function just changes the "fill" colour of the circle (or whatever shape is present).

I'm only providing some common items so that people who just want to use basic items don't have to draw their own. That's why I was asking about what people use (and I've gotten a couple of good suggestions so far).

So yes, the system is completely open and you don't have to use any of the symbols that I'm providing. You don't have to use any of the page templates that I will be providing. It's infinitely customisable, which is one of the major reasons I wanted to pursue this approach in the first place.

 

Thanks for the incredibly detailed explanation. It sounds like a very nice project, good clear documentation makes a huge difference. I have been learning AJAX and DOM scripting a little myself this year, it looks to be a great skill to have.

Bill Sturm

 

Does MBLogic have any other communication drivers besides Modbus? I would be interested in trying it out what you describe with some of my graphics I have, but I only have an Allen Bradley Micrologix 1400 with me. Am I correct in assuming the communication, web server, ad HMI client can all be run from a single laptop?

 

In reply to Bill Sturm: Yes, at its heart it's all just DOM scripting. I've just added a layer of software (in Javascript) on top of that so people don't have to learn what a DOM is.

If you are interested in the technical details, I have all the current documentation on line. I don't have the documentation for the Inkscape based method up yet, because I haven't finished writing it. I think there's at least 100,000 words of documentation on the current web site though.

For a basic overview, have a look at this page. It also includes a link to the HMI protocol specification (Cascadas).
"http://mblogic.sourceforge.net/mbhmi/mbhmiintro.html"

Then for information on how the DOM is manipulated, have a look at this:
"http://mblogic.sourceforge.net/mbtools/hmiserver/hmiserverintro-en.html"

(The forum software may insert spaces into the above URLs, so watch out for that.)

Everything is described with detailed examples because up to now the intention was that you would cut and paste the samples into a web page and then change a few things, and modify it to create your own. The new method is drag and drop, but what is happening underneath remains the same.

It took me a while to put together all the information that's on that web site, and I don't know of any place else that has this all in one place. I think you would find it interesting.

This is just a copy of the documentation that comes with the software. I use the embedded web server in each program to provide the on-line help facility.

 

In reply to Archie: I have drivers for Modbus/TCP and SAIA S-Bus Ethernet (this one is still being tested though, and isn't released yet). I don't have AB Ethernet/IP because that is a closed protocol and I can't get the specs for it (I'm not a licensed AB partner).

However, the software comes with a self standing demo, including a couple of HMI web pages and a process simulator program to control it. You can run it as is to see the features demonstrated.

It can all run on a single lap top. If you are just interested in the HMI aspect, then you probably don't want the MBLogic soft logic system. The MBTools package contains HMIServer, which has just the HMI features without the softlogic system.

You need to install the Python language run-time. If you are using the complete soft logic system, then you also need to install the Twisted and Nevow libraries. This is all explained in the installation instructions, which come as a PDF with each package.

The web site explains what each package does:
"http://mblogic.sourceforge.net/index.html"

The main download link is for "MBLogic_All", which is everything bundled together. There is a ".zip" version for MS Windows, and a "tar" and "tar.gz" version for Linux.

 

In reply to Curt Wuollet: People seem to look for a certain minimum amount of "bling". I "blinged" up the demo web page a while ago, but a day or two before I released the new version one person gave me a thumbs down review (on the Sourceforge user rating system) because apparently the original version didn't have enough "bling" at the time.

I think that too much detail in the graphics though makes an HMI hard to understand. People have done Phd theses on how to keep user interface graphics simple and understandable, but I still see process industry graphics where people have gone through great efforts to simulate glare and scratches on dial gauges.

I think there is a reasonable compromise between making something look good on the first impression, and making something work well for people who have used it for years.

 

Your comment about people implementing scratches on gauges in an HMI reminds me of a common joke between Engineers where I work. A couple releases back Solidworks released a new version which didn't seem to fix a lot of bugs, or make the program terribly faster, but the component prints (as viewed on your monitor) received virtual paper texture and wrinkles. Wow, your maintenance contract dollars hard at work....

KEJR

 

The Ethernet/IP protocol has recently become much more open. Rockwell software has posted a communication stack on sourceforge:

http://sourceforge.net/projects/opener/

Lynn Linse has a highly simplified break down of the byte stream required to read data with Ethernet/IP. I can't find the link right now,but a PDF file should be on his iatips.com site

I have a few older documents from back when you could download the spec from ODVA. The spec is useful for understanding the protocol, but horrible as a guide to implement a client.

Once I sat down and focused my time on it, I was able to implement the protocol in VB in about 3 days. Each controller family uses a different set of CIP commands, so implementing the SLC family is completely different from the ControlLogix family.

 

In reply to Archie: You had my hopes up for a moment, but then I looked into it some more. The problem hasn't been whether I could get my hands on a copy of the specs or some source code. The problem has always been the license terms. Those don't seem to have changed.

The terms are that you have to obtain a license from AB (through ODVA) before you can use the software. That is more or less the same problem as with the specs. Having a copy of the specs or the source code does not give you the right to use what they call their "licensed technology" (that is, their protocol). I'm not a partner or licensee, so I can't use either their specs or their source code.

I may not like it, but that's the terms of their license. I am going to assume that the terms of their license are legally enforceable unless I hear otherwise from someone who knows about such things.

What makes something open or not open is not how good you are at keeping it a secret. What matters is the terms under which you let other people use something. Other companies may have rolled out the welcome mat, but AB/Rockwell still have a big "keep out" sign posted on their front door.

 

Hi Michael

And I didn't say there was anything wrong with selling to people who think like crows are are attracted to shiny objects, if that's who is buying systems. The only sad part is if that's who's buying systems. And even that's not all bad, I've replaced several systems that had to have been bought for looks alone.

Regards,
cww

 

> In reply to pvbrowser: Do you create the SVG artwork completely as custom art for each application then? <

Most of the SVG is custom art. But you can import other SVG files and copy & paste from these objects. Thus you can create your own library of SVG objects. I think it would be a good idea to share such SVG files and host them on our webpage for example.

> I just had a look at your documentation, and you have some examples:
>
> d->svgAnimator.svgPrintf("HelloObject", "fill=", "#000"); // set a property
>
> You're modifying the "fill". That's what I do to control a pilot light. <

Yes, our system is client/server. The SVG is loaded from the server into the client (pv)browser. When running the application the server can modify the SVG in the client and let it redraw. You only send the commands for changing the SVG not the complete file.

> d->svgAnimator.setMatrix(const char *objectname, float sx, float alpha, float x0, float y0, float cx, float cy);
>
> You're doing a rotate, which is how I do a selector switch. I do an actual rotate transform instead of a matrix operation, but the end result is the same. <

There is a class rlSvgPosition

http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSvgPosition.html.

Which can be an argument to setMatrix alternatively. I think this does it also the way you are doing it.

> One difference in the approach that I am taking is that those code details are hidden out of sight of the person actually configuring the system (unless they want to open the file with a text editor and dig into the source code, of course). They just decide what tag they want to monitor and what sort of behaviour they want from it (pilot light, selector switch, dial gauge, etc.). Behind the scenes though, it's working with properties via the "id". <

Our modification methods also use the id to address the SVG objects.

> However, I think the actual SVG symbols that I've made would probably work with your software. When I've got everything running with the new system we may want to see if a common symbol format is feasible. <

I see no problem in that because it is simply SVG.

PS: We sometimes combine bitmap images with vector graphics in the SVG. For example you have a JPG image showing a tachometer and a needle on top of it all within 1 SVG. Now you can animate the needle.

 

For A-B connectivity, this MAY help: http://www.digi.com/pdf/prd_ds_digioneiap.pdf

Although, it would be easier and probably cheaper just to pick up an I/O device that actually speaks Modbus, there are many...

Bill Sturm

 

In process industries I think graphics should attract the operator's attention to possible abnormal situations. For the rest they should be as dull as possible. So showing rotating parts of motors etc. is just something we don’t do.

Here are a few examples of the rules I follow:

- Blinking objects are shouting for attention. Operators should be able to turn of the blinking. I.e. on our screens only unacknowledged alarms blink. When the alarms are acknowledged they stop.

- For changing state don’t (only) change color but also change shape. Running vs. stopped motors, open vs. closed valves, active bypasses, active alarms, abnormal modes etc. they all have their icons that pop-up (or not) and change (e.g. per alarm priority).

- Numerical data is serial input to the operator. He has to read it digit by digit, form a number and then decide if the value is high, normal or low. Using a figure (like a bar graph) the operator is much faster in assessing the situation. However, if he wants more detail he should be able to get it (e.g. by clicking on the bar graph).

So, do we need the realistic looking gauges, rotating pumps, vessels that look like real vessels with shades etc. ? Yes we do but only for one or two show case displays (for the management).

 

In reply to Rudi:
> In process industries I think graphics should attract the operator's attention to possible abnormal situations. For the rest they should be as dull as possible. So showing rotating parts of motors etc. is just something we don't do. <

I have to agree strongly with this point. The "pump" that I have in the standard demos is intended to show how rotating animation can be done. A pump that changes colour can be done as a "pilot light" (in the terminology that I use, a "pilot light" is anything that changes colour regardless of its actual shape). There are also practical reasons to not do too much animation, as too much might result in excessive CPU load on a slow computer.

>Here are a few examples of the rules I follow:
>
> - Blinking objects are shouting for attention. Operators should be able to turn of the blinking. I.e. on our screens only unacknowledged alarms blink. When the alarms are acknowledged they stop. <

So, do you have one thing blinking to indicate that there is at least one unacknowledged alarm somewhere, or do you blink each individual device? I have had people tell me that if there is more than one thing blinking at a time it drives them up the wall.

> - For changing state don't (only) change color but also change shape. Running vs. stopped motors, open vs. closed valves, active bypasses, active alarms, abnormal modes etc. they all have their icons that pop-up (or not) and change (e.g. per alarm priority). <

Are you using stock symbols for these though, or are you drawing your own shapes to change between?


> - Numerical data is serial input to the operator. He has to read it digit by digit, form a number and then decide if the value is high, normal or low. Using a figure (like a bar graph) the operator is much faster in assessing the situation. However, if he wants more detail he should be able to get it (e.g. by clicking on the bar graph). <

I have provided "tank fill columns", "column gauges" and "dial gauges" for this. They give you a good idea of relative proportions. A "column gauges" is just a bar graph, while a "tank fill columns" is a bar graph with an uneven outline that looks like a cut-away view into a vessel (or hopper). This is pretty straight forward.

> So, do we need the realistic looking gauges, rotating pumps, vessels that look like real vessels with shades etc.? Yes we do but only for one or two show case displays (for the management). <

This is what I earlier called "bling". I have features that are intended to make a good first impression, but frankly I don't recommend using them to excess. I've done 7 segment LED style digits which I put into the "bling" category, but if I had to look at a display all day I would prefer to look at nicely rendered conventional fonts.

 

This is a follow up to this subject. To summarise the situation up to now, you can use the Inkscape vector graphics drawing editor (http://www.inkscape.org/) to create SVG drawings which you can then animate to create a web based HMI. Some other (non-web based) HMI systems also use SVG as their graphics standard.

I have new versions available for my project which have the new SVG HMI libraries packaged with them, along with documentation (25,000 words) on how to use Inkscape, the SVG clip art, and other elements in HMI applications. Some people had expressed interest in using the SVG editing techniques and SVG libraries with other programs.

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

I intend to write a new program which will automatically assemble the SVG into the web page and that will be called "HMIBuilder", but for now the documentation and SVG files (and web page and css templates) are just packed in with the regular MBLogic, MBTools, and MBTLogic-All packages. They are located in in a tar.gz file (Linux) or zip file (MS Windows) which is included inside each package and is titled "hmibuilder.tar.gz" or "hmibuilder.zip".

Each SVG GUI widget is an individual file. There are several dozen different items which come pre-configured in various colours and shapes, so there are close to 600 different options (files) split into a number of different directories. One of the PDF documents ("MBSVGLib.pdf") provides an image of each one and describes what it does.

What I found was that to make the overall system easier to use I needed to include a number of embedded defaults (e.g. colour definitions) and Javascript library calls (for things like push buttons) that means that some of the individual widgets aren't completely generic. However, if someone wants to use the SVG components with their own software I can work with them to remove the things that don't apply to their situation.

I asked for some feedback for additional ideas for what sort of commonly used functionality is typically desired, and got a few good ideas. I haven't implemented those yet, but will be starting on them soon.

Any feedback on any part of this is appreciated.