Recent Control & Safety Systems Discussions
Similar Posts
Is there a way to determine if a graphic has an active alarm via a singe parameter?
Export data from the translation guide in DeltaV Graphics Studio
Activate license control Studio
Active language in a type scripting code exspression of Control Studio
How to Separate and take only certain details and create individual alarms like active / secondary Power supply fail , active / secondary Ethernet port fail etc from the overall MAINT_ALM for a PK controller
Share

Graphics exporting - Active x controls

I am copying graphics from a running system to a simulation system, and my last challenge I hope, is the Unacknowledged Prompt Control embedded into many of the graphics. 

When I copy the grf files with the control to the PIC directory on the target system, Operate run/configure states it cannot load the control (even though the control DVBCtrlPromptsList.dll is the same version on both source and target system, and is properly registered and referenced).

When I copy the grf files to the desktop, then open them in Operate Configure:  no problem.  When I switch to run time on the fly: no problem.  When I save the desktop grf to the PIC directory within Operate Configure, then open in run time: no problem.

I have many files and I do not want to have to manually work each file individually in this manner.  Is there a wizard or a routine to get the copied graphics to the pic directory to just accept the control without the additional effort?

I've run into this before but can't remember how I've solved it other than brute force.

Thanks!

Youssef.El-Bahtimy
  • turtleranch
    We have transferred graphics back and forth from live to simulate without any problems. Our method is to copy the graphic, shutdown OperateConfigure/Run on the target system station, transfer the graphic into the PIC folder, then restart OperateRun (typically). This has been both single and mass file transfers. Perhaps we are not using the prompt control that seems to be your problem? The suggestion is perhaps if OperateConfigure/Run is operating in the background and therefore using the file, the conflict is created.
  • Matt Stoner
    Youssef,

    Take a look at KBA NK-1100-1090 and see if it solves your problem.
  • Youssef.El-Bahtimy

    In reply to Matt Stoner:

    Matt,
    That worked. (although actually getting the KBA document was tough, for some reason the Foundation Support Site doesn't search very well, even when giving it the KBA number. I ended up having to just append the KBA number to the base url to get at it.)

    I had originally done the standard act of shutting down operate (can't say I checked DVSYS, but it typically shuts down along side workspace if there's only one session logged in), copied in the files and restarted operate.

    I actually ended up brute forcing it in the method I described initially, turned out to only be about a dozen files out of the hundred or so had the control. I tested the KBA procedure out with my original work practice and I got no errors. I looked at the .grf provided, no code, just an embedded control. Weird.

    Thanks for your help.

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.