Greg7683
Member
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?
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.
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
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.
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
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.