HMI for flexible machine - options for HMI size

[rQx]

Hi,
I feel my customer has come to the point where I need to make their program as a flexible program with add-ons/options. I feel that I have it kind of under control with input mapping, using blocks to choose wich modules exist etc. But now I have come to a point where one machine need 7" screen and the other a 9" or possible a 12". I can't just replace the HMI all over because of the price. The HMIs will only be diffrent in maybe 2-5 screens out of 60. If I have two HMIs configured in the cabinet then, I have to make all changes at two places in the programming enviornment. I guess that this is the only way, but maybe I'm not seeing something someone else know.
/Tim

 

[mk42]

Hi,
I feel my customer has come to the point where I need to make their program as a flexible program with add-ons/options. I feel that I have it kind of under control with input mapping, using blocks to choose wich modules exist etc. But now I have come to a point where one machine need 7" screen and the other a 9" or possible a 12". I can't just replace the HMI all over because of the price. The HMIs will only be diffrent in maybe 2-5 screens out of 60. If I have two HMIs configured in the cabinet then, I have to make all changes at two places in the programming enviornment. I guess that this is the only way, but maybe I'm not seeing something someone else know.
/Tim

Personally, I'd develop it at one size and just scale it up or down by changing devices, but from the other thread you already know how to do that and aren't happy with the result, so I'm not sure what another solution could be.


Unless you build a project generator with openness?

 

[JesperMP]

This is where you can see that Siemens TIA WinCC Comfort concept is quite archaic.
It is the classic way of making HMIs, with the programmer having to repeat tasks that should be handled automatically. Like easy scaling up and down in size, one program for multiple HMIs, easy handling of multiple languages ..

I wish that WinCC Unified will solve some of these, but I have my doubts.

Apart from that, I would create a standard program that handles the possible variations or options dynamically. Dynamically hide screen elements that are not to be used on a particular machine.

Making customized programs to handle options on otherwise standardized machines is a journey into entropy. Do you have multiple languages in your projects ? Just think of having to repeat all the changes on all the HMIs in all the custom programs in all the languages. Stuff like that drives me nuts.

 

[OkiePC]

This is an area where Crimson shines. You can easily rescale a project for use in larger HMI products. Going from larger to smaller often requires some manual intervention to make all the text look right but the graphic objects will be fixed for you in seconds.

Multiple languages using the built in Auto-Translate with resulting customizable lexicons is also a huge time saver. Crimson might take a few minutes to perform all the translations while you drink coffee and might result in some humorous results for technical terms, but gives you the flexibility to fix them.

 

[mk42]

This is an area where Crimson shines. You can easily rescale a project for use in larger HMI products. Going from larger to smaller often requires some manual intervention to make all the text look right but the graphic objects will be fixed for you in seconds.

Multiple languages using the built in Auto-Translate with resulting customizable lexicons is also a huge time saver. Crimson might take a few minutes to perform all the translations while you drink coffee and might result in some humorous results for technical terms, but gives you the flexibility to fix them.

You can do resizing easily with Comfort panels as well, which is what is confusing me about this whole thread. I'm clearly missing something, but I don't know what.

They also have good multiligual handling (although the "autotranslate" is a DL from the support site, not built in).

 

[mk42]

This is where you can see that Siemens TIA WinCC Comfort concept is quite archaic.
It is the classic way of making HMIs, with the programmer having to repeat tasks that should be handled automatically. Like easy scaling up and down in size, one program for multiple HMIs, easy handling of multiple languages ..

I wish that WinCC Unified will solve some of these, but I have my doubts.

Apart from that, I would create a standard program that handles the possible variations or options dynamically. Dynamically hide screen elements that are not to be used on a particular machine.

Making customized programs to handle options on otherwise standardized machines is a journey into entropy. Do you have multiple languages in your projects ? Just think of having to repeat all the changes on all the HMIs in all the custom programs in all the languages. Stuff like that drives me nuts.

Jesper, you usually know your stuff when it comes to Siemens, so I feel like I'm missing something. It feels to me like Siemens has features to address each of those things you're discussing. Is the implementation just bad?

why would you need to have multiple projects for multiple langauges? You can have multiple languagues built into the same project, and switch between them with a button press. You need to translate it yourself, but would you really trust autotranslate for your HMI?

You can easily scale projects up/down the sizes. Things might look dumb if you try to go from 22" to 4" or something like that, but going up/down one or two sizes seems to work well to me when I've done it.

I've seen people use recipes to control what is displayed and not for different options in standard HMI setups. CSV files get preloaded onto a memory card, which are then loaded on bootup to control how the HMI appears.

 

[JesperMP]

No I dont need multiple projects for multiple languages. It is the other way around.
I dont want autotranslate. I cant understand how other people rely on that.
I know the language editor in TIA where you can edit all the texts in one place, but it is really clunky. I guess they have done their best but it is just not good enough.

I want to edit the texts once, and have them permeate throughout the project on all HMIs.

I know I can convert panel types, and that more or less scales the resolution. But that is not what I want. I want it even easier, I want to have one (1) base program to edit even if there are multiple panels in the same project.

When I do have multiple projects for the same type of machine, because the programs arent standardized, or because you for any reason create a variant of an otherwise standardized program, and you want to add a modification, then welcome to make the same modification x no of times.
If you have 3 variants, with 2 HMIs in each, and 5 languages, then adding 1 alarm to your program you have to edit you program 3x2x5 = 30 times over !
You can cut and paste between the HMIs, and also export and import all that you want, but you still have to edit all the HMI variants in all the languages, even if it is the same machine.

It is the overall concept that is wrong. That you write your HMI programs targeted for a specific panel is arcaic to me.

I am thinking something where you have a single base program that you only have to edit once, even if the resolution changes, or if you add or remove screens.


Writing new PLC and HMI programs is interesting. Fun even.
Maintaining the existing PLC and HMI programs is a chore.