Emerson Exchange 365

• Not Answered

How can we save/retrieve DeltaV floating point array to/from TXT file?

We use several floating point arrays to storage huge amount of process parameters (~10,000). However, we find out the Array data can't be recovered after power off the controller and cold restart.  So, how can we export/import array to/from any type of  file which can be safely store at Operate Station or Engineering Laptop ?

Our DeltaV system is PK controller Version 14.5 and use DeltaV Operate at DeltaV Panel PC.  We are not using DeltaV Batch.

Weiming Sun

• 7 Sep 2022 6:50 PM
• Cancel

19 Replies

• Weiming Sun

  

  • 15 Sep 2022 1:22 PM

  In reply to Chris:

  Thank you Chris. We will try it for our case. I might have more question once I start. Thanks again!

  • Cancel
• Andre Dicaire

  

  • 20 Sep 2022 8:16 PM

  Jumping in a bit late on this.
  
  Important Note>>>>>
  
  On PK standalone, Operator writes are captured and stored in the Power up directory on the SD card of the active controller, since the Pro Plus (Engineering station) may not be connected. Later, the Engineering Station can upload these changes to the database the next time it is connected to the controller. The SD Card writes will consume control CPU and could cause slippage of module execution, at least that is what the GSC explained. Randy points out that excessive writes to a controller will consume Control CPU and could lead to controller slippage, and this is true for DeltaV controllers as well as PK standalone. The PK standalone with SD card may be more adversely affected by writes than typical DeltaV controllers.
  
  .>>>>>>>>>>
  
  
  Istvan mentioned logging values in the Ejournal. This might be something to explore as both Operate and DeltaV Live can access a SQL data source. However, this approach would create the Write actions for every value updated, and if we follow the 20 values per second recommendation, that would 500 seconds to transfer 10,000 values. If you pursue this, you could create a module that reads the data from the Float arrays to create a concatenated string of values and write them in a sequential fashion as a series of LOG Events. There may be a limit of one log event per module execution. The module could read the data into string parameters and then pass this snapshot of values over multiple scans.
  
  But given the possible complications with how fast log events can be generated without "losing" an event, and how slow writes will be from the HMI to avoid overloading writes into the controller, you might want to go with the OPC UA solution. The PK's OPC UA server is unlicensed. all you need is an OPC UA client application that can write to the controller OPC UA server. Looks like XL report writer can provide the collection and write back. The question here is how to trigger the write back on demand on a restart of the controller. The OPC UA server has a limit on values per second in the thousands. So this would/could be faster that 8-10 minutes HMI writes would need to take. I don't know if the OPC UA server can map Float arrays. This might require that the data be passed in to parameters and a module would have to then update the array. But it would be independent of the HMI or DeltaV Communications.
  
  Another approach might be with a Modbus TCP driver. The PK also has the Modbus TCP server that could host 10000 input registers or 100000 holding registers. You could store the array data in these registers and have a Modbus TCP client read the registers and based on some trigger, write the stored values back to the registers. In a management module, you would pass the array data to the registers via external reference parameters. On a restart, the module would enter an initialization cycle that would read the registers and populate the arrays, waiting for some handshake value that confirms registers are ready for use. I believe the PK MODBUS TCP map is limited to 40000 to 49999 registers. But that is still 10000 values (or 9,999 at least). MODBUS data exchange could be accomplished in a few seconds. However, I'm not aware of a Modbus TCP client tool to recommend one.
  
  Using the OPC UA or Modbus TCP servers bypasses the DeltaV Runtime write mechanisms and avoids the limits of writes per second and the creation of 10,000 event records that would be created with HMI writes.
  
  Curious as to what type of data these arrays hold. How frequently does it change? how long do you have to recover the data after a restart? how often must the data be stored?
  
  I could see a module with say 250 parameters one for each float in the array, and a data tag, such that you write the data tag and data values to the module and the module passes them onto the arrays and clears the data tag. This tells the source app it can send the next Array, and so on. Lot's of ways to manage the exchange, either via OPC UA, MODBUS TCP or even module writes from HMI. But you have to respect each methods max transfer rates.
  
  All this is just thinking out loud. good luck.

  Andre Dicaire

  • Cancel
• Weiming Sun

  

  • 24 Oct 2022 6:12 PM

  In reply to Andre Dicaire:

  Andre,
  Thank you so much for these suggestion. We did successfully use VBA code to trigger the load data from CSV file which copy CSV data to parameter array in VBA of DeltaV Operate. However, we did observe the huge time different between full DeltaV system (MX controller, ProPlus server, AS station server,...) and PK standalone system(PK controller and OP laptop). To load ~8,000 data, full DeltaV takes less than 1 minute but PK takes more than 1 hour 20 minutes. Is it purely because the SD card function or the laptop memory limitation?
  The reason we need so much parameter data because we create a research DOE system: 40 continuous reactions each has potential 25 steps and each step has potential 10 parameters. We will like to use CSV file as recipe/data source. The DOE can be loaded when we select the recipe.
  Also, I heard the VBA code will not support in the future when Operate switch to DeltaV Live. Is it true?

  • Cancel
• Andre Dicaire

  

  • 24 Oct 2022 7:48 PM

  In reply to Weiming Sun:

  Writing from HMI to controller module results in Event Log change events and also Upload data storage. In PK standalone, each write must be updated to the SD card. This takes time as the expected rate of writes would be from manual entry. Excessive amounts of writes can interfere with unsolicited communications, or even control module schedule.
  
  I can’t say for sure why it takes 80 minutes, but I’d suspect the SD Card updates

  Andre Dicaire

  • Cancel