I've written software for creating web based HMI systems. An important part of this uses SVG (Scalable Vector Graphics) to do graphical push buttons, pilot lights, text and numeric displays, gauges, etc.

I've recently been experimenting with using Inkscape as a vector graphic editor to do drag and drop editing of graphic screens. I can drag clip-art (e.g. pilot lights) into the drawing, move it around, resize it, and then the HMI system can animate it (change colours, rotate, etc.) using data from the server. Inkscape has also been used to do complex drawings from scratch which can be animated directly (this was something I discovered when helping someone with an application).

It all seems to work quite nicely and I plan to use it as the basis of making building a web based HMI a completely drag-and-drop and menu driven process. The parts that I have left to do are pretty simple and shouldn't take me too long.

What I would like to know though is to what degree people are using only the standard clip-art (push buttons, pilot lights, etc.) which came with your system, versus third party libraries, versus ones you have created yourself?

Also, if you are using stock artwork, then what types do you find yourself using the most, and which are "must have" items?

If you create custom artwork, then how often do you animate the actual drawing versus just using it as a background?

 

We use Sherrill-Lubinski's SL-GMS tools. Not cheap nor open source.

http://www.sl.com/products/devtools/devtools.shtml

JBA

 

There is an open source project that I have created that focuses very heavily on the quality of graphics (Advanced HMI). When the project was only in concept, I decided the graphics were going to be one of the distinguishing feature to make the project standout. I was able to get near photo-realistic graphics using Adobe Illustrator (vector editing software). Once the graphics are created in Illustrator, I export them to a PNG format.

Before adopting Illustrator, I tried Inkscape, but found the community support and tools were not as good.

So far the results of the graphics are far better than any HMI/SCADA graphics I have been able to find. The project is all done in Visual Basic .NET which handles the animations.

http://sourceforge.net/projects/advancedhmi/

 

We try very hard to use only built in stuff where possible. However, we've found that it doesn't really work to use a push-button that looks like a real button or an indicator that looks like a real lamp. Just give me a button that looks like a standard Windows "OK" button and a circle (with a border) that can change color. If there's a gradient or 3D-effect on the these, great. If not, oh well.

> Also, if you are using stock artwork, then what types do you find yourself using the most, and which are "must have" items? <

We really don't do much beyond push-buttons, indicators, and text/numeric displays. I'm sure that someone with a more "traditional" SCADA setup for a process control would have a very different answer.

> If you create custom artwork, then how often do you animate the actual drawing versus just using it as a background? <

Usually it's just a background, but we've started trying to animate more.

Hope that helps.

-James Ingraham
Sage Automation, Inc.

 

Depends on the industry I have worked in. There is always something that needs to be animated to make the operators acceptance and work with the screens easier. In manufacturing it has been machine component positions that need to be indicated, in material handling its mainly conveyor chute positions and maybe sampler and dumpers that get animated. In brewing systems its the temperature control and the clean-in-place system piping/pumps/valves that need animation. In pipeline systems its the batching and blending systems that see mostly colour based animation.

I think a lot of time is wasted on 3d buttons and lights. What's important for me is that components like buttons, lights & gauges scale well (especially on the small side) and don't have a lot of "dead" perimeter pixels (preventing overlay). Most of what I need to do I get done with animated rectangular shapes, lines and polygons.

Hugo

 

In reply to JBA:

I just had a look at the Sherrill-Lubinski web site. It appears that they are using Java applets to do their graphics. I didn't look closely at all the stuff they do, but for the automation related graphics I didn't seen anything that I couldn't do with SVG. They seem to have quite a diverse customer base though.

As for price, I couldn't find any prices on their web site, so I guess it's a case of if you have to ask how much it costs, you can't afford it.

Thank's for pointing this out to me.

 

Hello,

For me personally I prefer a minimal HMI screen. I use these "standard" features alot with hardware HMIs:

- Buttons that set or alternate bits, and display that bit status as an indicator "light".

- Buttons for changing screens (Menu system, etc.)

- Displaying different strings based on the value of a word (some call this alarm or comment display).

- Numeric displays (Often with "click to edit number" features).

- Use enable features of buttons to "grey them out" when they are not useable (preferably using an expression to enable the button).

I prefer not to use any fancy graphic libraries or animation for the types of things I work on. I think extensive graphics and animations to be aesthetically offensive and not useful. This is not to say that there aren't applications where this is helpful, just not for me. It almost seems like HMI companies try to sell their systems based on the flashiness of their animations which I believe goes against clean user interface design principles.

