• State Not Answered
  • Replies 8 replies
  • Subscribers 22 subscribers
  • Views 202 views
  • Users 0 members are here
Options
Related

How to script a "refresh" of a $UserDefined instance with attributes which are stuck with Bad data quality

JM

I am familiar with the following reconnection script for DI objects:

Expression (WhileTrue): Me.ConnectionStatus <> 2

Script body: Me.Reconnect = True;

 

Does a similar approach exist to refresh a UserDefined instance that has attributes with Bad data quality?

We are experiencing some issues with one of our OPC connections: When we lose connection to the OPC Server, it reconnects as expected, but some of the attributes which depends upon this connection do not update, as they get stuck with Bad data quality. When this happens, we have to manually redeploy the affected instances, after the redeploy has been completed all the attributes start to update as expected. Any input as to how this can be handled automatically with a script would be much appreciated!

IsBad() and _Attributes[] can be used to check if any of the instance's attributes has Bad data quality. The piece I am missing is how I can refresh the instance's connections in a similar manner to that of a redeploy. Maybe I can have a script which sets the InputSource of any Bad attribute to "---", before it resets it to what it originally was set to?

Parents
  • 0

    Hi!

    My initial reaction is that this is quite unusual behavior, as soon as the Device Integration object has re-connected, your attributes on Objects based on the User Defined should update the Quality status.

    There should not be a need to re-deploy any object just because a DI Object has recovered from a connection loss state.

    In some scenarios I have seen that non changing values stay at a BAD state until value changes, but that was due to the 'ways of working' of the OPC Server and not related to the communication mechanism in Application Server.

    There are some things you could try, what happens if;

    • You add the attribute to Object viewer, does it stay in a BAD state?
    • You add the communication reference to object viewer (<DIObject>.<Scangroup>.<item>), does this value have a bad quality? If not, did the quality state update on the Object too?
    • Is this behavior effecting all or some of the items that are connected to this specific OPC Server?

    You mention that you use the .Reconnect, this indicates that you are using the $DDESuiteLinkClient object, (The $OPCClient Object uses RestartReset to reconnect).

    This then requires a OI Gateway to access a OPC Data source, what is the state of the attributes in the Diagnostics view in OI Gateway? Are they missing in the list, or are they listed with bad quality (red icon) as well?

    It could also be good to know what version of Application Server are you using.

    And as a last comment, please verify the setting for Advanced Communications management, by default it should not be enabled.

Reply
  • 0

    Hi!

    My initial reaction is that this is quite unusual behavior, as soon as the Device Integration object has re-connected, your attributes on Objects based on the User Defined should update the Quality status.

    There should not be a need to re-deploy any object just because a DI Object has recovered from a connection loss state.

    In some scenarios I have seen that non changing values stay at a BAD state until value changes, but that was due to the 'ways of working' of the OPC Server and not related to the communication mechanism in Application Server.

    There are some things you could try, what happens if;

    • You add the attribute to Object viewer, does it stay in a BAD state?
    • You add the communication reference to object viewer (<DIObject>.<Scangroup>.<item>), does this value have a bad quality? If not, did the quality state update on the Object too?
    • Is this behavior effecting all or some of the items that are connected to this specific OPC Server?

    You mention that you use the .Reconnect, this indicates that you are using the $DDESuiteLinkClient object, (The $OPCClient Object uses RestartReset to reconnect).

    This then requires a OI Gateway to access a OPC Data source, what is the state of the attributes in the Diagnostics view in OI Gateway? Are they missing in the list, or are they listed with bad quality (red icon) as well?

    It could also be good to know what version of Application Server are you using.

    And as a last comment, please verify the setting for Advanced Communications management, by default it should not be enabled.

