Which HMI Graphic Objects Do You Use The Most?

I was wondering what everyone uses the most when building HMI screens. For some examples:

Plain rectangular buttons
Simple text readouts
Dial gauges
Realistic buttons such as the ones in Symbol Factory/Wonderware
Bar graph
etc....

Also what graphical objects would you like to have that is not in the typical HMI package?

I see these fancy buttons, gauges, tanks and piping graphics all over the internet, but don't think I've actually seen a machine with them used on it.

We stick to what is available natively from our HMI pacakage (Wonderware). That way when we have upgrades, we don't have to worry about ActiveX compatibility or some other 3rd party issues.

I usually use whatever graphics are on the software although, i've recently got some software called snagit which has allowed me to create my own library of graphics(a lot taken from proface software). but i never liked the fancy looking ones on the net, think they look cheap

Personally, I don't like 'Life-Like' graphics. I much prefer to use all square/rectangular buttons and indicators. Easier to lay out on screens, and universal across just about any HMI platform.

I do use 'Life-Like' graphics on displays that can benefit from depicting an actual representation of a machine section, like control valve assemblies, or piping diagrams.

I think fundamental components are the most important. These are pretty similar between HMI packages and development environments (Visual Studios, for example). Text labels, buttons, numeric input boxes, and all the basic 2D shapes.

More advanced representations are also powerful - hard to place in the "most used" category, though. I'm referring to sortable tables, graphs, pdf reports, etc.

Here is a challenge for you to do something a little different that is potentially a selling point for certain industries. A common problem in animating transport pipes is the number of options you have to consider in order to animate the pipes correctly. For instance, a system with 2 source vessels, 3 destination vessels and 1 pump with a few divert valves has an enormous number of possible combinations to animate so most do not bother. However, this is a really common request from operators, especially in complicated plants with many sources and destinations and lots of pipework. It can be done but in my experience it takes a long time and it's easy to make an error.

What I think is needed is a "Smart line" that is capable of (1) detecting a open or closed valve, a source vessel, or motive object (pump etc) is placed on it and (2) capable of animating whether a segmenent contains stationary or moving fluid/solid based only on the status of the preceding elements. If you really wanted to push the concept you could also make a generic smart object that highlights when material is flowing into or out of the vessel.

Other thoughts
- It's nice to have a library of simple 3D tanks and other objects with distinctive shapes, because it can really help the operators to visualise the plant when they see an object that visually stands out amongst more generic neighbours
- Faceplate support is always an advantage, and a smooth wizard for using them is a good idea. Some older packages don't really support this well and I hate those with a passion because I don't like having to hack up scripts etc to create this functionality
- It would be nice to have input objects that have a faceplate to set range, scaling etc during commissioning(administrators only of course)
- A good, simple recipe handler. Rockwell are notable laggards on this but WinCC flex is pretty good IMO.
- A good, simple batch record object would be great - preferably something with a simple interface (maybe configured with a wizard for non-windows gurus) to an ODBC database or similar.

May add some later!

What is "Faceplate support"?

I don't know why animated pipes comes up so often as such a challenging feature. Simply break down the problem to sets of pipes that share the same animation conditions. All you do is base the animation (color) on an expression that takes each factor into account. This is REALLY EASY if you can use the upstream pipes (other object states). That way equations are simple and you can make changes locally that don't screw everything up. If every pipe has to be directly based on all of its dependencies then you get knarly equations where an upstream change forces you to change lots of little objects, which is painful and error prone.

Binaural said:

Here is a challenge for you to do something a little different that is potentially a selling point for certain industries. A common problem in animating transport pipes is the number of options you have to consider in order to animate the pipes correctly. For instance, a system with 2 source vessels, 3 destination vessels and 1 pump with a few divert valves has an enormous number of possible combinations to animate so most do not bother. However, this is a really common request from operators, especially in complicated plants with many sources and destinations and lots of pipework. It can be done but in my experience it takes a long time and it's easy to make an error.

