Deployment mode tag definition

[hulla]

Hello, is it possible to create deployment mode override for tag definitions?

I have the mode=prod active. I have tag provider plc_data. In other modes, the plc’s aren’t connected, so I want to change the paths to the prod’s OPC connection.

at http://localhost:8088/app/services/tags I created the prod override, but that only created config/resources/prod/ignition/tag-provider/plc_data directory structure. I would expect that the config/resources/prod/ignition/tag-definition/plc_data will be also created from the config/resources/core/ignition/tag-definition/plc_data structure.

Is there a way to do this? Can I just copy the directory? Is it safe?

[paul-griffith]

Deployment modes are an overlay on the base resource configuration defined in (generally) the 'core' resource collection:

Deployment modes override and rename to override with another type?

Deployment modes can change anything (though it's not necessarily recommended). If it helps, think of it as a single project inheritance tree. If you're in the dev mode, you're consuming external -> system -> core, then whatever dev defines, and then potentially overridden by anything local: Tree External External System System External->System Core Core System->Core Dev Dev Core->Dev Test Test Core->Test Prod Prod Core->Prod Local Local …

You can copy resources from core to a deployment mode at any time, you'll just have to re-scan your config directory afterwards if you do it while the gateway is running.

But conceptually it's important to only copy the specific paths/resources you actually want to override in the deployment mode, not absolutely everything, or you're giving up most of the benefit of the inheritance cascade.

[hulla]

OK, I needed to do stop and start the gateway. Now it works. I need to do more testing. I would like to update the prod GW during runtime.

Thanks for the reply. Unfortunately, I am missing something. I created a testing environment and started the GW in mode=crash.

I did:

cp -r config/resources/core/ignition/tag-definition/plc_data/* \
config/resources/crash/ignition/tag-definition/plc_data/

I did GW Scan File system,

git add config/resources/crash/*;

git commit -m “create crash plc_data copy”

Then I deleted tags via designer in plc_data tag provider and I imported my modified tags.json.

I get:

git status
...
...
modified:   config/resources/core/ignition/tag-definition/plc_data/plc_data/PV03_26/Valves_PCSAuto/tags.json
...
...

I see the core tag-definitions were modified. I expected that the crash definitions are active and that they would be modified.

ignition81
crash
Ignition standard 8.3.3 (b2026012009)

[hulla]

OK, I needed to do stop and start the gateway. Now it works. I need to do more testing. I would like to update the prod GW during runtime.

[paul-griffith]

@paul-griffith

you'll just have to re-scan your config directory afterwards

Scanning the File System for Deployment Mode Changes​ - Gateway Deployment Modes...

[hulla]

Thanks. It looks like a problem with the Designer. I created copy of tag definition from core to prod:

2003@ignition-prod:/work(main)$ cat ignition.conf | grep mode=
wrapper.java.additional.7=-Dignition.config.mode=prod

2003@ignition-prod:/work(main)$ ll config/resources/core/ignition/tag-definition/plc_data
total 4K
drwxrwxrwx    1 2003     2003         318 Sep 29 12:20 lab
drwxrwxrwx    1 2003     2003         408 Oct 28 11:37 plc_data
-rw-r--r--    1 2003     2003         135 Feb 26 11:43 unary-resource.json
2003@ignition-prod:/work(main)$ ll config/resources/prod//ignition/tag-definition/plc_data
total 4K
drwxr-xr-x    1 2003     2003         318 Feb 26 11:38 lab
drwxr-xr-x    1 2003     2003         408 Feb 26 11:38 plc_data
-rw-r--r--    1 2003     2003         135 Feb 26 11:38 unary-resource.json

git add .
git ci -m "cp plc tag def core to prod"

I did scan Filesytem, both for gateway and projects. I did it two times. I opened designer and created New Tag in plc_data root. The file was created config/resources/core/ignition/tag-definition/plc_data/tags.json. Which is wrong I think.

OK, I closed the Designer. Then I did:

2003@ignition-prod:/work(main)$ git st
On branch main
Your branch is ahead of 'origin/main' by 1 commit.

        modified:   config/resources/core/ignition/tag-definition/plc_data/unary-resource.json
        modified:   projects/minifactory/com.inductiveautomation.perspective/session-props/props.json
        modified:   projects/minifactory/com.inductiveautomation.perspective/session-props/resource.json

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        config/resources/core/ignition/tag-definition/plc_data/tags.json

git checkout . #reverts ...plc_data/unary-resource.json and session-props
rm config/resources/core/ignition/tag-definition/plc_data/tags.json

I did scan Filesytem, both for gateway and projects. I did it two times. I opened designer and I still see the New Tag in the plc_data root.

I did rename the New Tag to New Tag Edit. I did git status and I see:

git st
On branch main
Your branch is ahead of 'origin/main' by 1 commit.

        modified:   projects/minifactory/com.inductiveautomation.perspective/session-props/props.json
        modified:   projects/minifactory/com.inductiveautomation.perspective/session-props/resource.json

I bit expected the tags.json would be created again, but it seems its just in some buffer memory.

LATER:
My patience went off. I did restart the production GW. I opened the Designer and the New Tag is gone! I created tag Tag Later in the root of plc_data. And it works! The Filesystem Scan is broken in relation to the Designer. Somehow.

2003@ignition-prod:/work(main)$ git st
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   config/resources/prod/ignition/tag-definition/plc_data/unary-resource.json
        modified:   projects/minifactory/com.inductiveautomation.perspective/session-props/props.json
        modified:   projects/minifactory/com.inductiveautomation.perspective/session-props/resource.json

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        config/resources/prod/ignition/tag-definition/plc_data/tags.json

no changes added to commit (use "git add" and/or "git commit -a")

2003@ignition-prod:/work(main)$ cat config/resources/prod/ignition/tag-definition/plc_data/tags.json
[
  {
    "valueSource": "memory",
    "name": "Tag Later",
    "tagType": "AtomicTag"
  }

[dmcwilliam]

To expand on this topic slightly we are looking to do something similar and have different tags for our production and dev environments. Basically we would have the tags configured as memory tags in the dev environment and as OPC tags in the production environment, seeing as we don’t have the field equipment connected for dev.

Is there a way to import tag definitions for each deployment mode through the tag importer on the designer or does this have to be manually overridden using the json files? It seems whenever I do an import there it always imports to core regardless of the mode that the gateway is started in.

[hulla]

@dmcwilliam

To expand on this topic slightly we are looking to do something similar and have different tags for our production and dev environments.

you have to create the mode override first. for tag definitions this means cp -r the tag dir as stated above. then restart the gw.

I use export tags to json, then modify with a python script and then import back.

[amarks]

An easy way that I hand this is by just swapping the device names in the background.

For instance, you have 2 devices created - an OPC Device_PRO and a "simulated" Device_DEV.

When in "dev mode", change the Device_DEV device name to Device and leave Device_PRO alone. When in "production mode", change the Device back to Device_DEV and change Device_PRO to Device. Of course, this relies on the underlying OPC path and "simulated" path being the same - I would suggest using @pturmel 's IP module for your simulated OPC devices.

I've not used a mode override before and it's a little over my head at the moment, but it definitely sounds like a cool solution.

[paul-griffith]

With deployment modes, you could have a single "device" (addressed by name) and swap the underlying configuration to point to the real device/the simulator based on your environment. So you wouldn't need configuration in all your tags, it would just be an aspect of the gateway's configuration that changes.

[hulla]

We found a flaw to the copy method. We created a tag group hw_data with some dirs, like plc1, plc2. Then copy from config/resources/core/ignition/tag-definition/hw_data to config/resources/prod/ignition/tag-definition/hw_data. Then restart the prod gateway.

After the restart I reopen the designer. When I modify tags, the tags in the prod get changed. But when I create new directory, it is created in the core structure. What is even worse, when I delete a directory it is deleted in the prod and when I recreate it, it is created in the core. Now, we are doing this a lot, because the development on the PLC side is quite dynamic.

My goal is to have all device data in one tag group. In other deployment modes I have to run a script to redirect the tags to the prod server OPC server (read only). This is not optimal, but it worked, except the issue above.

Another idea is to redirect the device OPC clients to elsewhere? But I have no simulator, I am happy with the live data. The flaw above makes the solution very ineffective.

How to solve this? What are my options?

My other idea was to have all device tags in a group. Then access all these tags through the OPC loopback client. Then in other deployment modes redirect the loopback OPC client to prod OPC server. But my colleague argues that thats very slow, as there in extra communication level on the way. We have thousands of device tags.