Gateway restore confusion about OPC connectors

I received a full gateway backup from a client in order to do some poking around/debugging. I don’t know what version the backup was created under, but as I am just looking at it and not actually doing any work on it I simply restored it to a 8.1.3 test system I had lying around. (Note that I did restore it disabled)

The test system is actually a cloned Linux VM that I use to connect Ignition to my local PLC on my local subnet at 192.168.100.82.

This is where it gets interesting. The project has a single MS SQL DB connector, and a single OPC Connector. When I inspected the DB connector I can see it points to the client’s DB.

But when I go to the OPC Connector configuration and select More=>Endpoint on the client’s only connector, in the “Server Discovery” page, the URL points at the IP address of my local PLC. This seems odd to me. I could rationalize it by saying that the webform is simply using a cached value of the last time I actually did an Endpoint discovery to my local PLC.

However when I go to the OPC Status page (after backing out of the Endpoint discovery), I see that this OPC connection is faulted (see below), but the error message also refers to my local PLC’s IP address. But I never explicitly set that IP address in any Endpoint Discovery - I always backed out of making changes. So I am confused as to why the GW restore still knows/uses my local PLC’s IP address.

So what should I expect with a GW restore? The docs say that OPC connections are a part of the GW backup. Could this be an issue from restoring from an older version?


The actual OPC connection error messages relates to a refused connection. I’m not concerned about that at the moment as I haven’t even loaded my local PLC with the client’s code, nor considered if they have security enabled on their PLC.

You sure they don’t just happen to have the same IP?

Nothing should change when you load a backup. You can send us a copy to take a look if you want.

:man_facepalming:

I just went and checked the client’s Hosts file. Out of all the dumb luck, this random PLC has exactly the same IP address as my local PLC (in a project that has about 40 IP addresses allocated to it). I feel like I should just give up right now and go back to bed. :roll_eyes:

2 Likes

Strange. This sort of thing is supposed to be reserved for Monday. :thinking:

Well I’m meant to be testing another project that is being delivered in two weeks, but I had this project dropped on me yesterday afternoon and told “Fix it ASAP”. So maybe the “Random coincidence on Mondays” rule has lower precedence than the “Panic work mode” rule? :thinking:

But I’m also experiencing the “PLC programming software starts to randomly crash when nothing has changed” rule. So I have no idea what’s actually going on.

1 Like

BTW I do have a related issue. As I mentioned, I restored the project “disabled”. What I discovered was that in doing so the default provider was disabled (as expected), but that meant that none of the GW tags were actually visible in the project. This sort of relates to my question from yesterday about not seeing any GW tags in the project. In hindsight this also confused me.

I expected points not to be updating, but I didn’t expect points to be hidden. I only saw the points in the project after I enabled the OPC connector.

Do you mean after enabled the tag provider? I wouldn't expect the OPC connection being enabled/disabled to have any bearing on whether you see OPC tags or not.

Oops … I used bad/wrong terminology.

Yesterday, after doing the GW restore/disabled, the default tag provider was disabled. From within the project I couldn’t see any GW tags, and I also couldn’t create any new tags.

Today, after I enabled the default tag provider on the GW, from within the project I could see that there were GW tags, and that I could create GW tags.