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:
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:
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.
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 )
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.