What are the best practices when it comes to an Ignition HMI and restricting someone from remotely starting equipment?
All of the systems we build have safety but not every place we install has the best lockout practices and I want to be sure someone in the office doesn’t start the HMI and try turning the equipment on. We generally try to restrict control to line of sight.
I know I can check to see what the client computer name is and restrict that way but I would have to do that for every button on the screen.
Is there a way to make a vision client read only, and is making a client read only based on computer name the best way to do this?
I don’t know about the legal requirements at your location, but it is unsafe and normally not allowed to start safety relevant operations or machine movements only on a hmi screen.
The recommended way (and the only allowed way in europe at least) is a separate hardware enable switch in line of sight to the controlled equiqment.
I know this post does not answer your question, but you should definitely consider this.
If you write a client startup script that looks at the Hostname, then you can set the client read only like you were asking using system.util.setConnectionMode(). If you only want them to do it from one computer then it should be a very simple if statement.
That’s probably how I’ll have to do it. I’ve got three different clients that will have control in this system. Hostname work’s but I have had plant IT go back and change computer names before so I’ll have to be sure they are aware otherwise they’ll that HMI will no longer function for writes.
If they change the Hostname, are they fixed IP addresses or DHCP? If their fixed you can use that instead. Anything you use you always have the concern they can change it on you but I know with a lot of places the control system computers are a fixed IP even if the computer is replaced. When the computer is replaced though the Hostname is likely to change.
The other thing to keep in mind, if you set the system read only then everything about it is read only so if there are any other spots in your project that you want the operators to be able to enter data away from the machine it could still cause you issues.
For this case I don’t think it would be an issue. I’m mostly concerned with someone in the office opening up a client and pressing buttons without realizing what they are doing.
One downside is that this would disable a filtering drop down that I do on the alarm list but that is a minor inconvenience.
You can always use system.util.getConnectionMode() to see what mode your in and make it switch to read/write long enough to do your filter then change it back, through a script in your drop down. If that’s the only area you would need it able to write, that would be a simple solution to keep all functionality and still limit what they can do.
You just may have to change how your dropdown triggers the filter, you may have to set the value through a script instead of through bindings.
Isn’t there a login and profile associated with every users logged into Ignition to grant access right to different users? I am unable to understand the requirement!?
I would assume that the same user can log in at the machine and away from it so I believe he is trying to limit what they can do on the machine when they aren’t at the machine.
The question isn't about users. It is about the client machine where the project is opened, regardless which user. Client computers close to the machine (line of sight) will have write-access. Other client computers won't.
Oh sorry! I understood it now! Never thought of such a requirement before! Ignition users are ingenuous
I guess some interlock can be built in the control logic of the equipment or the HMI thru scripts with a bar code reader on the machine or something like that? Command is enabled for a few seconds only after the right barcode is read from the client or something like that? Just a weird thought.
I’ve done this before with a dataset client or memory tag, called something like HMIControlList, with two columns: area and ipAddressCSV.
Then on each Window you can have a controlEnabled parameter that checks whether the client should have control based on the area the Window belongs to and the ip address of the client (call a script library function on load).
Then you can use that in the enabled expressions for your input components on the Window.
If you are updating tags using scripts rather than bindings, it is also possible to put a wrapper around the tag.write function and check whatever properties you want before allowing the write to go ahead.