Emerson Exchange 365

• Not Answered

Is reading/writing to local files during run-time in DeltaV Live possible?

Hello everyone,

In DeltaV Operate engineers were able to open files for reading/writing during run-time.

Does Graphic Studio / DeltaV Live have anything similar?

Any help is greatly appreciated!

Thank you.

• configuration
• JavaScript
• Graphics Studio
• Live
• DeltaV

James Podobea

• 10 Jun 2019 3:58 PM
• Cancel

12 Replies

• Daniel Parrish

  

  • 26 May 2021 8:44 PM

  Bump. In some of our Operate installations, we do read a few local text files for different reasons, I don't think that moving that stuff to SQL is going to be viable in every case, and I'm going to need to do something to read a file at some point. Even if I have to "get creative", what's the way to read from a file? I'd rather not have to become a pro web developer just to learn how to break out of the sandbox. :) Thanks in advance! -dap

  • Cancel
• Matt Stoner

  

  • 26 May 2021 9:25 PM

  In reply to Daniel Parrish:

  Currently there is no method to be able to open a file and this was done for Cybersecurity reasons in Live I'm told. The only method "currently" supported to get external data is the SQL method.
  I'm not sure of the plans for the future but I have brought this up a year or more ago about people reading files for "things" in Operate and will be migration issues. My suggestion would be to give the use case(s) and submit to User Driven Enhancement Program (UDEP) at userideas-emerson.com/about.html.

  • Cancel
• Andre Dicaire

  

  • 26 May 2021 9:39 PM

  In reply to Daniel Parrish:

  There is currently no supported way to interact with files as was possible with Operate. I've seen many sources online discussing how to interact with files in Typescript and they call for some additional libraries. I don't know if Live would allow such modifications or how to go about loading such libraries.
  
  Maybe it would be useful to have specific examples of why File access is desirable. Here are some examples I've seen:
  
  1. Use of an XML file to identify Plant Display Hierarchy for a Navigation Toolbar. Although Live now provides this natively, the Navigation bar is rather prescriptive in how it works and does not allow for targeting a display to a display frame by the Operator. We might have to create a custom solution if the OOB feature does not meet requirements.
  
  2. Parsing a download file such as MODT.SCR to get the Faceplate filename, without actually opening the faceplate file.
  
  3. Create a browser of History tags with which to open PHV or to configure into an embedded Trend.
  
  4. Exporting History Data to a CSV file. ( I can run the DVCHDUMP file and pass the tag and time span information but Live does not recognize the redirect to file. The syntax to redirect is somehow ignored, and the data is shown on screen. )
  
  Anyway, I agree with you that we need to be able to interact with files.

  Andre Dicaire

  • Cancel
• Benji_Kidmose

  

  • 26 May 2021 9:43 PM

  In reply to Matt Stoner:

  Matt, do you know if a method is available for file stream reading and writing for text files through the scripting? I have not tried yet, but this is going to come up as we convert as we utilize stream reads in couple of instances for Operations, and certainly for some custom tools we use that allow stream reading a text file of any number of tags to do mass changes to parameters in modules so that they come from the graphics and flag for upload (think of changing thousands of Alarm Priorities after an alarm rationalization, and not wanting to do downloads or write to tags one at a time)
  
  Writing from Excel using OPC will not flag for upload, unless you turn on that one bit in the registry, although I think that it is gone in V14

  • Cancel
• Benji_Kidmose

  

  • 26 May 2021 9:52 PM

  In reply to Andre Dicaire:

  Andre, one Operations example that we are working on now is Well suggested speed SP from Pad Engineers everyday, this shall come via a text file that is placed in x location every day on the network, do a few robo copies down through the layers and through the firewalls until this file ends up on the PIN. From there we will stream read the file into tags that have a "well production" daily plan for the CRO's.
  
  We are also going down this path for some optimization programs where we are planning on filestreamwriting to a text file and have a Python application read the text file, run some magic, spit out textfile and stream read the data for suggested Setpoints.
  
  The other big example of something that is used many times a month is the mass writes by file stream reads so that we can speed up work and flag for upload.
  
  File reading is a big need, the system only does so much, we need the ability to use our own tools to meet our needs, feels a little like cutting us off at the knees

  • Cancel
