https://emersonexchange365.com/community-hubs/deltav-community-connect/Control & Safety Systemsen-USTelligent Community 13https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11473/bypasses-and-simulations/25389Thu, 09 Jul 2026 15:15:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:f4e53ab7-24c6-4756-af0f-6d391122ec41Matt StonerCheck out this threadhttps://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11473/bypasses-and-simulationsThu, 09 Jul 2026 12:15:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:7034bb06-cd5a-4acb-87a5-c3b905fe46e8B JohnsonLooking for ways to view all current bypasses and simulations in DeltaV version 15.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11469/deltav-live---disable-evaluation-of-gems-online/25387Wed, 08 Jul 2026 18:49:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:a9bf6f90-6c56-48b7-97ef-d6b98431467bHugh BThanks Matt, This did achieve what I needed albeit it was a bit cumbersome to configure GEM overrides individually for all the components that would have bad status when no module tag is configured. For GEMs I am using the PCSD Gem package.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11472/editing-values-of-alarm-prioritiesMon, 06 Jul 2026 20:06:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:a7e28ff5-65d0-46cc-b98b-afe05a6c07f8Mark BendeleWe assigned the wrong area sequence numbers or values to a couple of new alarm priorities. Now we are not able to edit their values. I'm talking about the values from 0 to 15 related to say log, advisory, warning and critical. Are we not able to edit because we have alarms configured with these alarm priorities? Also, can we delete the alarm priorities and recreate them with the right sequence numbers without causing problems other than a temporary loss of alarms? We have to do this work on-line then update, because we are not allowed to download. I'm wondering about deletion and re-creation, because we have reached the limit of the number of alarm priorities.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25386Mon, 06 Jul 2026 19:31:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:5fb6f202-7e52-4f2b-966d-b4473573a10eKentThanks! I think this is going to be manageable until we get moved to version 16. Your help has been greatly apricated.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25385Mon, 06 Jul 2026 19:25:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:329a577b-d2b3-40bd-ad1f-d778814da1acAndre DicaireIs 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.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25384Mon, 06 Jul 2026 17:34:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:e3e085c1-958c-4b64-8fe4-37fe08593013KentThanks 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.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25383Mon, 06 Jul 2026 17:12:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:b32ed756-f720-4ef2-a3b3-73922442480aKent14LTShttps://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25382Mon, 06 Jul 2026 16:04:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:8d6fd8d5-2a64-49f9-baed-b009726c15d8Andre DicaireBy the way, what version of DeltaV are you using?https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25381Mon, 06 Jul 2026 16:02:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:4d0640eb-42ba-419f-b2e9-364da8833751Andre DicaireWhen 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.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25380Mon, 06 Jul 2026 15:06:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:d2d0922d-0805-48a7-b273-f1047affc247KentThanks! 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?https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11469/deltav-live---disable-evaluation-of-gems-online/25379Mon, 06 Jul 2026 14:56:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:be00fb71-96b8-40de-80ee-f94491bdcb4eAndre DicaireWhy do you see errors when there is no physical unit in a specific position? Is it because the control module ends up with a Bad Status because there is no IO connected for that postion? DeltaV modules don't appear and disappear in the controllers, so your GEMs would still be bound to something. Would be good for you to explain this in more detail. The DeltaV LIve health check on open displays does flag references that have a Bad Status. If the module/parameter exists but its Status is now BAD, I'm thinking the Conditional Read may still return the bad status as the parameter does exist. I'm thinking that is a communication layer status error based on .CST. I'd have to do some testing to confirm. If the module/parameter exists but can be BAD but you don't care, perhaps adding the .NUM or .STR qualifiers to the path will allow Live to ignore the status. You would need to use a visibility expression to hide the "unused" location. Another approach might be to modify the parameter paths based on what location is currently available using a script, maybe a time script that can update periodically based on changing conditions. The GEM would then be modified to bind to the appropriate module or unit. so that it is adjusting the runtime references as needed. One Gem to rule them all. You could position the GEM on the display and indicate which unit it is bound to, but all its references would be made valid through the script. Hard to say what the best solution would be given sparse details on where the error is generated. You're only telling us where the error is appearing...https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25378Mon, 06 Jul 2026 14:41:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:61522ed5-bdf0-4332-b4f4-07181f2eaf1cAndre DicaireDeltaV 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.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11471/validate-username-password-in-deltav-live/25377Mon, 06 Jul 2026 14:03:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:087bac1a-4103-46c8-a18a-1189e73bbcffAndre DicaireFirst thing to know is DeltaV uses the Windows User Authentication. It does not keep or manage its own passwords. So the question I have is, what are you actually wanting to do that you feel you need to prompt a user for his user/password information within the HMI? Maybe there is a way to do what you need to do that does not require any entry of user passwords to an HMI Script. Logging off the DeltaV user and forcing a log on would be on way of forcing a revalidation of the user. The Screen saver can be setup to auto logoff the current user, securing the console and forcing a valid user/password to gain access. The ESig allows for a re-entry of the user password to ensure the person performing the write is indeed a valid user, with an option to add a confirming user/password if needed. This is a function that passes the User Password securely to the Authentication server. What other use case are you trying to address that you need to "know" if the current user is indeed valid to do the next task? Maybe we can help find a solution to your problem rather than hack the user security of the system over a public forum...https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11471/validate-username-password-in-deltav-liveFri, 03 Jul 2026 13:14:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:e74c7aa3-e576-47f8-bb5e-3d870f7e00dfStefan VraciuHello all, Does anyone know a way to validate a username/password combination in Typescript without using Electronic Signatures? Something like a function that could validate if given credentials are valid. I saw the ValidateEsig functions that are mentioned in the Script Assistant but wondering if something similar exists without using electronic signatures. Thanks, StefanDeltaV #DCSDeltaVhttps://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11467/finding-where-a-given-gem-is-used-in-live/25376Thu, 02 Jul 2026 18:45:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:eac3ee86-b734-43b9-a0d6-6403135f6cdaKentI'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.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11470/process-history-view-on-deltav-13-3-1/25375Thu, 02 Jul 2026 13:07:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:2068bd57-2680-4d14-9c57-e8815e27b7a0Caleb HollandI restarted the application station vm and historian data started logging after the reboot. Thanks for your help!https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11470/process-history-view-on-deltav-13-3-1/25374Thu, 02 Jul 2026 12:01:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:d59eb974-e327-430a-8798-609e58a81a19Caleb HollandHey Matt. I did download the continuous historian server after making the changes.https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11464/how-do-i-know-if-my-m-series-8-wide-carrier-was-manufactured-after-2002/25373Wed, 01 Jul 2026 19:37:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:a3893e5e-40c7-4af7-9249-54cf772f362cRune ReppenhagenYes, that is correct!https://emersonexchange365.com/community-hubs/deltav-community-connect/f/deltav-discussions-questions/11470/process-history-view-on-deltav-13-3-1/25372Wed, 01 Jul 2026 19:32:00 GMTcd40bb2b-3d49-4868-939d-417119b40291:10f8b009-3be2-43e5-ae5a-77056a486cd0Matt ForbisDid you download the DeltaV continuous historian after making the changes? When you created a new controller and then renamed, it likely has a different Node ID and IP address. PHV can still pull data from the control system for current data, only using the historian for past data.