After the fix, each fault investigation starts with two timestamped runtime snapshots that can be compared offline. Productivity Suite project comparison does not provide that record: capture the values while the controller or simulator is available, then store them separately from the project.
Stop using project compare as a state recorder
The usual quick fix is to save another copy of the project after the fault and run Productivity Suite Compare. That compares project content, not the changing runtime values needed to reconstruct machine state. A second project file therefore does not answer which permissive dropped, which sequence step was active, or which counter changed.
Data View addresses the live inspection part of the job, but it is not an offline value store. Values are available there while connected to a PLC or using the simulator; the saved offline project does not expose a corresponding value set for later comparison. Reopening the project after leaving the machine cannot recover the earlier state.
| Quick fix | Why it fails | Use instead |
|---|---|---|
| Save another project copy | The project does not become a runtime snapshot. | Save values in a separate, timestamped record. |
| Run Productivity Suite Compare | It identifies project changes, not machine-state changes. | Compare two records containing the same tags in the same order. |
| Leave values visible in Data View | The inspection context ends when the online or simulator session ends. | Record the displayed state before disconnecting. |
| Open two empty text files in a diff tool | A comparison utility cannot acquire PLC data. | Capture the data first, then compare the files. |
Check: Save and reopen a test project offline. If the required live values are not available for review, treat the project and the runtime snapshot as two separate maintenance records.
Define the snapshot before the next stoppage
Do not wait for the intermittent fault to decide what to collect. Build a focused Data View around the logic that controls the failed action. Include the sequence state, command, permissives, interlocks, mode, fault status, relevant inputs and outputs, timers, counters, recipe or product selection, and operator requests. Add raw and processed values where scaling or limit logic can hide the cause.
Keep tag order fixed. Offline comparison becomes noisy when two captures contain different tags or different ordering. Use one row per tag with fields for tag name, displayed value, capture time, machine condition, controller identity, and project revision. Record the revision because a value difference has little meaning if the logic also changed between captures.
Limit the list to signals that establish cause and effect. A huge unsorted dump makes the first changed permissive harder to find and increases the chance of capturing values at different moments. Create separate views for sequence control, safety-related status, motion or process conditions, and production settings when one screen cannot be recorded coherently.
Check: From the prepared list, trace every condition that can block the failed command. Add any missing upstream condition before moving on.
Capture the state while it still exists
Connect before resetting faults, changing modes, forcing values, or restarting the sequence. Those actions alter the evidence. If production must restart immediately, capture the minimum fault-state view first, then reset. Get it running, then fix it properly.
- Confirm the active project revision and controller being observed.
- Open the prepared Data View and verify that values are updating.
- Record the machine condition and capture time.
- Capture the complete displayed value set using the site-approved method, such as a screenshot or a manually maintained worksheet.
- Record a second snapshot after recovery with the same tags and ordering.
- Store both records beside the matching project revision, not only on the programming computer.
A manually captured Data View is a point-in-time observation, not an atomic read of every PLC value. Signals may change while the screen refreshes or while multiple screens are recorded. For fast or one-scan events, add diagnostic logic that latches the initiating conditions or copies selected values into a dedicated snapshot area when the fault occurs. Commission that logic during planned work; adding untested diagnostics during a breakdown can change memory usage, scan behavior, or the very sequence under investigation.
If an installed HMI or SCADA system already records the required tags, alarm history and trends may supply the missing pre-fault sequence. Verify its timestamp alignment and logging interval before relying on it.
Check: Disconnect from the PLC and confirm that both snapshots remain readable without Productivity Suite being online.
Normalize the records for offline comparison
Use a stable plain-text layout when character-level comparison is needed. One line per tag works well:
capture_time | machine_condition | tag_name | displayed_value
Do not silently change units, numeric formatting, tag aliases, or row order between captures. A difference tool will report formatting changes as readily as process changes. Record strings with their full displayed content, preserve leading signs and decimal places, and label any value that was transcribed rather than copied.
WinMerge can compare two text files, highlight changed lines and individual characters, and compare folders or subfolders. It is useful only after the values have been placed in files; it does not read Productivity Suite tag values or turn a project comparison into a runtime comparison. Notepad++ can also support manual text review, but the acquisition limitation remains the same.
Check: Compare a file against an exact copy. The result should show no differences. Change one test value and confirm that the tool highlights only that row and value.
Read differences in control order
Start with the earliest condition in the command path, not the output that failed to energize. A de-energized output is often the consequence. Review the snapshots in this order: operating mode, sequence state, requested command, permissives, interlocks, fault bits, input feedback, timer or counter state, and output command.
| Observed difference | Likely diagnostic direction | Next check |
|---|---|---|
| Mode or sequence state changed | The controller followed another branch. | Trace the transition conditions into that state. |
| Command present, permissive absent | An upstream condition blocked the action. | Trace the missing permissive to its raw input or calculated condition. |
| Command absent despite permissives | Sequence logic, operator request, or fault handling withheld it. | Inspect the rung or block that creates the command. |
| Output command present, feedback absent | The problem lies beyond command generation or in the feedback path. | Check module status, field circuit, device state, and feedback input. |
| Only timer or counter values differ | Timing or accumulated sequence history changed the branch. | Review enabling conditions and reset logic. |
Do not merge snapshot values back into the control project as if they were logic edits. Runtime state can contain transient commands, stale fault latches, and machine-position-dependent data. Use the comparison to locate the controlling condition, then correct the sensor, wiring, sequence, configuration, or operating procedure that created it.
Check: Identify one changed upstream condition that explains the downstream symptom and prove the relationship online without forcing control values.
Verify the complete capture-and-compare path
- Place the machine in a known, permitted test condition.
- Capture the prepared tag set as the baseline.
- Cause one approved, observable state change without bypassing protective functions.
- Capture the same tag set again.
- Disconnect and compare both records offline.
- Confirm that the expected command path, state, or permissive change appears and unrelated rows remain stable.
- Reopen the stored records from their maintenance location and verify that the project revision and controller identity are present.
If the failure changes faster than Data View can preserve it, stop relying on manual capture. Commission a latched fault snapshot, an event buffer, or existing HMI/SCADA logging appropriate to the process, then test its trigger and reset behavior before production depends on it.
Check: A technician who was not present for the test must be able to open the two records offline, find the changed condition, and associate both records with the correct project revision.
FAQ
Why does Productivity Suite Compare not show changed tag values?
Compare evaluates project content rather than recording live controller state. Capture Data View values while online or in the simulator and store them in a separate timestamped record.
Why does Data View lose the values I need offline?
Data View presents values in an online PLC or simulator context; the offline project does not provide a saved value set for later visual comparison. Record the displayed values before disconnecting or resetting the machine.
When should I stop and contact AutomationDirect support?
Stop when Data View does not update reliably, the project and controller identity cannot be reconciled, or diagnostic changes could affect protected or production-critical operation. Preserve the project revision, controller details, screenshots, and exact reproduction sequence, then escalate through AutomationDirect's official support channel.