Changing tag providers in a project dynamically

We have a hopefully not too unique situation...

We have the normal project which runs the HMI interface for our system, but we also need to support a "training" mode. When the client is in training mode it needs to update to a different tag provider that is fed from our simulation system and emulator.

To accomplish this we will create a second project that is nearly a mirror copy of the "live" project except an indication it is running in training mode. Here is the more difficult part, we can't change the tags because other clients may not be in training mode and need to continue operating normally. We can use the ignition.util.retarget to change projects, but the tag bindings and all the scripting will still target the "live" tag provider.

We are looking for some way to change the default tag provider for the current project dynamically without needing to go through every screen (over 100). Ultimately the training project would need to be updated each time the live project is changed, which would be a lot of manual labor.

Any ideas on how we can retarget both the project, and the tag provider? We can't change the OPC driver setting on the server either because that change would affect other clients... We are also trying to avoid having another server instance due to other project constraints.

Thanks in advance.

Have an unlicensed gateway that is an exact copy of the main gateway, but with the providers pointed at the data coming from your simulator devices. Any time your prod interface is updated, export from main gateway and import to 'training' gateway.

You can add in something to the main project to detect which gateway its pointed at to display the training mode banner.
Missed the comment about no extra server

Are all the tags in the project looking at a single provider? You might be able to remove the provider config from the project and make it inheritable. Then make 2 projects that inherit from that newly inheritable project.

One of these would be your 'Prod' project which sets default provider to A and the other would be a 'trainer' project that sets the provider to B. All edits are done in the inheritable project, and will be reflected in both the 'Prod' and 'Trainer' projects.

Otherwise you'll need to rework all of your bindings to be indirect and provide the provider name to each one. You could use a vision tag to hold the provider name(s).

Under no circumstances should you be training on your production gateway. The slightest admin/developer screw up and your trainees will be breaking your site. Don't do it. IMNSHO.

Fix this. Use 2-hour trial mode if you must.

4 Likes

There are no admins/developers on the site, updates to the project are vetted during a full system test and regression test off site and moved to production manually. I agree this is a "best practice", but there is a unique situation that drives the inability to add servers to this system (this is a floating platform, not a shore based system with unlimited weight/space/power).

We can't use the trial mode, even if it wasn't technically against the terms of the license our customer would never accept it.

Yes, all of them are a single provider ([default]), I understand that the shortcut in the tag of [] means the "default" provider for that project, it may be possible to create a new project with [] where [default] exists and just have the default tag provider different in the other project, we are investigating this as it was brought up by one of our other engineers.

You could pass the explicit tag provider to your components and use it in your tag path bindings which comes from a session custom prop. However as Phil said, if you miss one binding or usage in scripts etc., you risk reading/writing to the prod tag provider. I don't know if you can change the client's project instance's default tag provider on the fly, and if this would affect all clients or just the client you're training on..

All.

That's what I would assume, but perhaps there's a session-specific hook? :man_shrugging: