What are some Best Practices for managing Unity MODICON PAC Active Data

Examples of the types of Data that are most often ‘At Risk Data’ include:

• Regularly Modified Setpoints (PID, Timers, Thresholds, etc.)
• Batching/Recipe Data
• Cumulative Data (e.g.: Motor Runtime, Flow Totalization, etc.)
• Tracking of Product/Process (e.g.: FIFOs, Queues, Thresholds, Transitions, etc.)

Locating this ‘At Risk Data’ (@ %M/%MW) will enable the most effective options for Data Recovery and is the
recommended method.

There are many situations that can lead to the Loss of Data, some are:

• PAC CPU failure and replacement
• PAC FW Upgrade
• PAC Application modification requiring Off-Line Build
• PAC Application Fault (WDT or anything causing HALT and required INIT)
• Accidental Off-Line Build (Changes or Rebuild All)
• Accidental Cold Start (P.S. Reset or via Unity Pro)

There are Project Settings that should be used to limit the user’s ability to perform ‘Accidental’ mistakes:

• General>Project autosaving on download> save STU
  • ‘download’ refers to both On-Line Build Changes and Full Downloads
• General>Build Settings>Virtual Connected Mode
  • This setting disables ‘Build Changes’ when not connected to the PAC

Recovery from PAC Hardware Failures and Applications Faults will be the most challenging. These can happen
at any time and if recovery of Active Data is Critical then it is necessary to engineer Disaster Recovery into the system.

MDT AutoSave with Scheduled Compare and Backups can reduce the impact of Data Loss to the frequency of the Schedule.
The impact on network communications should be evaluated.

Unity Loader can provide a solution. Scripting of Unity Loader commands can be used to periodically create a ‘.DAT’
data file of the PAC Located and Unlocated Data. However, these ‘.DAT’ files can be useless for Unlocated Data if
any type of Build is used before loading of the replacement PAC.

This leaves protecting the Data during the process of PAC Application modifications requiring Off-Line Builds
to be addressed. There is only one method to insure that the Data in the PAC will be the exact Data that was present
in the PAC prior to the required Full Download. This procedure is:

• Having all ‘At Risk Data’ located at %M and %MW addresses
• Having a ‘.STU’ or ‘.STA’ that allows connecting ‘Equal’ to the PAC (or Upload is possible)
• Know that the ‘.BAK’ file created by Unity Pro is one step back from the last On-Line Build Changes or Full Download
• Connecting to the PAC (with above) immediately before Stopping the PAC to download the modified application
• Performing a ‘Save Data from PLC to File’ (using ‘.DAT/.DTX’ File) and Disconnecting
• Connecting with the modified Unity Pro Project and performing the Full Download (no RUN)
• Performing a ‘Restore Data from File to PLC’ (loading the above ‘.DAT/.DTX’ File)
  • Note: DTX file is recommended (requires Unity Pro V6.0 or higher)
• Put the PAC in RUN

This procedure may not restore any or all Unlocated Data to its previous value.

There is also another method and procedure that can help to avoid the Loss of Critical Active Data in a MODICON
PAC. This is an inherent feature of the Unity OS.

• Using the Save Parameter for Data (Variable Data and Public Variable Data of DFBs)
  • Both of these require frequent connection to the PAC with Unity Pro to ‘Update Local Init Values from PLC Init Values’
    • ‘Update Init Values from Current Values’
    • Periodic triggering of %S94
  • Enables Off-Line comparison of ‘.STU’ file Data with a running PAC Data via Unity DIF