I'm glad to hear that you are working toward a WYSIWYG kind of HMI builder by using Inkscape. Do you think that it would be possible with your HMI to have Button presses execute "C" code on the server machine? I may be working with a Linux based system in the next year that already has the libraries to access IO and things from the C language. I find it nice to be able to write code that when the button is clicked it checks the status of things and puts up a dialog box to let the operator know that something is not possible, etc.

Thanks,
KEJR

 

In reply to Archie: I have heard that a lot of commercial artists (advertising, brochures, etc.) swear by Adobe Illustrator. It is very expensive though, so I haven't tried it.

I have however seen some pretty impressive art work done with Inkscape, although I don't think there are as many books or courses on how to use it. On the other hand, Inkscape doesn't cost anything and I'm not enough of an artist to make use of even a fraction of its features.

Adobe was one of the major parties who worked on the SVG standard, and Illustrator will output SVG. I don't know if the XML (SVG is XML) they output maintains the relationship of the different elements in the objects, or whether it is just a bunch of disconnected XML. Dia (more of a diagramming program than a vector art editor) will also export SVG, but it's just disconnected lines, rectangles, and other basic shapes. If I get a chance to work with Illustrator, I will investigate whether its SVG output is in a usable form.

I had a look at your project, and the graphics look terrific. However, you're doing pixel graphics (PNG files) while I'm doing vector graphics (lines, circles, etc. specified as XML), so they aren't directly comparable. There are pros and cons to each method, so which one works better depends on the application.

My own project is at: "http://sourceforge.net/projects/mblogic/" if you are interested.

If you just want to see what the graphics look like, there are some screen shots on the main page as well as a lot more on the project web site at "http://mblogic.sourceforge.net/mbhmi/mbhmiintro.html". The colours are only examples, as any colour is possible, and of course you can stretch, shrink, skew, etc. any of them.

There are several parts to it. The "MBTools" package includes web based HMI (as well as other things). The "MBLogic" package does combined web based HMI with soft logic. The "MBLogic_All" package has everything all in one (the new Sourceforge redesign has made downloading separate packages more difficult).

The existing documentation deals with creating the web pages using conventional web page editing techniques. The new (Inkscape based) technique isn't on there yet as I am still working on the documentation. When it's ready (probably in a week or so) I will bundle it with each of the existing packages in a new release.

 

In reply to James Ingraham: I had assumed that most people would only want push buttons, pilot lights, text, numbers, etc. However, I was recently helping someone who drew some terrific looking process images he was planning on just using as a background, and he was using Inkscape.

He was going to put the stock objects on top, but I had a look at his Inkscape drawings and saw that he could just animate his art directly (e.g. change colours of pumps and valves, make tank levels go up and down, etc.). That is what got me thinking of how to use Inkscape as a drag and drop editor for stock images.

My own background is assembly type operations where an HMI is basically just a replacement for old style push button panels. I am guessing though that process industries like custom graphics more. Either way works, one is just drag and drop of stock images (which is fast and easy), while custom drawing work takes more time and a bit of artistic talent. I'm not an artist at all, so I actually have better luck drawing things using XML in a text editor.

As for how push buttons should look, I've come to the conclusion that conventional hardware push buttons look too much like pilot lights when they are drawn on an HMI screen. So, I have tried to make them more distinguishable while still looking nicer than a simple "OK" button.

I ended up with pilot lights that have a "nut" around them and a flat colour (the colour changes of course). The push buttons have no "nut", and they have a colour gradient across them and a number of other visual effects (e.g. the border changes colour when you active the button).

I've ended up with the following:

- Pilot Lights (in various styles).
- Push Buttons (in various styles).
- Selector Switches (2 and 3 position).
- Text and Numeric Displays (various styles and sizes).
- Numeric Entry keypad.
- Numeric Entry (via increment/decrement digits).
- Pumps and Piping.
- Tanks with indicator columns.
- Column gauges.
- Dial gauges.
- Simple strip charts.
- Screen select menus (using push buttons).

Everything comes in a selection of different colours, and it can all be resized, skewed, etc. That's pretty much all that I've ever had need to make use of myself. I was wondering if there was anything obvious that I've missed because I've never needed it. I've been dealing with people lately who are doing things like process industry and building control systems, and they seem to have a different perspective on things. I don't want to try to create a big process industry symbol library though, as that is a big project on its own.

