So let me ask this question about HMI progrming

So in order for the HMI to what you want it to do everything that the HMI does has to be entered into the PLC program?

No, you can and probably should separate implementation between PLC and HMI, minimizing touch points (shared tags) to what is needed to meet your requirements.

core truth:
the system should work if the hmi ends up in a tree.

Well from what I got from programing one I had to use the addresses that was entered into the PLC program in order for it to work rite.

Yes, in order for the hill to ask for information from the plc it must use the names that the place knows. The hmi could display information which is not in the plc but then why connect it to the plc?

The answer is 'no', 'maybe', and 'yes'.

When we start a project, the HMI team and the PLC team (assuming the projects are big enough for "teams" or one or more people; otherwise, its just one guy wearing multiple "hats") start on the project at the same time. The HMI team will start with stuff that the PLC (usually) doesn't care about, like screen navigation, security rules and the like. So that's the "no" part of the answer.

Much control system programming these days is sort of "object-oriented": that is, there is a chunk of code in the PLC (user-defined instructions / data formats) that manage all the operations for a "class" of device: motors, valves, analog inputs, etc. Similarly, the HMIs will often have a "library" of objects that perform all the animation for the motors, valves, etc. Sometimes these libraries will come from the PLC/HMI vendor, other times the client may have a company standard. But often they are created from scratch, based on the system's needs. Once the PLC and HMI teams agree on what functions will exist, and how they will be communicated, they can each independently go about building their own libraries of objects. Testing of these objects is often iterative, and a single instance of those objects will be created on the PLC and HMI to verify that everything works as its intended to. That's the "maybe". The HMI can, for a time, "fake" a PLC signal to verify function, but usually only on a limited basis.

Then comes the meat of the project, where the HMI team and the PLC team work to generate instances of all the objects, display higher level controls (sequence visualizations, recipe management, etc.). To fully and properly test those, the function needs to be in the PLC AND on the HMI. It's hard for the PLC programmer to test without visualization, and it's hard to verify visualization without supporting logic.

In that respect, it's just as correct so say that for the PLC program to do everything you want it to do, it has to be entered into the HMI.

There are all sorts of tricks and work-arounds to do things when one team isn't as ready as the other. Tag databases can often be managed in Excel, and so can point to dummy tags while waiting for the real ones to be created, and the final database can be loaded quickly.

Like I said, it's often an iterative process -- some HMI work (navigation with graphic placeholders), some PLC work (device-level control), some HMI work (device instantiation), some PLC work (sequencing), and back and forth until the project is done.

Thanks for the info now is there some thing that gives an in depth explanation of the bits bit word and word lamps and word bits something more then the manual like what how when and why.

What systems are you using/considering?

Um weintek MT6070iH and MT6071iP with Mitsubishi FX 2n and 3u?

Greg7683 said:

Thanks for the info now is there some thing that gives an in depth explanation of the bits bit word and word lamps and word bits something more then the manual like what how when and why.

Click to expand...

The short answer is "No". HMI software is like a canvas, brushes and paint. What images you choose to convey, and how you convey it, is up to your creativity.

Of course, part of the point of an HMI is to "tell the story" of the control system clearly, so that your audience is able to understand what is going on.

With that in mind, read your last post: no periods/sentence breaks; no commas between clauses, odd phrases like "word lamps"(?). You need to practice making yourself clear -- unambiguously clear -- in your thinking and expression, before you can hope to make a good HMI.

I recognize that it is the current vogue to write as you have. But you aren't limited to 140 characters here. The better we understand what you are after, the better we can guide you. We shouldn't have to GUESS. Neither should the operators of your system.

Some general HMI tips:
- Avoid superfluous use of color and animation. Color draws the eye to it. So using color to show that something bad is happening is a good thing. Lots of color, or spinning motors and flickering flames, can make a graphic look cool, but when they are "normal", they pull the eye away from the things that are not normal.
- A rule of thumb says that you should never be more than 2 clicks away from any graphic. This is not a hard-and-fast rule, but something you should strive for. The more buried important information is, the more likely it won't be seen when it needs to be.
- Operators tend to "live" on one, perhaps two, screens. They generally don't navigate much, so focus on presenting the information that they absolutely must know in one place.
- Try and forget everything you know about the system and the process and put yourself in the operator's shoes. What is HIS job? What does he need to know in order to do that job?

