2 of 2 people found this helpful
It sounds to me like the customer delibarately changes the addressing of 'tags' in the PLC. Is that right?
If that is the case, then there must be some trigger, probably somebody starting this process, which can be used in your own process to update your pi tags.
I'd recommend to store this logic into your AF model which you will probably use for PI Tag creation. Using some scripting, you should be able use the AFUpdatePlugInConfiguration utility to bulk update your PI tags from AF. Or you can place all this logic into scripting and update your PI tags directly.
There exist 3 different kind of Modbus interfaces: PI Interface for Modbus Ethernet PLC, PI Interface for Modbus Plus PLC and PI Interface for Modbus Serial PLC. I however do not expect that either one supports what you are looking for. An Auto Point Sync (APS) connector doesn't exist for either kind. We have requested Technical Support to open a ticket for you and to find the answer for you.
Please note that Production interfaces like Modbus are not included with vCampus. Hence addressing questions like yours to Technical Support is usually the better option. However creating a programmatic solution to your issue if you know the change pattern as suggested by Roger makes it to a discussion again that absolutely belongs to vCampus. However, please work with the Technical Support Engineer that will contact you to find out if there's any mechanism with the interface that allows to handle PLC address changes.
1 of 1 people found this helpful
Any mechanism to modify tags to dynamically change the PLCs that the tags are associated with should consider consequences related to IO optimization that is performed by the interface.
Modbus is a very chatty protocol, with a max of 250 bytes in a response. The interface tries to optimize its requests such that contiguous registers are returned in a single packet to satisfy multiple tags in the same scan class on the same PLC. Once location2 is changed for a tag that was part of a contiguous group, at least one extra IO will be performed over the network to get the data, all other things remaining the same.
If you can place an OPC layer on top of your Modbus devices (you will need to check to see if it supports OPC protocols in the first place), you can get rid of OSIsoft Modbus interface and replace it with OPC interface that goes after OPC Item IDs. At least on the PI side of things, everything will remain the same even after dynamically changing the register addresses.
And you can research the feasibility of mapping your OPC item IDs to Modbus registers dynamically. May be this option might be easier than writing a custom AF SDK application that updates location2 codes.