It can get a little confusing if you start configuring Ignition Tag permissions because the OPC UA server uses a different authentication profile by default, though I'm not sure it actually matters in this case.
I'm evaluating some Ignition features for a client. We would like to perform supervisory control functions using python against the Ignition OPCUA server, which will provide access our ModBUS (and potentially CAN) devices. Might run it all on a Revolution Pi or some such.
By default the server just exposes configured devices, some of which will have browseable tags by default (e.g. Logix), some won't (Modbus) - depends on the protocol.
Exposed Tags exposes the Ignition Tags that you've created in each Ignition Tag Provider. Many of these might be OPC tags from Ignition's server or other OPC servers you've connected, but it also includes all the memory tags, expression tags, UDTs, folders, etc... that you've built out in your Ignition tag model.
Access the devices directly for a Kepware-ish experience, though that's not an experience we really focus on making great. Access the tags via exposed tags if you want a way to integrate other systems that can act as an OPC UA client with Ignition's tags.
Yeah, I get control isn't Ignition's thing. But for some supervisory use cases like energy management, might be just the ticket. Throw out the cumbersome PLC and program with Python against tag namespace to get the job done.
I just finished some benchmarking with local simulated ModBUS device mapped into Ignition tags. By cranking up the tag group polling rate I'm seeing nice roundtrip write/update times averaging 20ms. I know java GC, networking etc. will push this up, but looks good for our needs.