• Matt Stoner

  

  • 26 May 2021 10:10 PM

  In reply to Benji_Kidmose:

  You will need to have external app to read the upload files if you only have Live, I have used Excel to do this (prior to next item) or you can just use the Save to XML on the upload dialog to get the values (this is better than Excel because it only shows the last instance). This came with v13 I believe.
  
  Setting the OPC Bit to enable OPC uploads is still an option in v14.
  
  I know this is a specific instance for uploading but there is no method to interact with a file in Live unless we have access to libraries that Andre mentioned. I don't know where this will go but Austin is well aware of people opening/reading files in Operate.

  • Cancel
• Benji_Kidmose

  

  • 26 May 2021 10:16 PM

  In reply to Andre Dicaire:

  Thinking about this for a few minutes, Operate will be around for awhile, convert to Live and leave a single Maint Licensed station running Operate with a scheduler based on events to run the scripts that we require that can not currently be converted over, only needs a single graphic to run, with all the scripting left in the user defined. This may be the way to ensure that we don't lose functionality and can continue on with Live development and deployment whilst the scripting engine catches up to what we used to have.

  • Cancel
• RobPerry

  

  • 27 May 2021 12:13 AM

  In reply to Benji_Kidmose:

  It is possible to read a text file into Live via an embedded web browser but it is convoluted and in my tests it was only a few line of text.
  The operator can select a file and read it into a web browser either as variables or into an element. Then the browser can write that into Live provided a channel has been opened by the operator. In Live scripting can move the data from the display into configuration.
  Writing data out to a file by the same route seems to be blocked by the security setup.
  If you're interested I can share my example.

  • Cancel
• Matt Stoner

  

  • 27 May 2021 5:22 PM

  In reply to RobPerry:

  I would call that circumventing the product and not really Live supporting but that sounds like something I want NO part of at 2 am after 5 days of startup and only 5 hrs of sleep when/if it stops working.
  
  Probably the biggest fear I have with this would be that the embedded web browser is later changed with a workstation hotfix (Cybersecurity issue for example) and the logic that was working stops working.

  • Cancel
• Andre Dicaire

  

  • 27 May 2021 6:07 PM

  In reply to Matt Stoner:

  I have not tried this, and just spit balling... OOB, Live provides the SQL Data source. What if we create a simple table with two columns as Strings. An executable is use that parses any text file into this table, with line number in one filed and line content in the second. The file could also "clean up " the table by removing all entries.
  From Live, you would run this file and pass it the name of the File you want to process. When that finishes, you use the SQL Data source function to read the table into a string array, which you can then parse one line at a time.
  
  Using the line number, you could read each line, parse the path and value and write to a parameter or display text field. Once you reach the end of file, the command is run again with a keyword of "Clean Up" and it clears out the table.
  
  I know, its pretty expensive to stand up a SQL database just to process text files, but that seems to be the cleanest way to read files and stay within the lines of what Live can do.
  
  Writing data out to a file is another matter. But along the same lines, would it be possible to pass the entire line of Text to an executable that would then append this to a file. Or it would store the line in our SQL table and when finished would write the lines into a file. Again, convoluted, but once the executable is created, using it would not be that complicated.
  
  So specific, repeating tasks, a dedicated table in the SQL databsource could be created and populated independently, allowing Live to read the data from this file.
  
  Again, just thinking out loud...

  Andre Dicaire

  • Cancel
• Benji_Kidmose

  

  • 27 May 2021 7:02 PM

  In reply to Andre Dicaire:

  I think that the exploration of the limits of the Live SQL function will need to be tested. I have not played with it at all yet, but thinking that this is maybe a priority in coming weeks to fully understand the upper and lower limits. As far as getting data into SQL, good idea, that part creating a program that reads txt, and pushes it into SQL or pulls it out is simple enough. Understanding the limits of what we can do with that data once we read it into Live is the key.
  
  Can we write from Live to a SQl table?
  
  OPC reads/Writes to custom tools is the way I am leaning at this moment, and maybe leave all this file stream reading behind. A program I develop outside can read my text file then just read/write OPC to the tags I want.

  • Cancel
• Ben Merryman

  

  • 1 Jul 2021 3:33 PM

  In reply to Benji_Kidmose:

  You can do any query (including writes) that is allowed for the user you are logged in as. This would be set at the security permission on the SQL Server side.
  
  You can use this w/ a timer at the layout level to achieve a backend type system that is constantly running (be wary of SQL query floods if the query is very large, potential for heavy network traffic) or via button scripting etc.
  
  As far as I know, there is no way to read/write to anything but SQL w/ out doing some hacky web browser workarounds that would use the Live *.exe launcher function and more customized code built in that script.

  Ben Merryman

  • Cancel