As for the tools themselves -- all those "bits" and "bit words" etc., that you asked about: those vary, sometimes greatly, by software. But they all work about the same: you put an "object" on the screen (simple lines and boxes, texts, sometimes specialized "numeric displays" or "entry fields" that simplify linking the data on the screen with the tag/register/address in the PLC, and then assign some animation (visibility, color, position, sometimes linked values) to that object. The values that control that animation may be from an HMI tag database (which manages the linking to the PLC addresses), or you may reference the PLC registers directly within the animation.

But your focus should not be on how to best use the tools that the HMI software gives you, but how to paint a clear, coherent picture using those tools. Yes, like in painting, there are techniques that can produce good effects, and can be more efficient and effective. But those will come with time; there is no shortcut, no manual, that will tell you what will work best for YOU. Only you can write that manual.

You will struggle with using the tools. But let me reiterate a point: even though YOUR focus will be on the tools and how to get them to do what you want them to do, your end user won't care -- or even know -- about them. Focus on HIS needs, not your struggles. It won't make your task any easier, but it just might produce a product that you'll feel more proud of in the end, and thus make the next one easier because of your good feelings towards your first.

Good luck.

I was just trying to understand what a set bit actually is im sorry im not as smart as you guys to explain everything as good as you guys want me to. I don't now what a set bit is I tried using google but nothing comes up to help me understand what a set bit is or a word bit I already wrote a working HMI with your guys help and I thank you guys for the help I don't even know what the x, y,m D bit addresses are all I know is they are letters.

Weintek told me that I just cant pick any address and think it is going to work I figured someone on here could point me in the rite direction to something that will explain it more so I would understand how to use them a bit better.

Hi A bit is a binary level thing that can be ON or OFF (1 or 0) so these are typically used for HMI buttons to send a command to the PLC (Motor Start) or indicate a state from the PLC to the HMI (Motor running)


It is common that a HMI button command will SET the bit in the PLC and some PLC code will reset that bit once it has done its job in the PLC


So a bit set is basically a HMI command to the PLC



Note: The PLC can also set bits but your question was about HMI

cjd1965 said:

Hi A bit is a binary level thing that can be ON or OFF (1 or 0) so these are typically used for HMI buttons to send a command to the PLC (Motor Start) or indicate a state from the PLC to the HMI (Motor running)


It is common that a HMI button command will SET the bit in the PLC and some PLC code will reset that bit once it has done its job in the PLC


So a bit set is basically a HMI command to the PLC



Note: The PLC can also set bits but your question was about HMI

Click to expand...

Thanks yup I am just doing the HMI at the moment because that's what we need right now

Aardwizz said:

The answer is 'no', 'maybe', and 'yes'.

When we start a project, the HMI team and the PLC team (assuming the projects are big enough for "teams" or one or more people; otherwise, its just one guy wearing multiple "hats") start on the project at the same time. The HMI team will start with stuff that the PLC (usually) doesn't care about, like screen navigation, security rules and the like. So that's the "no" part of the answer.

Much control system programming these days is sort of "object-oriented": that is, there is a chunk of code in the PLC (user-defined instructions / data formats) that manage all the operations for a "class" of device: motors, valves, analog inputs, etc. Similarly, the HMIs will often have a "library" of objects that perform all the animation for the motors, valves, etc. Sometimes these libraries will come from the PLC/HMI vendor, other times the client may have a company standard. But often they are created from scratch, based on the system's needs. Once the PLC and HMI teams agree on what functions will exist, and how they will be communicated, they can each independently go about building their own libraries of objects. Testing of these objects is often iterative, and a single instance of those objects will be created on the PLC and HMI to verify that everything works as its intended to. That's the "maybe". The HMI can, for a time, "fake" a PLC signal to verify function, but usually only on a limited basis.

Then comes the meat of the project, where the HMI team and the PLC team work to generate instances of all the objects, display higher level controls (sequence visualizations, recipe management, etc.). To fully and properly test those, the function needs to be in the PLC AND on the HMI. It's hard for the PLC programmer to test without visualization, and it's hard to verify visualization without supporting logic.

In that respect, it's just as correct so say that for the PLC program to do everything you want it to do, it has to be entered into the HMI.

There are all sorts of tricks and work-arounds to do things when one team isn't as ready as the other. Tag databases can often be managed in Excel, and so can point to dummy tags while waiting for the real ones to be created, and the final database can be loaded quickly.

Like I said, it's often an iterative process -- some HMI work (navigation with graphic placeholders), some PLC work (device-level control), some HMI work (device instantiation), some PLC work (sequencing), and back and forth until the project is done.

Click to expand...

So your HMI team just creates the screens and buttons and stuff and once the PLC guys put the program in the PLC you add the addresses to tge buttons in the HMI.

Greg7683 said:

I was just trying to understand what a set bit actually is ... I tried using google but nothing comes up to help me understand what a set bit is or a word bit

Click to expand...

A bit is a memory address that contains either a '0' ("False") or a '1' ("True").

When changing the value in a bit, the bit is "set" (given a value of 1) or "reset" (given a value of 0).

Thus a "set bit" is a bit that has a value of 1.

-----

A "word" is an integer (number), typically consisting of 16 consecutive bits. Typically we think of that word as having a value -- say '5' -- but we can also look at that value as a binary value -- '000101'. Thus, in this word that has a value of 5, the first (usually called the 'zero' bit) and the third (the 'two' bit) are set. This can be a useful technique for packing information, with the HMI reading a single register, but getting lots of information about it.

What the meaning of each bit-in-the-word (or "word bit" as you're trying to use it, although I've never heard that phrase before) is up to you and the PLC programmer(s).

-----

Greg7683 said:

So your HMI team just creates the screens and buttons and stuff and once the PLC guys put the program in the PLC you add the addresses to tge buttons in the HMI.

Click to expand...

Sometimes it works out that way. Sometimes things are well enough planned out ahead of time so that both teams know what "rules" are going to used to define addresses. Thus the HMI team can link to registers that the PLC team hasn't created yet, but when they do, the links will work.

Time is money, and the bosses can't have someone sitting around waiting for someone else to be done before they can get started. A little bit of planning, a bit of asking "If I can't do X, then what CAN I do?" can speed things up greatly.

Good luck.