Once I have the graphics as drag and drop finished (I've built a sample application, so this works), then the rest of an HMI can be built using templates and menu driven boilerplate (to add the tag names and auto-generate the scripting). That gets rid of the need to know how to create a web page to make an HMI application, and it's a lot faster as well.

 

I have mostly used basic push-buttons, pilot lamps, bar graphs, and data entry/displays. I have used simple dial type gauges on occasion. I typically have a solid color background, but sometime I have imported a vector graphic diagram and placed some data entries on it.

Bill Sturm

 

In reply to Hugo and Bill Sturm: Thanks for your comments. They seem to confirm my own experience. That is, run of the mill assembly manufacturing doesn't use elaborate graphics. It just sticks standard components on a screen. Process industry on the other hand seems to go for elaborate views of the plant. It helps me to know what people find useful.

As for scalability, SVG graphics are like CAD in that they can scale up or down without losing resolution because they are dealing with geometric shapes rather than arrays of pixels (until it actually ends up on your monitor, of course). So, I could stretch an object to fill up the whole screen, or shrink it down so it's very small and it doesn't get pixellated like a PNG or GIF would.

 

In reply to M Griffin: The reasoning behind me using PNG files is the ease of use with the .NET environment and file size. All of the original graphics are vector based and simply exported to PNG files. I have experimented with using XAML and .NET 3.5 because it gives much better animation and keeps everything in vector graphics.

I did export one of my components from Illustrator to SVG, then opened it in Internet Explorer with the Adobe plug in. It did seem to preserve the quality. If you would like, I can send you a graphic created in Illustrator and saved as an SVG. Illustrator does have a bit of a learning curve, so its not very easy to jump right in and create decent graphics.

I have actually been following your project for a while. I have been looking for some commonality amongst all of the open source HMI projects. So far it seems that everyone is heading in opposite directions.

My focus has been graphics, a windows desktop environment, Allen Bradley and Beckhoff drivers, and something that can be up and running very easily. I steered away from web based applications because it does require a bit of knowledge about setting up a web server.

 

In reply to Ken E:

>- Buttons that set or alternate bits, and display that bit status as an indicator "light". <

I do that with push buttons, selector switches, illuminated push buttons, and pilot lights. The pilot light or illuminated push button can follow the state of the button input address or it can monitor some other address. Selector switch position is the same, and the machine control can actually set selector switches to whatever position they want at any time (since it's all under software control).

>- Buttons for changing screens (Menu system, etc.) <

Got that.

>- Displaying different strings based on the value of a word (some call this alarm or comment display). <

Got that.

>- Numeric displays (Often with "click to edit number" features). <

I do that with a calculator style keypad so that it can work with a touch screen.

>- Use enable features of buttons to "grey them out" when they are not useable (preferably using an expression to enable the button). <

That is a feature that I've overlooked but that I obviously need to add. It doesn't look very difficult to do. It would monitor a bit address and if the address is in one state it would enable the button, and if it is in another state it would disable the button. This would need to cover both push buttons and selector switches.

I will have to do a few experiments to see which visual effects will work the best. Just turning the button grey won't do, as grey is already a valid colour.

In your opinion, do you think the control logic should be "on" to enable the button, or "on" to disable the button? I think that "on" to disable with a default of enabled is how most people tend to think about it.

> I prefer not to use any fancy graphic libraries or animation for the types of things I work on. I think extensive graphics and animations to be aesthetically offensive and not useful. <

I think that man hours comes into it as well. It's not worth sinking a lot of man hours into an HMI for a single $100,000 machine, while it is if you are selling 100 identical machines, or if you are building a $10 million process plant.

> I'm glad to hear that you are working toward a WYSIWYG kind of HMI builder by using Inkscape. <

The graphical part using Inkscape is already working. I've repackaged the SVG as individual files that you can drag and drop onto Inkscape. I'm half way through writing up the documentation on how to do things like how to tell a pilot what tag address to monitor (e.g. right click on the object, select "properties", enter the tag name, etc.). There was a very close correspondence between how Inkscape uses SVG and how I was using SVG. The documentation is step by step instructions about what buttons to click to use the different features.

What I have to do next is write a program that automatically assembles the scripting boilerplate libraries to drive the display (which is the other half of the system) and then assembles the templates into a finished web page. That's pretty straight forward though and won't be too much work.

> Do you think that it would be possible with your HMI to have Button presses execute "C" code on the server machine? I may be working with a Linux based system in the next year that already has the libraries to access IO and things from the C language. I find it nice to be able to write code that when the button is clicked it checks the status of things and puts up a dialog box to let the operator know that something is not possible, etc. <

I guess it depends on the details of what you are trying to do. I started writing a really long answer here, but I think it would be better to talk about your application in a less abstract manner. If you don't want to talk about the details on this list, then if you download a copy of any of the MBLogic packages from
"http://sourceforge.net/projects/mblogic/" you will find a contact e-mail address in the source code headers. That is an address that I've set up specifically for the project, but I don't want to post it here because it would get buried in spam.

The short answer is that there are several programs which implement the HMI and they are all written in Python. Python interfaces very well with C libraries. One of the users for my software is customizing a version of it for his application, and I'm helping him and making changes to the original version to accommodate him.

If you want to talk more about your application either here or via e-mail, then let me know. I've actually got 2 completely different programs that use the same HMI and one of those comes in 4 different versions (client and server for 2 different protocols). So, it's hard to even say which one would be best suited as a base for customisation.

If none of that suits you, you could take the graphics and the web browser Javascript libraries (which do the background communications and update the web page) and control those from your own server. The protocol is documented and it's pretty simple to implement. It's not tied to to the servers that I wrote.

 

Wow, you have been busy!

Are you planning an open API for attaching user defined vector graphics? Maybe using tagnames like in HTML. That would be handy.

Bill Sturm

 

Our http://pvbrowser.org
is an open source project for HMI/SCADA that also supports SVG.
We use inkscape for SVG design.

The server is in C/C++, where the framework will be generated and you only have to act on user events. The SVG in our HMI can be animated dynamically and you will get events when the user clicks SVG objects..

There are some collections of SVG symbols within the net.
Example:
http://ian.umces.edu/symbols/

But these collections are not well suited for HMI.

We could host a collection of SVG symbols on the homepage of our project if there are users who want to share their symbols with others.

 

Hi, Guys,

I have mostly used the basic Graphics and tools that are available with the developmental package. I would like to think a bit differently, if I am allowed to present it here. Probably this idea is already in practice and I am not aware of it.

Imagine you have CCTV cameras covering the entire plant (may be the cost is prohibitive) with required amount of zoom-in, zoom-out and swivel facilities controlled from your SCADA Screens. Imagine that you are watching the Real Time Video of a particular plant area showing all the data (what you normally incorporate on a SCADA Screen, including the Push-buttons etc). While you zoom-out, there is no data on the screen except for the real time video, while you zoom in, layer-by-layer you keep getting the relevant data, super-imposed graphic or control push buttons etc. Imagine you also have the privilege to archive the data with the video in real-time. From the archived data imagine you are making a postmortem analysis of a safety valve opening (gushing the gas out) in the video and the relevant data (say the tank pressure) appearing next to it.

It looks I have really got carried away with the idea. Comments if any please!

 

I've done some experimenting with Illustrator, SVG, and Inkscape. To my surprise, when I saved as an SVG from Illustrator and opened in Inkscape, the integrity of the graphic was retained quite well.

I tried it on a few of my more complex graphics and so far the only thing that did not convert was an artistic brush. I rarely use that so I wouldn't consider it much of a loss.

With those findings, I would have to say that Illustrator AND Inkscape can be used interchangably for creating SVG graphics.

Unfortunately for the AdvancedHMI, Microsoft does not offer support for SVG in the .NET framework, so I will have to continue to convert to PNG files until I move to XAML and WPF.

 

I'm replying to some of the comments about animations and graphics used frequently in the process industry for the sake of understanding. I have not done work in this area (my focus is assembly machinery), so take these comments with a grain of salt, but why would you want someone troubleshooting a bad auger, pump, or valve with animations versus putting up fault messages? I guess I can't see the value in animations.

I could maybe see displaying flows, temperatures, etc on simplified vector graphic backdrops, just so you don't have to get into intricate naming schemes, but this usually isn't that bad either. For what its worth I think it is bad taste when I see literature of HMIs consisting of a digital photograph backdrop of someone's equipment with displays and dials pasted all over it. Its really too much information to see photo detail of your process in a user interface design.

KEJR

 

There are two big advantages:

1. Graphics are _kewl_ and sell projects to people who think like crows and are attracted to shiny objects.

2. They can give some direction to users who haven't a clue, quickly.

People who know what they are doing are OK with messages and may even prefer the greater information transfer. But they are attracted to graphics too, just not as strongly.

Regards,
cww

 

In reply to Archie: I'm going to guess from your description that Adobe Illustrator can create SVG in a suitable format. At this point, I think I will be telling people that Inkscape will work, and here's the instructions on how to use it for importing and arranging clip-art. If they want to use AI, then I will tell them it will probably work, but I won't have step by step instructions for it.

As for XAML, Inkscape will export to it, but I don't know how good the output is.

As for having something up and running easily, that has been my goal as well. It's why I'm interested in using Inkscape as a vector editor.

If you are trying to do everything with the MS DotNet framework then yes, you end up with MS Windows Server, IIS, MS SQL Server, etc. all running. That's all pretty complicated (and expensive) and also entirely unnecessary for the sort of applications we are talking about here.

You don't need to set up a separate web server for the software that I've written. The web servers are built right into each program that needs one. A basic http server isn't any more complicated than a Modbus/TCP server (less so, in many ways). It's just another protocol in that sense. The programs are completely self contained, so there's no separate web server or other components to configure.