• State Not Answered
  • Replies 13 replies
  • Subscribers 5482 subscribers
  • Views 454 views
  • Users 0 members are here
Related Posts
DeltaV Live : Interaction border for GEM
Issues with DeltaV Live GEM Instances
Where do you find your DeltaV answers?
DeltaV Live: Visibility property for GEM Class
DeltaV Live - Disable evaluation of GEMs online
Share
  • Not Answered

Finding where a given GEM is used in Live

I am looking for a method for finding all the places a given GEM is used in all of my Live displays.  In particular, I'm wanting to be able to look at all the Chart and Sparkline GEMs to check which tags they are referring to.  Is there an easy way to do this?

Kent

13 Replies

  • Matt Stoner
    Unfortunately Chart and Sparkline aren't GEMs but objects so you can't use the File Info to see where they are used like you can a GEM.

    You will have to export all the displays and then use Notepad++ to search the export files for references to <Chart Name=" and <Sparkline Name=" and they you will have all the references found by display and then result should show you the name of that item after the search criteria.

    After you find some you can look into further search methods to find the info you really want with Regular expression.
  • Kent

    In reply to Matt Stoner:

    Thanks! If I did the export, would it also carry with it the name of the tag used by each of the pens? If I can, I think I could make that get me where I need to be.
  • Matt Stoner

    In reply to Kent:

    yes, all of the information is within the export. Here is an example of simple sparkline and highlighting the tag reference:

  • Kent

    In reply to Matt Stoner:

    Yes. I found it. This should get me where I want to be. Thanks again.
  • Kent

    In reply to Matt Stoner:

    I've gone through this analysis. Unfortunately, I can't find the tags that are showing up in Event Viewer in any Charts or Sparklines. The tag are now things like XV-04/DC1/OUT_D.CV and XV-04/DC1/SP_D/CV. I tried to just add them to the historian and within a few hours the error reappears with a different XV. Are there other places in the DeltaV that would be trying to access the HDA server? All of the operator graphics involved with these tags are in Live. The error says "DeltaV OPC HDA Server Tag is unknown to DVCH". I have to say I'm puzzled by this.
  • Andre Dicaire

    In reply to Kent:

    DeltaV Live itself uses OPC HDA to retrieve data for Trends and Sparklines, unlike Operate which used an API call to DVCH. These OPC HDA client connections are separate from licensed connections for 3rd Party OPC HDA clients, like PI connectors.

    DeltaV faceplates in Live come with an embedded chart that dynamically takes on the "Dsp.Tag" module name to retrieve related data. If you call up that faceplate, the embedded trend resolves the DLSYS[Dsp.Tag + '/DC1/OUT_D.CV'] path, so you would not find this reference in the XML files based on a specific module name like XV-04.

    If you check the XML files, you should find explicitly defined paths as Matt describes. But the faceplate charts and Watch List sparklines would be generically defined with either Dsp.Tag or Gem.Tag type expressions.

    I'm not sure but it looks like you are seeing OPC HDA error messages for tags that are not in the historian and trying to find where these tags are configured in Live. Adding them to the historian would address the error message for those tags, since they would now exist in the historian. But I think the issue is from faceplate and watchlist references.

    I don't like that DC or EDC faceplates come with a trend for DC1/PV_D or DC1/SP_D. Historizing these tags is costly and does not really provide much value. PHV will display the event data overlaid on the EChart for doing SOE analysis, although you have to assign the module to the chart to get that. So you might want to assign the PV_D to history, and then let the Ejournal provide all other event data for the module for the timespan of the chart.

    In the Faceplate, I would remove the History chart and replace this with a Table object, populated from the Ejournal via a SQL query. The Table will add scroll bars and allow you to see a list of events related to the DC block (filtered on the module name). I would then add a click action to launch either a larger Popup with a more detailed view or a click action to launch PHV Event list for the module. By eliminating the standard Embedded Chart from the faceplate, you will stop the OPC HDA error messages.

    The Drag and drop feature in Live for Watch list and PHV will grab a defined parameter from the module and if you drag that tag to a Watchlist, and the tag path is not historized, you would likely still see the HDA message the tag is not in DVCH.

    Not sure if this is helpful. Suggest you test that the messages are indeed generated from faceplate call ups or Watchlist assignements.

    Andre Dicaire

  • Kent

    In reply to Andre Dicaire:

    Thanks! This has been very puzzling. I'm going to try an experiment over this next weekend. The tags that are showing up in this error are all on workstations that are not used over the weekend. I'm going to try turning Live off on a few selected machines to see if the errors go away or at least switch to different tags on VMs that are running Live. Does the faceplate need to be open for the it to try to access the data? If the problem is somewhere in Live, am I correct in assuming that turning Live off would prevent the graphics used on that VM would no longer make those requests?
  • Andre Dicaire

    In reply to Kent:

    When you open a faceplate with a trend object, it opens a connection to the OPC HDA server of DVCH and asks for the constructed tag for history, which may or may not be there.  It will then pull ongoing data from the Workstations local OPC server for that tag.  That way, the trend works with or without history.  The Trend does not ask the DVCH for history until it is re-initialized, so each time you open this faceplate from the GEM, the DVCH OPC HDA call is made.

    Can you post exactly where you see this message?  Is it in a log, or in the Live Health monitor?  Or is this in the Ejournal?  

    You can also look at the Faceplate display and check how the Trend Gem is setup to confirm this is the same syntax of your OPC HDA error.  Here is Emerson default EDC faceplate tha tuses the CD_FPTRN_3PEN_DC Gem.

    As you can see, it defines SP_D, PV_D and OUT_D for the parameters.  Inside the GEM, the Trend is configured as 

    With Gem.Tag coming from the "Dsp.Tag" and Gem.FB from "Dsp.Context1", the trend paths are resolved at run time when the faceplate opens.

    Interesting here is that SP_D and PV_D are set with the .STR qualifier, but OUT_D is not.  This may explain why you don't see the OUT_D parameter as an error, and only see PV_D and SP_D.  The .STR qualifier forces the comm layer to return the string rather than the integer value of the associated named set parameter.  However, I'm not sure if this creates a discontinuity with DVCH where the configured path in history does not contain .STR.  I saw an issue using the .NUM qualifier on an embedded trend, where history would not show for the tag, even though the tag was historized, but as a /PV.CV path.  I removed .NUM and the trend started showing history data.

    There are many layers here to evaluate.  I'd have to do testing to confirm if .STR is causing an issue.  But fundamentally, trending SP_D, OUT_D and PV_D of a DC or EDC is not an effective use of your Historian licensing.  I would consider trending only the OUT_D.CV.  The SP_D is captured in Ejournal as User Change and any failed start or loss of confirm will generate an alarm and using an E-Chart in DeltaV will give you a history of abnormal conditions affecting the asset.  One history tag allows the data to be viewed across the time line of the Chart, with all specific events listed in detail.  

    Andre Dicaire

  • Andre Dicaire

    In reply to Andre Dicaire:

    By the way, what version of DeltaV are you using?

    Andre Dicaire

  • Kent

    In reply to Andre Dicaire:

    14LTS
  • Kent

    In reply to Andre Dicaire:

    Thanks again. We've been doing some experiments that could be shedding light on this. We turned off Live for one of the reactors with the error. The errors went away for that VM but another set of messages came up from a different reactor. We shut down Live on that reactor and the error messages stopped completely. We opened up a Live graphic for the first reactor where we had shut down Live but on a different VM and even opened faceplates on it. The errors did not come back. We are bringing Live back up on the other reactor in an orderly manner. Since we are working on version 14, is it possible that there was a glitch in that version where sometimes a faceplate opened and did not close properly and kept asking for the data? The only reason I noticed it was that I was in the Event Viewer troubleshooting another problem. At this moment, I'm not seeing the errors coming back. We're going to be upgrading to version 16 very soon so if the workaround is close and reopen Live more frequently, I can live with that as a workaround. I hope that his holds as a fix. Thanks again.
  • Andre Dicaire

    In reply to Kent:

    Is it possible the is an issue in v14? I'd say yes. Lots of improvements in v16 for Live, especially in performance and such.

    You mention Event Viewer, which tells me that is where you see the OPC HDA messages. I was surprised when I found out Live used OPC HDA. Operate did not. why change it? but they did. Since it is transparent to the user, there was not much in BOL about that detail.

    We had some security issues with DCOM that impacted the OPC HDA connections, which is where I found OPC HDA messages in the event viewer.

    Anyway, it would be super useful to provide an example of the actual error message you are seeing. It helps to understand the lens with which you are seeing your issue. Bottom line, updating to v16 is your best path forward. If you still have issues, you will be at the latest version which will get the most attention. And if the issue has been addressed, you get the fix...

    Good luck.

    Andre Dicaire

  • Kent

    In reply to Andre Dicaire:

    Thanks! I think this is going to be manageable until we get moved to version 16. Your help has been greatly apricated.

This is the official online community site of the Emerson Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson'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.

Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2026 Emerson Exchange. All rights reserved.