There can be many different reasons for wanting to Log Process Data.  The reasons will determine why and when the logged data will be retrieved for analysis.  

Logging Process Data to a '.csv' or a Delimited '.txt' file requires the data that is logged to be converted from the data's native format in Unity Pro (like a REAL) to Character Strings.

There are two primary guidelines that should be followed for successful implementation:

1)	Record size should be minimized by:  Limiting Field Size to the minimum number of characters required to contain the data
2)	Appropriate Time Periods must be chosen for Logging Files to insure that the number of files maintained will fit onto the SD Card

Examples of these guidelines applied:
    Limiting (Minimizing) Field Size

The Logged data will have absolute minimum and maximum values.   For example:  If a System Pressure Value is to be logged it will be limited by the minimum and maximum values of the Pressure Transmitter calibration. For this example consider:  0 to 100 PSI If the Scaling of this Pressure Value in the M340/M580 is done into a REAL, then the resulting REAL Value in the Unity Pro Variable might be something like +1.6833982e+01. This is an undesirable data format and should be refined to values in the range of 0.0 to 100.0 (where there is a fixed number of whole number and decimal places included in the Character String representation of the Value).  So in this case the Field that will contain the Flow Value will be fixed to 5 Characters ('  0.0' to '100.0').  This implies that six characters are required by this Field, the five needed for the Flow Value plus one for the Delimiter (e.g.: a comma).  This approach should also be applied to INT values (also UINT, DINT and UDINT), and only the required number characters for a value should be used in the String Field.

    Log File Time Period

Log Files must have a defined Time Period. Chose the appropriate period (like: Hourly, Daily, Weekly, Monthly) that will result in File Sizes that allow the overall duration of historical access that is desired and considering the intended File/Data Collection Frequency. For example: If Log Files will be manually retrieved on a Daily Basis (five days a week), then consider creating Daily Files and and possibly maintaining 7 Daily Files.

Here is an example of what Process Data Logging content (using 5 minute Sampling) might look like:

In this example, the content of a Record in the File will be: 01/01/1990,12:00:00, 55.7, 47.3, 60.3$L The space between the commas and the three numeric values is because the value can be 'xxx.x'. The '$L' at the end will force a new line in the Log File.

Here is a diagram of the Process Data Logging procedure:

Systems that Push data to a Historical Database can require Store and Forward functionality to insure zero loss of data occurring as a result of communications issues.

In this system: Failure of the Critical Data Link can result in a loss of Critical Data unless procedures are in place to Store and Forward the Critical Data in the Process Control System. If Process Control System Failure will result in extremely high costs associated with downtime and Critical Data Recovery time, consider Hot Standby Controllers to avoid these costs.

In this example: The Critical Data is Pushed (Data Event Triggered) to the Historian and on a loss of the Critical Data Link, the Store and Forward procedures are initiated in the Process Control System.

When a loss of the Critical Data Link is detected, the Store and Forward procedures must enter the Store mode, Buffering the Critical Data while managing an Active Data Buffer and a Recovery Data Buffer. These Buffers have fixed sizes that are governed by the frequency of new Critical Data, the size of the Critical Data and the duration of Store and Forward capability required before it becomes necessary to either: accept the Loss of Critical Data or Shutdown the Process to avoid operation without Critical Data recording.

When the loss of the Critical Data Link is corrected (for the appropriate amount of time), the Store and Forward procedures must enter the Forward mode and begin to Push the Recovery Data Buffer until the Buffers are emptied.

Minimizing the size of the SD File Storage Card File for Store and Forward applications is accomplished by writing HEX formatted String Records to the Log Files. To demonstrate this consider the following example.

A Unity Pro DDT is created containing the required information for a Package to be tracked. A Variable has been created using the Datatype of the DDT and Located at a %MW Address. Under normal operational conditions, this variable's content will also be contained in the EMIS Variable for the Active Data WRITE_VAR that pushes data to the Historian.

Following loss of the Critical Data Link and the Store and Forward procedure reaching the point where writing to the SD File Storage Card is required, then the record written (based on this example) will contain: 313033323534373639384241444346450000410800004130C28F40151EB840D5$L

Here is a diagram of the general Store and Forward Data Logging procedure:

It is not unusual to find 10, 20, even 30-year-old PLC based Process Control Systems executing Batch/Recipe procedures independent of connectivity to a Supervisory Batch/Recipe Management System. These systems are likely to have the Recipe Definitions maintained in the Controller Memory (State RAM). Systems like this generally have limitations related to the expansion of the number of Ingredients and/or the number of Recipes. When a System like this is modernized, these limitations can be easily removed by relocating the Recipe Storage from Controller Memory to the SD File Storage Card. This will also result in an improved environment for external management of the Recipe Definitions.

Recipe Files should be Delimited ('.csv' or '.txt) and can be transferred to the SD File Storage Card using standard FTP tools. Automation of an FTP Client can be by simple Batch File Execution.

This presentation of a possible Recipe Management Solution will use the ISA-S88 Physical Model as the underlying framework and will assume that the Recipe Management is implemented in the Area Level for execution at the Process Cell or Unit Level.

In this system, the independence at the Unit Level to execute Batch/Recipe procedures may be a requirement and/or greatly desired functionality. Maintaining this capability might be a requirement when modernizing the system to address product obsolescence or to the previously referenced limitations. It may also be desirable to minimize the costs associated with improving the system. To this end, here is a possible modernization approach that achieves all of these requirements.

The independent execution of Batch/Recipe procedures at the Unit Level is maintained. The ability to expand Recipes and Ingredients is achieved. Downtime for system modernization is minimized by the use of Wiring Adapters (eliminating wiring changes/disconnection) and automated Software Migration Tools (guaranteeing post-modernization functionality = pre-modernization functionality) .

The above possible Recipe Management Solution for an existing system includes use of the SD File Storage Card that can also be incorporated into new applications. All Recipe execution solutions that utilize the SD File Storage Card will involve indexing into the '.csv' file to access the appropriate Recipe Record, reading that record and parsing the content into a Structured Variable for Recipe Execution. With new systems based on ISA-S88, the use of SFC Unity Pro Sections is recommended for the Recipe Execution.

With the SD File Storage Card and the supporting Unity Pro Elementary Functions it is possible to create Reports in the M340/M580 that contain the required Static and Dynamic Content of any report. One possible solution for Report Generation is to have an Array of Strings that contain the Static Content and Substitution Markers for the Dynamic Content. In this case the Unity Pro String Elementary Functions provide the ability to Find/Replace the Substitution Markers with the required Dynamic Content.