There have been a number of questions asking about how to get user information from PAC Display back to the strategy, and that looks like it would be pretty hard. Fortunately, I don’t want to do that.
All I’d like to do is change the appearance of elements in PAC Display based on the identity of the logged in user, just like security attributes can be set. The strategy need never know. But I’d really like to hide a button if a user doesn’t have permission to press it, or at a MINIMUM, grey it out.
Once suggestion is to create a completely redundant set of screens for each permission level, with only the different functions changed, but that strikes me as absurdly overcomplicated. If I have three levels of security, I don’t want to have to repeat every change I make to a common element three times - I just want ONE screen where I can indicate visually which buttons aren’t available at the user’s current security level. Is this possible? If not, can I STRONGLY request it in a future release?
Could you have “launch” buttons on your first loaded window that utilize the security attributes and when pressed set a value in the strategy for the operators level? Then you can bind the visibility attribute to that strategy tag. Unfortunately this won’t work if multiple users are connected at the same time since it relies on strategy tags (though you could possibly run softpac locally just to use it to store this tag and have a localhost control engine in PAC Display).
I feel like there would be a way to do this using AutoHotKey. If you set up an AutoHotKey script to watch the login window, you could theoretically post the username back to the controller when a user logs in. Once you have the username in the controller, you could do any number of things with it.
The key thing here is that I don’t need, or necessarily WANT, to communicate the user back to the strategy. What if there were two users, of different permission levels, logged in from different HMIs?
“Who is logged in on this HMI?” is information that ought to be available, and usable, locally, without reference back to the controller. In addition to setting the appearance of a button based on the state of a controller variable, it ought to be possible to set the appearance of the button based on the logged in user or group, and there’s no reason for that functionality to require storing a variable in the strategy.
@alt: I definitely understand, and I realize my suggestion isn’t perfect. In my application, which obviously may be totally different than yours, I’d consider sending the username to a different strategy variable per HMI workstation. It’s certainly an imperfect solution and one with complications, but for some it may be better than nothing.
I’m bumping this, because I’ve had an issue arise where I REALLY need this functionality.
There’s a button that I absolutely must have available to one user but not another user for critical regulatory reasons.
However, while I can make the button not WORK for the disallowed user, as far as I can tell there is absolutely no mechanism to change the APPEARANCE of this button in any way. The button will be visible to both users with absolutely no change in appearance, and the only difference will be that nothing will happen when the disallowed user clicks on it.
Am I missing something? This seems such a blindingly obvious functionality that I continue to be absolutely gobsmacked that it isn’t available.
We are planning to move to a different brand of PLC for our next iteration, in part due to issues like this one.
@alt: the only other thing I would add from where this topic was a few years ago is that you do have options like using Ignition or even Node-RED for HMI purposes if you’re strategy is running on an EPIC or RIO device. In short, while PAC Display has a lot of nice features, it’s just not going to compete with something like Ignition. If you otherwise like the Opto22 product line and programming options, I would look into moving your HMIs to Ignition instead and you’ll be able to do what you want here as well as get access to a whole lot of other great features.
We have a complex, fully functional HMI built in PAC Display right now. Rebuilding it from scratch in another environment represents a lot of staff time, and if we’re going to be doing that anyway, we’re going to move to a hardware environment with a more robust software ecosystem.
I certainly understand that, however, making some changes to the HMI, without having to update your programming, hardware, and everything else seemed like it might be worth considering.
I’m just an end user with my own set of concerns and use cases, but having worked on PLC systems from a few other manufacturers, I actually think that finding a system that supports a more robust set of software may be a real challenge. I think Opto22 does a lot to provide very low cost software that does a really good job at most things, but they also embrace open standards to allow you to go beyond whatever limitations their software may have. I haven’t found another PLC system that does that to the same extent that Opto22 does.
The other solution I was offered by support was to just build entirely separate runtimes for the different user access levels, which would work, but completely breaks the point of having access levels in the first place.
What is the point of having access levels on login, if the only thing you can use them for is to invisibly break the functionality of certain buttons without any indication to the user that the functionality isn’t present, or why?