Children
  • 0 in reply to Richard Köhlerstrand

    Hi, Richard!

    Thank you for the detailed reply! It is much appreciated!

    1) I was a bit imprecise with the script (I just quickly copied it from the Training Manual when I wrote this post). We are using the $OPCClient template!

    2) We are using TOP Server with an OPC UA Client Channel. All the values recover fine in TOP Server and return to good quality. We have more than one OPC UA Channel, and it is only one of them which has this issue. The data quality in all channels look fine in TOP Server, though. 

    3) We are on AVEVA System Platform 2020 R2 SP1 P01.

    4) Advanced communications management is disabled.

    5) To somewhat answer your questions, Richard:

    What happens if;

    • You add the attribute to Object viewer, does it stay in a BAD state?
      • It stays BAD until I redeploy the object which is hosting the specific attribute.
    • You add the communication reference to object viewer (<DIObject>.<Scangroup>.<item>), does this value have a bad quality? If not, did the quality state update on the Object too?
      • I will have to check this the next time it happens. I do, however, believe that everything looked fine within the DI object. This might be, because the values were not present when viewed from the Object Viewer, if I am not mistaken. Will update this thread when I have more information on this. I will check if all items are present after a reconnect, I will also check their quality.
    •  Is this behavior effecting all or some of the items that are connected to this specific OPC Server?
      • The DI object in the IDE interfaces every Channel we have set up in TOP Server. It is only the objects which rely on the one PLC/OPC Server/TOP Server Channel which exerts this behavior. Also, I do not think that all items from the specific OPC Server are BAD after reconnects. I will have to check this and update this thread when it happens again. Since it happens very rarely, this could take some time. 
  • 0 in reply to JM

    JM - did you check with support and see if they have any information on this?  $OPCClient is one of those objects that I feel (maybe just psychosomatically) always has a hotfix hanging around. 

  • 0 in reply to Phil Wood

    I must agree on this statement, this does not sound like normal behavior and the above mentioned actions will help you sort out where the issue resides. 

    And since the $OPCClient object speaks OPC DA, witch I am personally trying to move away from, replacing it with DDESuitelinkClient <> OIGateway can be an option, at least where Suitelink is not possible, 
    But I do believe TOP Server can be activated to use Suitelink for Application Server to connect.

    At least try to avoid OPC DA over network. (It comes with lots and lots of DCOM Issues/challenges)

    Trond's mention verifying timestamp, witch is also a good thing to sort out.
    But this applies to both OPC DA, OPC UA and Suitelink since all can get timestamps from the source (PLC or Driver level).

    Please let us know how you progress on this! Slight smile

  • 0 in reply to Phil Wood

    Hi, Phil and Richard!
    I have opened a SR with AVEVA Support. I will ask for any relevant HFs once they reply to the SR. I will keep this post updated if I apply any HF that fixes the issue we are experiencing.

  • 0 in reply to Richard Köhlerstrand

    Hello again, Phil and Richard!

    Here is some additional information which I have gathered today:

    • You add the communication reference to object viewer (<DIObject>.<Scangroup>.<item>), does this value have a bad quality? If not, did the quality state update on the Object too?
      • When we are experiencing the issue
        • The quality is Good in TOP Server's Quick Client.
        • The quality is Bad in the OPCClient instance for the effected instances.
        • The quality is Bad in the effected instances.
        When I redeploy the effected instances (not the OPCClient instance!)
        • The quality becomes good again in both the OPCClient instance and in the effected instances.
        • I tried to toggle the scanstatecmd on the effected instances. This did, however, not fix the issue, a redeploy was required to restore the quality on the effected instances. I did not touch the scanstatecmd or redeploy the OPClient instance as this would have affected many instances which already had Good data quality. 
    • Is this behavior effecting all or some of the items that are connected to this specific OPC Server?
      • I do not have a concrete answer to this, yet. But the issue happened with another PLC/OPC Server/TOP Server Channel (I have not seen that before), thus my statement that it has only been happening to a single channel was incorrect. This makes me think that the issue lies with the OPCClient instance itself.

    Any input is greatly appreciated!