What I think is needed is a "Smart line" that is capable of (1) detecting a open or closed valve, a source vessel, or motive object (pump etc) is placed on it and (2) capable of animating whether a segmenent contains stationary or moving fluid/solid based only on the status of the preceding elements. If you really wanted to push the concept you could also make a generic smart object that highlights when material is flowing into or out of the vessel.

Other thoughts
- It's nice to have a library of simple 3D tanks and other objects with distinctive shapes, because it can really help the operators to visualise the plant when they see an object that visually stands out amongst more generic neighbours
- Faceplate support is always an advantage, and a smooth wizard for using them is a good idea. Some older packages don't really support this well and I hate those with a passion because I don't like having to hack up scripts etc to create this functionality
- It would be nice to have input objects that have a faceplate to set range, scaling etc during commissioning(administrators only of course)
- A good, simple recipe handler. Rockwell are notable laggards on this but WinCC flex is pretty good IMO.
- A good, simple batch record object would be great - preferably something with a simple interface (maybe configured with a wizard for non-windows gurus) to an ODBC database or similar.

May add some later!

Click to expand...

surferb said:

What is "Faceplate support"?

I don't know why animated pipes comes up so often as such a challenging feature. Simply break down the problem to sets of pipes that share the same animation conditions. All you do is base the animation (color) on an expression that takes each factor into account. This is REALLY EASY if you can use the upstream pipes (other object states). That way equations are simple and you can make changes locally that don't screw everything up. If every pipe has to be directly based on all of its dependencies then you get knarly equations where an upstream change forces you to change lots of little objects, which is painful and error prone.

Click to expand...

Faceplate in this context = a generic screen that can be connected to a tag or tags in the PLC that are assigned at runtime - very useful for device popups etc. WinCC (the original, not flex) does not have this and is still widely used. My company that I have just joined has implemented a system but it requires considerable background C and VB code, which is ugly, confusing for maintenance programmers and easy to break.

Regarding your second point, you have answered yourself. Writing equations for every segment of pipe in a project (even simple ones) takes a long time to do something that is obvious based on simple inspection of the elements and their running status. Not to mention that for systems with multiple source/destionations, several pumping stages or multiple diverts your "really easy" equations can quickly require a large testing matrix to evaluate - you can't just take for granted the logic will be correct. Objects that just do this function without further adjustment allow you to add a functionality that is very useful for processs visualisation with no added development time.

Other things I've thought of:
1. Recipe lists that can show a filtered view at runtime which can be invoked on a screen in context (i.e. show all AR670 parameters). Most recipe objects I have seen show always show a full list and you have to identify the objects you want to modify using a standard string at the start of the comment.

2. Auto-assign. Let's say you want to create a screen which shows you input fields for the 10 parameters contained in a data block in the PLC. I'd like to be able to place 10 generic input objects on a screen, block-select them, select the first tag in the PLC and have a wizard assign the following input fields to the following tags, formatting as required, or using a standard selection field. For environments like Step 7 that support structs, you could use a wizard that auto-creates standard objects for an entire struct.

3. More checking and validation tools! This cannot be emphasized enough. Ideally I'd like to be able to see a list output that shows the connected tag for each screen object next to it's identifying string, the tag type (float, bool etc) and have highlights for potential problems (i.e. no range set for input). Clients haaaaate it when you have screen objects that don't work or, worse, don't work the way they should.

I see - does this just mean that "indirect addressing" (PLC talk) or "pointers" (programming) are supported in the place of tags, or is something fundamentally different?

Binaural said:

Faceplate in this context = a generic screen that can be connected to a tag or tags in the PLC that are assigned at runtime - very useful for device popups etc. WinCC (the original, not flex) does not have this and is still widely used. My company that I have just joined has implemented a system but it requires considerable background C and VB code, which is ugly, confusing for maintenance programmers and easy to break.

Regarding your second point, you have answered yourself. Writing equations for every segment of pipe in a project (even simple ones) takes a long time to do something that is obvious based on simple inspection of the elements and their running status. Not to mention that for systems with multiple source/destionations, several pumping stages or multiple diverts your "really easy" equations can quickly require a large testing matrix to evaluate - you can't just take for granted the logic will be correct. Objects that just do this function without further adjustment allow you to add a functionality that is very useful for processs visualisation with no added development time.

