Multiple users modifying the same screen objects

Ignition
1

Hi there,

I wonder if you can help me? I have had a quick look at other topics but I cannot see one that helps me, although I am sure this must have been asked before.

I am currently setting out on my first ignition project and I am trying to get some fundamental things sorted before we do. One thing that concerns me is that the system we are launching runs on multiple screens, set in different areas of the plant, which can be used by different operators. However, when one operator is modifying information on one screen, I want to prevent another operator modifying it on another.

For example, I may have a recipe that one user is modifying. I want to then lock that screen to that user session so that if another operator uses a different SCADA terminal they cannot access the same recipe screen until the first user has finished and closed it.

I cannot see how I go about setting this up or whether ignition handles this by default.

Any help on the above would be gratefully received.

Kind Regards
Kevin

2

You are right that Ignition doesn’t handle this by default, and doesn’t make it easy to handle this. But a lot depends on how your setup is done.

Ignition is most often meant to alter single data points (a bit to start something, a numeric parameter, …). Those can be written directly to the PLC, and if two people set something different, they need to communicate better on what they want.

Recipies on the other hand are complex data, and you can indeed argue that they should be locked.

If you use datasets, it can be very annoying. Dataset updates are not atomic. That means if user A wants to change row 3, and user B wants to change row 5, each of them downloads the dataset from the server, updates the row they want, and uploads the entire dataset back to the server. The one who updates it as last will win, the other change will be lost.
In that case, you may try to add locking f.e. by having a “locked-by” tag where you put the hostname of the client who currently has that recipe open. Then you can disable the interface if the “locked-by” tag doesn’t match the client’s own hostname.
But, as with many naive locking implementations, if something goes wrong, and the “locked-by” tag doesn’t get reset, nobody will be able to edit that recipe again.

I wouldn’t implement locking on datasets, but would only use datasets if it’s very unlikely that two people will edit the same recipe at the same time.

The recipe editor I once made, stored the data in a database. So every line in a recipe was a database row. If the user updated a step of the recipe, the DB update made it atomic (only that step, and even only that parameter of the step was altered). And thanks to Ignition’s native polling, it appeared a few seconds later on the other clients too (if they happened to have that screen open).

Phil had also given me some good advice on how to make sure you write to the database at the right moments. Especially if you switch recipes, and all values of your templates change, you have to make sure to not update the wrong recipe. His tip was to have a custom property named raw that always gets the data from the DB, but never writes. Then the actual component value is linked to the raw property. If the value changes, and the value is different from the raw value, it means the user has edited that field, and you should write it to the database.

2 Likes
3

Thanks for that, I guess that’s why I couldn’t find much out about it. I will see what the client wants to do in this regard but I wonder why ignition doesn’t offer a solution for this as it would seem a rather useful feature to have when modifying something like a recipe.

Thanks again for your response.

Kind Regards
Kevin

4

The main reason is because it’s hard. Modern databases have very thorough locking capabilities, where they try to put their locks as good as they can (for performance) but still allow the user to force some types of locking.
But you can still get into locking issues with those.

Windows has a much simpler locking strategy, but you also get into issues with file locking from time to time.

So if those big players can’t make it flawless, it will be hard for Ignition to do that.

1 Like
5

Thank you Sanderd17 - they are all fair comments and most useful.

6

Thorny problem, indeed. As @Sanderd17 noted, there’s no magic wand for this, at any level. In the recipe editors I’ve programmed, I don’t try to lock out other editors, but rather push updates to the DB as they happen, with notifications to trigger refresh of the possibly affected secondary editors (via system.util.sendMessage). The message payload would include enough detail that secondary editors would be able to figure out if they were working with the same recipe items, ignoring the message when not applicable.

7

I will speak to the client and see how they want to handle this but it maybe that we have to do something like you describe. If it’s OK I may come back to you for some information on how you managed to achieve it if that’s OK?

8

I'm happy to provide free advice on tools, techniques, and algorithms publicly on this forum. And occasionally post code snippets or helper scripts that I'm free to share. Beyond that is a bit fuzzy, at least for free. (: