Technical FAQs

Ask a Question

Where are examples of using the M340/M580 SD File Storage Card in Unity Pro

Goals and Symptoms
Where are examples of using the M340/M580 SD File Storage Card in Unity Pro

Facts and Change
Unity

Causes and Fixes

The File Storage SD Card option available for the MODICON M340/M580 provides users with the ability to create Application Solutions that previously may have required costly external components which reduced system reliability and increased system complexity. The user Application can Create, Open, Delete, Write and Read Files. External access to the files is by FTP (the M340/M580 is an FTP Server) using USB or Ethernet.
 
Examples of applications that can be implemented:
  • Event Logging of Discrete Events (SOE Recording) to a  '.csv' or Tab Delimited '.txt' File Format.  The Files can be Imported into Excel for Analysis.  The SD File Content can also be displayed on a  Magelis Operator Interface or an M340/M580 Custom Web Page.
  • Process Data Logging:
    • In an RTU application this may be at higher resolution than the SCADA Host Trending allowing access to data for a more finite Analysis.
    • With the proper File Format and coding these files can be used to Auto-Back Fill Trend Files in Vijeo Citect or other SCADA.
    • Event Triggered Process State capture for Fault Cause Analysis by Playback techniques in Unity Pro, on a Magelis or in SCADA.
  • Store and Forward Applications:  Product Tracking, Quality Data, Regulatory Data, etc.
  • Recipe Management Solutions
  • Reporting Solutions
Example Architectures that can be implemented:
 
M340 (minimum P342000 CPU) with Locally Accessed FTP Log Files
 
 
M340 (minimum  P342020 CPU) with Remotely Accessed FTP Log Files
 
 
 
M580 (any CPU w/ BMENOC0321) with Remotely Accessed FTP Log Files
 
 
 
General SD File Storage Card Best Practices
1) The application must track the File Names that are on the SD File Storage Card.
One method for this is to use a STRING QUEUE for each Log Group.
2) File names must be unique and a recommendation is to use a naming convention that is derived from the File Logging Period.
e.g.: ID_MMDDHH.csv where ID=Log Group, MM=Month, DD=Day, HH=Hour
3) Files should be opened and remain open for the duration of the chosen Logging Period.
Special care must be taken to deal with Controller Power Cycles within a Logging Period.
4) Avoid FTP Client interaction with the Log Files that are currently Open.
SOAP or Modbus can be used to access the Log File Name QUEUE for FTP Client automation.
5) Data must only be written to the SD File Storage Card 512 Bytes per write (excluding the final write before closing the file).
See the Tip: How to maximize the life of an M340/M580 SD File Storage Card
6) Insure that the code avoids %S15 Errors.
Note: %S15 is not set if the when String Value assignment results in the String being truncated.
7) Consider the inclusion of an optional Header Row when Log Files are created.
8) Calculate (predict) the resulting File Size of all Log Files.
9) Avoid using > 50% of the available SD File Storage Card free memory for Logging Files.
10) The use of Periodic Scan Configuration of the MAST Task will reduce (improve) SD File Storage Card FTP file transfer time.
 
 
 
Sequence of Event (SOE) Recording is usually required in processes that seldom have issues but when issues do arise it is important to be able to research what happened when to aid in determining why.  The retrieval of SOE data for this purpose is infrequent.
 
Then there are systems subjected to continuous improvement programs with SOE being a part of the system performance evaluation, resulting in the SOE Logs being retrieved and analyzed on a regular basis.
 
Depending on the purpose of the SOE, there will be differing needs associated with the duration of SOE collected data files.
 
Generally this type of application records Discrete Events which can include Threshold Crossing or Value Change Events of Analog Data.  Time Stamp resolution of these Events can be millisecond resolution, but to achieve this it may require the inclusion of Time Stamp Modules (BMXERT1604T).  It is recommended to select a time period (duration) for SOE Files (Hourly, Daily, etc.) and include File Management in the application to maintain the required number of Files to cover the SOE needs.
 
Here is an example of what the SOE Log might look like:
 
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.
 
 
 
Was this helpful?
What can we do to improve the information ?