Recent Control & Safety Systems Discussions
Similar Posts
DeltaV Live PCSD GEMs not dragging into watch area
DeltaV upgrade and PCSD Library
DeltaV Live : Pass context value from Gem to faceplate
Searching Dynamic References in DeltaV PCSD Library
PCSD EDC / PID GEMs Faceplate no option to change the requested mode
Share

Is the "Gauge" GEM missing from the DeltaV Live PCSD Library?

Is there a "GAUGE" GEM? 

There are examples of the DeltaV Live Gauge GEM in Live Videos and in a product data sheet. 

https://www.emerson.com/documents/automation/product-data-sheet-deltav-live-deltav-en-3869350.pdf 

Steven Cox

13 Replies

  • Matt Stoner
    Yes there is a gauge GEM...working on the status of this GEM as at one time it was suppose to be added to the product.
  • Steven Cox

    In reply to Matt Stoner:

    Matt, Thanks! We have some Process Engineers that would love to use these. Please let me know how we could add the Gauge GEM to our existing library.
  • Andre Dicaire

    In reply to Steven Cox:

    Steven,  I have these gauges on my system:

    Below is the export of them  that shows the Functions and Standards they use.  If I send you these, they would import these additional items if they don't exist.  

    The Gauge_EMR has been updated to use a Link Selection property for the source of the value.  the original is in L1_Guage_EMR. The default version had hard coded DLSYS[Gem.Tag +'/PID1/PV.CV'] references. I can send both for your enjoyment.  Though I'm expecting Matt's version to be better.

    The other two, I created based on customer examples.  The Sparkline gives a bit more context and was added for a demo.  These were done a couple of years ago and are just some examples.  I can send them to you if you like. No warranties implied.

    .

    Andre Dicaire

  • Matt Stoner

    In reply to Andre Dicaire:

    So the Gauge GEM didn't make the v15 release but here is the GEM that is shown.

    HPGauge.zip

    Andre, not sure if you wanted to attach a pic of the files (that is what happened) or all the files (that didn't happen)

    Hopefully my zip file works...

  • Martin Rooke

    In reply to Steven Cox:

    Research (for example, see towardsdatascience.com/gauge-bullet-charts-cfe171ca3094) suggests that vertical bars require the less cognitive effort than either gauges or horizontal bars. I think the spark line in Andre's example has potential in some applications, though.

  • Jim Cahill

    In reply to Martin Rooke:

    Thanks for the link,   ! The URL had pulled in the close parenthesis and broken the link. I've updated it.

  • Matt Stoner

    In reply to Matt Stoner:

    Couple notes...

    As Andre mentioned since this is not standard product there is no warranty and it's like you have developed

    There is a problem with the current configuration, insure that the Gem.Target.target has a value of 0 for No Target selection as shown in the pic below.

  • Matt Stoner

    In reply to Matt Stoner:

    Actually that didn't remove the runtime error either, this change does however remove the runtime error.

  • Andre Dicaire

    In reply to Matt Stoner:

    I was just showing the Standards and Functions that my GEMs would add to his system if he wanted them.

    One of the things I try to manage in Live is the proliferation of Standards and Functions. As you import items from different sources, you can end up with many duplicate items, like Standards for colors or fonts and functions. The database does not care, but it adds to the management of Themes and such. And you end up with multiple items that do the same thing and so you have to update these to have consistent behavior.

    I had a project with an integrator, and three additional solutions providers import their various components into the same Live database. Result, 5 versions of standards for the same thing (the OOB standard was there and none of them used it.)

    That's why I'm a big proponent of the Style Guide document that should define all the standards and Functions "approved" for use on a system. Any work done to be imported into a production system should be done using the "toolkit" library from that system. Any new Standard or Function has to be approved by confirming there is no existing item that would serve the purpose.

    In my Dial GEMs, I added some color standards and a couple of functions. The F_GUAGE_FONT function adjusts the Font Size based on the size of the Dial if it is stretched. If a system already had a Dynamic Font function, they might want to replace mine and align behavior with theirs. I would do that. Same thing with some of the standards. Maybe they don't need or want a S_DialBckGrnd color standard, and want dials to follow an existing color standard. The fewer standards, the better, I think.

    If I've used OOB Standards, they'll likely have the choice to skip. If they've deleted some OOB, my import will recreate them. I'd want to review these potential new objects and clean up the GEM before using it.

    That's why I showed the list.

    Andre Dicaire

  • Andre Dicaire

    In reply to Martin Rooke:

    I won't disagree with the science. But sometimes, we are asked to replicate existing designs. I find it easier to follow the "show that you are equal before you can show that you are better". Change takes time. So we built the dials that they liked very much. Then we moved on to improving the designs for better cognitive effect.

    Dials take up a lot of real estate for a single piece of data. Back in the early 80s, the PCON (pre Provox system consoles) had their deviation bars. They had no graphics. Values were normalized on these thin vertical bars and at a glance, you saw what was normal and what was not. Much like the wall of single loop controller gauges from AC squared where the Operator could see PV's out of normal position based on what normal looked like, normally. Our current vertical L2 HP Bars in Live recreate these same concepts. We've come full circle it seems.

    Anyway, dials are an aesthetic approach that some users really like in some situations. I like a dial for my speedometer on my Jeep. I like sliders and bar graphs on my digital audio mixer controlled on my iPad. And a row of dials can also be appropriate if the space allows. But vertical bars are by far most efficient in space and pattern recognition. In my opinion.

    Andre Dicaire

  • Steven Cox

    In reply to Matt Stoner:

    Matt, The gauge worked great. Thanks for your help!
  • Steven Cox

    In reply to Andre Dicaire:

    Andre, I would be interested in giving the different gauges a try and let the Ops Team decide if one gauge provides an advantage over another. We are planning on implementing Level 2 graphics for the first time and many believe the gauges will improve the operators recognition of the pressure readings. This is especially true when the graphic contains 20 to 30 vertical bars for the level, temperature, and flow readings.
  • Martin Rooke

    In reply to Andre Dicaire:

    Wise advice, Andre. We're currently working with Emerson to develop a style guide in preparation for migrating a couple of older DeltaV systems from Operate to Live. Hopefully we can maintain a relatively "clean" database going forward :)

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.