Click to expand...

SurferB,

I generally use Cimplicity HMI and I use what they call screen variables.

I use screen variable to animate the objects properties (colours, values, visibility, text etc) then at runtime i assign the screen variables to tags.

As already said, this is ideal if you have a lot of repetition etc.

cjd1965 said:

SurferB,

I generally use Cimplicity HMI and I use what they call screen variables.

I use screen variable to animate the objects properties (colours, values, visibility, text etc) then at runtime i assign the screen variables to tags.

As already said, this is ideal if you have a lot of repetition etc.

Click to expand...

This is exactly what I am talking about. Rockwell RSView SE does this by allowing you to make a screen with numbered placeholders (#1, #2 etc) which are replaced at runtime with screen tags stored in a list in a text file called with the screen (#1 = {blahtag}). Incidentally, this method makes it hard to check the object linking is correct at runtime, which would save a lot of toggling bits in the PLC during benchtesting. Siemens WinCC flex has another way again.

I definitely dislike "life like" visualisations, 3d, shadows, unnecessary details etc.
HMI and SCADA vendors like to show off all the visualisation candy they can add, and I like to strip it down to the bare essential.
I think the buttons you posted in another thread were beautiful, but I would never use such buttons myself.

Graphically my screens shows a simplified but immediately recognisable layout of the plant.
I tend to use very simple grahical objects for animations.
Circles, squares, arrows - and they change color and flashing state to show the status of the objects.
edit: Silos and tanks use fill animations.
For buttons and input/output fields I tend to use the "Windows standard". This because people are accustomed to them anyway.
Only exception is that I use a button with color animation in stead of the standard Windows "radio button". The radio buttons are just too discrete to my opinion.

I shall see if I can find an example to post here someday.

JesperMP said:

I definitely dislike "life like" visualisations, 3d, shadows, unnecessary details etc.
HMI and SCADA vendors like to show off all the visualisation candy they can add, and I like to strip it down to the bare essential.

Click to expand...

Another consideration here is that large bitmaps can noticeably add to screen loading time on HMIs (noramally a SCADA has enough processing power for it to be unnoticeable). The key here is the "recognition" - however an object is represented, its most recognizable features (flat top on tank? Top or side pipe entry?) should be preserved as far as possible to help the operators visulize what is going on. To this end I will use a bitmap graphic for key objects, because it visually privileges that object and highlights that it is important to watch it.

Binaural said:

Here is a challenge for you to do something a little different that is potentially a selling point for certain industries. A common problem in animating transport pipes is the number of options you have to consider in order to animate the pipes correctly. For instance, a system with 2 source vessels, 3 destination vessels and 1 pump with a few divert valves has an enormous number of possible combinations to animate so most do not bother. However, this is a really common request from operators, especially in complicated plants with many sources and destinations and lots of pipework. It can be done but in my experience it takes a long time and it's easy to make an error.

Click to expand...

This is what I do.
When there are several paths, I animate piping by color. The piping is segmented as lines between every branching point.
If a pipe is deselected it is gray. If it is selected but passive, it becomes black. If it is conveying it becomes bright green. This is immediately understandable by any operator.
The animation is controlled in the PLC, which controls the conveying sequence anyway. Generally, I use my HMI as a simple frontend for all the 'clever' stuff which are handled by the PLC. I never let the HMI become part of the sequence, apart from letting the operator input settings.

I generally agree. Hopefully when you say "bitmap graphic" you're just referring to an image or object that loads/renders images. There's not a lot of reason to use the .bmp format these days. JPG, PNG, or better yet, various vector formats are a much better way to go. They have an improved look, significantly smaller footprint, and tend to do better with dynamic coloring.

Binaural said:

Another consideration here is that large bitmaps can noticeably add to screen loading time on HMIs (noramally a SCADA has enough processing power for it to be unnoticeable). The key here is the "recognition" - however an object is represented, its most recognizable features (flat top on tank? Top or side pipe entry?) should be preserved as far as possible to help the operators visulize what is going on. To this end I will use a bitmap graphic for key objects, because it visually privileges that object and highlights that it is important to watch it.

Click to expand...