DeltaV Live VS DeltaV Operate Connection Speeds

I would like to confirm if DeltaV Live is slower at creating connections for reading controller values than DeltaV Operate is?

 

I have found that when translating DeltaV Operate CDs to DeltaV Live that I ran into issues when I need to read many values upon a CD being opened.

When I open a DeltaV Live CD which is required to read a 100+ paths upon opening, not everything would load.

However, if I closed and reopened the graphic item, connections would eventually be made and once all values begin to read, everything then runs fine on the DeltaV Live CD.

However, the equivalent DeltaV Operate CD item works fine upon the CDs initial opening.

If DeltaV Live cant make connections as fast as DeltaV Operate, for me this would explain the design decision by PCSD team to split out  detail display tabs in DeltaV Operatel into individual Detail display which are then opened via the detail call up in DeltaV Live.

DeltaV Lives HTML5 scalable vector graphics have many clear pros over DeltaV Operate. But I would be grateful to confirm what the cons/limitations are in comparison to DeltaV Operate.

This would help me make better design decisions and help me justify to people when I need to deviate from an approach taken in DeltaV Operate.

  • Interesting "If DeltaV Live cant make connections as fast as DeltaV Operate, for me this would explain the design decision by PCSD team to split out  detail display tabs in DeltaV Operate into individual Detail display which are then opened via the detail call up in DeltaV Live"

    Have not seen the PCSD library, if I am to understand what you have said here, does the PCSD library break out all of the detail display data into multiple Context displays?

    I am having a lot of issue with the Tab GEM that is supplied, and if they had the same issues with the Tabs that I am seeing then this also may be a reason to break away from the tabs and have multiple Context displays in place of the tabs

    Do I have the understanding correct?

  • In reply to Benji_Kidmose:

    There are a couple of things here.
    First, the DeltaV communication layer optimizes data transmitted based on active use. Unused values are pruned to make room for active comms in the comm layer. Always has been this way. Now, DVSYS and DLSYS both interact with this communication layer and if a parameter is not currently available on call up, the behavior of Live vs Operate comes into play. This can be difficult to test as by calling up a new set of parameters, they are there on the second call up and depending on what was done previously, a parameter may work find sometimes and is slower to update other times.

    The values that are present in the main GEM are established when that picture opens, so they are available immediately to a Detail display or Faceplate.

    For those parameters that need to be "re-added" to the communication layer, like the 100+ variables in this example, how are they configured in Live vs Operate? (DLSYS[tag] or DLSYSCond_Read(Tag/Path).value. with or without a default value? The conditional read with default value is intended to replace the OK NOT Configured option so that a common GEM or CD can be used with similar modules that may not have all parameters the GEM looks for. IF not present, the conditional read uses a defualt value and is happy.)

    Our library has followed the approach of having a second CD for Interlocks and such, tied to the DCC blocks of the module. I think the main reason for this is that you can solve the Module status health data and the Asset Interlocks conditions separately and have a common motor Detail display with a choice of Interlock CD's based on the module design, and no so much a parameter performance issue.

    Is the issue that the data never comes up in the Live CD or that the value is momentarily unavailable, but populates on its own? and How long does it take to resolve if it does on its own? (without reopening). I haven't observed any parameters no populating in my detail displays or that they are noticeably delayed. I could check behavior if you could describe how these parameters are configured, and what values are and are not affected.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Prompted by this question, I dug into my CD with tabs a bit.

    The Tab Object allows you to easily add up to 32 Tabs, and has a complete set of properties to define colors, fonts etc. I did have a conversation with a PCSD savvy colleague and he pointed out that they use the TAB object just for the Tabs portions, much like Operate did. The then create the displayed data under the TAB and use the TAB.tabselected property to animate what data is shown.

    So rather than the OOB implementation, the TAB object would only be as large as the Tabs configured. Underneath it, or above, create the content and group it. Say grpTAB1, and animate this tab when tabselected ==1. Now you can work in the group, use Add to Group and use the scroll buttons to move items within the group.

    I tried adding more buttons to the Tab object, which was easy to do. But I found it easier to copy and past an existing Tab. The reason is the copy preserves all the property settings of the Tab. When I added a tab sing the tab properties Tab Count, all the properties of the new tab are defaulted and not linked to any standards. Not sure I would want new tabs to have a different look and feel.

    In my existing Tab, the tab is sized to include the objects for that tab. When I added a row of tabs, none of those items were moved. They are referenced to the overall tab size and not the available area under the tab. I would have to go into each TAB and reposition everything based on the new tab. Same if I change the tab from top to bottom or buttons on left or right. The content in each tab has to be repositioned. I would have expected that all the positioning properties would be referenced to the upper left of the data window area.

    Now, if I grouped all the items in a tab, repositioning that group would be relatively easy. But I would also have to adjust the overall tab size.

    So back to Benji's challenge, I'd suggest using the Tab object in the CD and ajust the TAB oject size to only show the tab rows, and nothing more. Then, create your Tab pages as groups, and set visibility to match the associated Tab. You can then use the Group visibility buttons to easily access each group and not have to deal with selected Tab and Tab Page and losing items when you hit a scroll button.

    You can then have a set of Tab Standards to use in both the Tab object and the Groups so the presentation is consistent based on Standards.

    Andre Dicaire

  • In reply to Andre Dicaire:

    So, if I am reading this correctly, just use the Tab Object much like the MS tab Active X, where it can give you buttons with some sort of standards, but dont put your groups on the tab drawing space for each tab, instead use visibility on your groups based on Tab.Selected? So essentially what I am thinking of doing but using my own made buttons? Alright you have me convinced to try again lol
  • In reply to Benji_Kidmose:

    So many ways to skin this cat once you are prepared to do scripting. Totally agree with you that the OOB tab with contained items is too problematic. The PCSD library just uses the tab object for the tabs.

    I'm going to change to a TAB object but separate Page groups with visibility of the group on TagSelected. Solves so many issues (oops I said it) and supports the Add to Group option when modifying the display. Hmm.

    Good luck Benji.

    Andre Dicaire

  • In reply to Andre Dicaire:

    So for my scenario, I use Await DLSYS.CondReadAsync within a OnOpen script of a popup to iterate through 100+ paths.

    I need to use the await Await DLSYS.CondReadAsync and cant rely on using a fall back as we populate a drop down menu with the read values.  So if I used fallback my menu would be useless in scenarios where a value did exist.

    However, your comment about the communication layer may have explained why my MacGyver-Ish solution to my problem worked.

    As I noted that my popup dropdown would always work on second opening to me it appears that once connection are made it would run lighting fast. So, now I read the 100+ paths upon the detail opening to make/buffer some connections but I do nothing with the values.

    Then when I open the popup for the dropdown menu, I read the 100+ paths again but this time I work with the values. I was genuinely amazed this worked hence why I created this post regarding DeltaV Live connections to make sure there was rational to why this is working for me.

  • In reply to Frank Kelly:

    Frank, you need to wait for all the ReadAsyncs at some point to complete before proceeding to populate the drop down. This would be done by populating an array with the result of the writes and having a line of code waiting for the them to complete, i.e. let results = await Promise.all(WriteArray)
  • In reply to Matt Stoner:

    Thanks Matt, Your suggestion to use "Promises" was exactly what I needed.
    All 100+ paths are read into the combo box entry now upon initial opening.

    Your approach of using “Promises” to which concurrently read values is clearly better practice than my previous solution.

    Do you know if there are whitepapers or some other resource that gave more scripting examples relevant to DeltaV Live such as using await Promise.all() ?

    I felt I made relatively good progress learning JavaScript/Typescript via online courses/resources, reading BOL topics and have been reverse engineering the supplied library.

    However there seems to be aspects of JavaScript/Typescript that are more relevant to more Open-Source web development than DeltaV Live.
    Any additional scripting resources tailored to DeltaV Live would be great as it would narrow the search space when learning Typescript as a DeltaV Engineer.

  • In reply to Frank Kelly:

    Unfortunately nothing other than what is in BOL and Graphic Studio help.

    I use the following sites and never took a formal Typescript class (I've had many other languages though but won't list to protect my age Laughing)

    You can google search for help as well but I have found since helping with prototyping/testing of Live since before it was officially released that the sites above give the best results.

    FYI, there is a GSC call NC-2202-1597 about running out of memory and suggesting not doing a lot of Promises (189 writes) and suggesting to group them but a hotfix was created for the issue in v14. I think you should be good in v15 but just letting you know of an issue.