• State Verified Answer
  • Replies 11 replies
  • Subscribers 15 subscribers
  • Views 991 views
  • Users 0 members are here
Options
Related

How to upload changes to objects using scripting from OMI runtime?

Vaibhav Pandey

Hello All, I am trying to find a way to update my object attribute values such as alarm Hi limit, lo limit, initial values, etc. (integer, float, boolean) from runtime itself. Is there a way for me to make these changes like an upload change function that I can use from buttons to specifically upload selected values to the object? I am having to do this because there can be situations in our project where we won't be able to "Preserver Runtime Changes" when re-deploying engines because of some bugs we are encountering. I am hoping there is way to force update the object when someone updates the alarm limits from runtime for example.

Parents
  • +1

    (Edited with some clarifications)

    Hi,

    In InTouch you have the Retentive value configuration witch retains configuration data on a tag between shutdown and start up of the application.

    But with Application there is no such thing and for years there has been different approaches to resolve the issue you are describing.

    The Upload Runtime changes is one, but it will retain ALL settings and you have no control over witch of the settings are saved, performing this in IDE will save alarm settings, comments, data source configuration etc.

    This problem was resolved by introducing the Preserve Runtime changes setting on the deploy prompt, and you can configure an attribute to align to this setting. But as you say it is not always 100% reliable, certain configuration changes on a object will upon deploy disregard of the setting and I would advise to test the function if you come to rely on it for production data.

    AND if you find bugs or issues, report it to AVEVA tech support.

    So back to the Upload Runtime changes, witch is one option.

    There is no native way of triggering this action from OMI but the GRAccess Toolkit allows for programmatically perform Upload Runtime changes.

    In similar scenarios I have created a 'helper object' (using GRAccess in script) that you can trigger to perform this action, and similar from any other instance/object. using this method i have created self configurating applications and applications that can create, modify and deploy objects without the usage of IDE. Big disclaimer here, GRAccess will require a license for connecting to the galaxy as a development session, so make sure that the object is deployed on the node that you are normally use IDE on, or make sure you have enough development licenses available. GRAccess is not a free path to development actions Slight smile

    Another workaround is to store requested limits / configuration in a database, or even in xml files, reading settings upon deploy.

    If you have them in a database it allows for easy bulk modifications and customer documentation.

    The solution of using external storage of important configuration data is commonly used in many systems, and as mentioned, there are several methods in doing so. I would say using a custom database is very common.

    Triggering the read configuration upon deploy. Note, to NOT put the database access in the Onscan or startup script since it can effect your deploy stability, there are some good examples on how to implement scripting that triggers on deploy in the Scripting Guide from Aveva.

    And to support the update of values you store upon the change of data.

    Same thing here, it is not advisable to put the 'save' of data in the Offscan or Shutdown script for the same reasons as Onscan/Shutdown.  

    From GRAccess manual:

    Upload Method
    Uploads AutomationObject configuration changes made at run time.
    Class
    IInstance
    Syntax
    [C#]
    void Upload(
    EAutomaticallyUndocheckout automaticallyUndocheckout,
    ESkipOtherUsersCheckedOutObjects
    skipOtherUsersCheckedOutObjects,
    ESkipObjectsWithPendingUpdates skipObjectsWithPendingUpdates
    );

  • 0 in reply to Richard Köhlerstrand

    Hey Richard,

    I just came across your tip here.
    Do you know what is Aveva's Developement general opinion about using GRAccess in runtime scripts?
    Is this recommended?
    I had already found the following opinion in the forum: ( Scripts using GRAccess )

    Pulled out of the context of my entire answer this text is a bit confusing so let's see if I can explain it better.

    The main point is that Application Server is not like a programming environment where you create instances of objects dynamically. The GR is the master copy of you application and if changed based on state of the process, you will not be able to redeploy the system in its original form. Changing the GR from runtime would compare to doing runtime changes to code stored i a Source Safe. What happens if the script is interrupted due to excessive system load of computer malfunction? Then the master copy of the application might get corrupt.

    Also, the templates you create in Application Server should serve as internal standards and model typical behavior of your plant equipment. Changing this on the fly might break such standards and make it difficult to keep track of, and document, changes.

    One last argument is that while it is technically possible (and if you still want to go ahead) you will need to install ArchestrA IDE and a Wonderware Development Studio licence or every computer where you want to deploy objects hosting this script.

    I am not familiar with your specific case, but I would like to caution you from using GRAccess for runtime use. If you need to store data somewhere, use a SQL database, web services or XML files. GRAccess is a tool for developing an application. In rare cases it can be used to retrieve information about the system configuration for runtime use.

    Regards,
    Rickard

    However, that was some time ago.
    What do you think the current status is here?

    Thank you in advance for the information!

    Best regards
    Mario

Reply
  • 0 in reply to Richard Köhlerstrand

    Hey Richard,

    I just came across your tip here.
    Do you know what is Aveva's Developement general opinion about using GRAccess in runtime scripts?
    Is this recommended?
    I had already found the following opinion in the forum: ( Scripts using GRAccess )

    Pulled out of the context of my entire answer this text is a bit confusing so let's see if I can explain it better.

    The main point is that Application Server is not like a programming environment where you create instances of objects dynamically. The GR is the master copy of you application and if changed based on state of the process, you will not be able to redeploy the system in its original form. Changing the GR from runtime would compare to doing runtime changes to code stored i a Source Safe. What happens if the script is interrupted due to excessive system load of computer malfunction? Then the master copy of the application might get corrupt.

    Also, the templates you create in Application Server should serve as internal standards and model typical behavior of your plant equipment. Changing this on the fly might break such standards and make it difficult to keep track of, and document, changes.

    One last argument is that while it is technically possible (and if you still want to go ahead) you will need to install ArchestrA IDE and a Wonderware Development Studio licence or every computer where you want to deploy objects hosting this script.

    I am not familiar with your specific case, but I would like to caution you from using GRAccess for runtime use. If you need to store data somewhere, use a SQL database, web services or XML files. GRAccess is a tool for developing an application. In rare cases it can be used to retrieve information about the system configuration for runtime use.

    Regards,
    Rickard

    However, that was some time ago.
    What do you think the current status is here?

    Thank you in advance for the information!

    Best regards
    Mario

Children
  • 0 in reply to Mario

    Hi Mario,

    I agree with Rickard that using GRAccess in a "low code system" requires some thought and you have to be aware of the effects of modifying configuration in/from runtime. The intension with GRAccess is to enable bulk modifications. You need to ensure a robust error handling and it has to match your backup strategy and version management of the Galaxy. and if you run in to issues with your galaxy it might be a challenge to get support from your Aveva tech support engineers. And as stated, the connection made by your object will require a development session in the perspective of license. The points made by Rickard are still valid.

    And lets say you do modifications from an object hosted on the same engine as your production critical objects, time consuming tasks will require you to manage asynchronous execution to avoid locking your object executions.  

    But with all that said it is still possible to utilize GRAccess to make changes to your system in "runtime".

    There are some systems I am aware of where this is implemented in but the term "recommended" is diluted some by that this moves the responsibility from (supported) core product functions to you as the developer.

  • 0 in reply to Richard Köhlerstrand

    Thank you for your assessment Richard.

    Best regards

    Mario

  • 0 in reply to Mario

    Hey, that looks like one of my old rants Smile

    I think my perspective is pretty much the same as way back then.

    Furthermore, Upload Runtime Changes is a "funny" feature given that it offers no granularity and may update a bunch of things beyond the intended scope. I would make extra sure that it will not perpetuate a transitory state that causes problems during a fresh deploy. In some applications it may work ok, but I can see some scenarios where it could cause problems

  • 0 in reply to rickard.norin

    Hey Rickard,

    thanks for your replay. Thumbsup

    Best regards

    Mario

© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.