Emerson Exchange 365

• Not Answered

Data Structures in DeltaV

Hello,

I am new to DeltaV and am coming from a PLC background. I am working on a project where data structures in DeltaV controller would be helpful.

For example, I need to report production data to an enterprise system and buffer production data if communication to enterprise system is down for maintenance.

In an Allen Bradley PLC I would create a user defined data type structure array and buffer completed production data in arrays while communication was down. When enterprise communication is restored, buffer would be unloaded.

PLC Data type structure example:

CompletedBag[0].LotNumber   //string

CompletedBag[0].Weight    //Float

CompletedBag[0].HandlingUnit   //string

CompletedBag[1].LotNumber   //string

CompletedBag[1].Weight    //Float

CompletedBag[1].HandlingUnit   //string

Does DeltaV have same capability to create user defined data structure arrays?

Thanks for any input!

Drew

Drew Shumate

• 25 Jul 2018 1:34 PM
• Cancel

7 Replies

• Andre Dicaire

  

  • 25 Jul 2018 7:17 PM

  Drew, I consider a DeltaV Composite Block similar to a User Defined Instruction. You can create an assortment of parameters as well as specific logic to manage them. However, DeltaV controllers support only Floating point arrays. Your example above calls for String arrays that you cannot do in the controller. You could create multiple String parameters, but they can't be manipulated in the same was as an array can. You would need to use a number for all three pieces of information. You could create three FP arrays and use a CALC block to read new data and fill the arrays, up to 240 values in a single column array. or define the array as 3 columns x 80 Rows.
  
  But DeltaV is not a PLC, and the issue you solved with local arrays in the PLC is not typically something I'm concerned about with DeltaV. First, DeltaV controllers do not connect directly to your enterprise servers. The Controllers will serve data to an Application station and Historian would store time series data. For Batch systems, the Batch Historian would maintain unit and lot specific data in its SQL database. So typically, we would store data on this server, and make it available to the enterprise system.
  
  I don't know how your enterprise server is using this data, and if there is a better way to exchange it with DeltaV. If you ask only how to build something equivalent in DeltaV to what you did in the PLC, we might be missing the bigger picture that would reveal a much more elegant solution.
  
  As for managing an array, there are two approaches:
  - Fill the array by shifting data so that that latest value is in cell 1 and the oldest data is x number of cells down. Then you read data from that oldest location first and work up the array till you get to cell 1.
  - fill the array and keep a pointer to the latest value. The oldest value is in cell 1, until you roll over, and then the oldest value is 1 plus the pointer. This may be a bit more complicated at first, but not really. And it avoids a lot of processing as you don't move values before storing the new one.
  
  With the array parameter you can programmatically loop through the array to read or write as needed. The CALC block has the DO WHILE commands for this.
  
  Good luck.

  Andre Dicaire

  • Cancel
• Michael Krispin

  

  • 28 Jul 2018 4:50 AM

  In addition what Andre told about the composites. You might create a composite which includes only your parameters. The information to a specific value must be then CM-Name/COMPLETEDBAGxxx/LOTNUMBER. CM-Name means the control module name, because this composite must be online somewhere. COMPLETEDBAGxx means 1 to max 250 composites where xxx is a number 1 to max 250 per control module. That would represent your array.
  To address to a specific sub-parameter of this 'structure', you can build a dynamic reference like:
  '^/GET_LOTNUMBER.$REF' := "//CM-NAME/COMPLETEDBAG" + '^/INDEX-PTR' + "/LOTNUMBER";
  the parameter GET_LOTNUMBER then point to your COMPLETEBAGxxx number which is stored in the INDEX_PTR Integer type
  I suggest, use shorter names, because the limit is at 16 Chars for FB and parameters.
  Best Regards, Michael

  • Cancel
• Drew Shumate

  

  • 31 Jul 2018 2:09 PM

  In reply to Andre Dicaire:

  Thanks Andre for your input!

  • Cancel
• Drew Shumate

  

  • 31 Jul 2018 2:10 PM

  In reply to Michael Krispin:

  Thanks for your reply Michael. Ill dig into this when I get test system up!

  • Cancel
• Andre Dicaire

  

  • 31 Jul 2018 7:54 PM

  In reply to Drew Shumate:

  I wonder if the problem you are trying to solve is more of a PLC architecture issue and not really a DCS (DeltaV) concern. As you know, the DeltaV system is tested as a whole and the peer to peer communication is very robust. An Enterprise server would not be accessing a controller directly, and if the reliability of this upper level connection is problematic, maybe the solution is to store this information at the DeltaV Application station level. however you decide to solve this, you will have to decode the data in order for the Enterprise system to read them. As we've found out, there is no String Array in DeltaV, and creating composites blocks to hold data such that DeltaV can access them may not be a solution that lets the Enterprise system access easily.
  
  Which got me thinking of a couple of alternatives:
  
  First, you could simply historize these three values in the Continuous Historian. Since the values don't change between completed bags, a compression deviation of 0 would still result in efficient storage and ability to retrieve values using either Excel reporting tool or OPC HDA connection. You could also enable one of the free 250 tag historians on the Pro Plus, or operator stations and store the data in two locations (or more) in case you have to reboot a server for maintenance.
  
  Second would be to store the data in the Event Chronicle. A simple query in PHV would retrieve the values that you can export in EXCEL. And setting up a SQL query to read the data would be one way of allowing the enterprise system to come read the data. I did a quick test and create a module that compares the LOT Number parameter, and when it changes, it reads the LOT Number, Weight and Unit, concatenates these together and does a LogEvent command to store this in the Event Database, with commas to create delimited data entry "LOT1, 532.56,UNITA".
  
  OUT1 := LOGEVENT( '^/LOTNUMBER.CV' + "," + '^/WEGHT.CV' + "," + '^/UNIT.CV')
  
  A filtered Event View in PHV would show me this history at a glance.
  
  So maybe a better solution is to capture your LOT data in the Event Chronicle or Continuous Historian, which can be a simple configuration. Now you can focus on how the Enterprise server will get this data.
  
  If by Enterprise server you mean a PI Enterprise Historian, the OSI connector for OPC DA will automatically buffer the data on loss of communications, or can come retrieve the History data in DeltaV.

  Andre Dicaire

  • Cancel
• BillS

  

  • 1 Aug 2018 5:33 PM

  In reply to Andre Dicaire:

  Hello Drew. If you are able to store the data using the previous posts then that is probably the best path forward. However, if that is not preferable and you need to go directly from controllers to enterprise with buffering (in case the communication breaks down), you may want to consider XLReporter. With XLReporter as "middleware", values can be read from the PLC, converted to almost any structure and then passed onto the enterprise (I am assuming this is a database). If communication to the enterprise fails, XLReporter buffers until it is restored.

  • Cancel
• BillS

  

  • 1 Aug 2018 5:34 PM

  In reply to BillS:

  I meant controller (not PLC)

  • Cancel