Resolving P1-622 Scheduled Logging After Suite 4.7 Update

P1-622 scheduled data logging at one-minute intervals can fail after moving the project to Productivity Suite 4.7.0.47. The scheduled-trigger fault has been reproduced and submitted for development investigation. Event-based logging restores data collection while keeping the same nominal interval.

Skip the usual quick fixes

Treat this symptom as a trigger-path problem before disturbing storage or rewriting working file logic. These common first moves do not address the reproduced scheduled-logging regression:

Preserve the current card and project before making changes. Get logging running through the known event-based workaround, then investigate media or path issues only if independent tests point there.

Separate the trigger from the data writer

A logger has two distinct jobs: decide when to capture and write the selected values to storage. Scheduled logging supplies the first decision from a time schedule. Event-based logging supplies it from a Boolean transition or comparable project event.

The decisive observation is that event-based data logging works on the same P1-622 where one-minute scheduled logging fails. That isolates the problem to the scheduled execution path rather than proving a general failure of the log definition, selected values, or storage destination. The confirmed root-cause class is a software regression associated with Productivity Suite 4.7.0.47; the internal defect remains under development investigation.

The email attachment failure is another post-update symptom, but it does not prove a shared internal cause. Track it separately under its exact message, File attachment error, while retaining the version and project revision information that ties both symptoms to the update.

Prove the failure before changing hardware

1. Record the controller model as P1-622 and the engineering software version as Productivity Suite 4.7.0.47.
2. Save the project revision and preserve the existing SD-card contents. Do not reformat the card during diagnosis.
3. Confirm that the failing logger is configured for scheduled operation at a one-minute interval. Check its enable conditions and data selections for accidental edits.
4. Observe the expected logging window long enough to cover multiple scheduled intervals. Record whether new entries appear and compare their timestamps with the controller clock.
5. Run the same log definition from an event trigger. If records appear when the event executes, leave the data fields and destination unchanged; the trigger selection is the useful discriminator.
6. For the attachment symptom, inspect the SD-card directory and compare the actual file name and path with the email configuration. If both match and the exact error remains, stop rewriting the path and document it as a second regression symptom.

If neither scheduled nor event-based logging writes data, move back to normal storage diagnostics: card recognition, available capacity, file accessibility, logger enable conditions, and runtime diagnostics. That is a different failure branch from the reproduced scheduled-only fault.

Replace the schedule with an event trigger

Use event-based logging as the production workaround. For a cadence equivalent to one minute, derive the event from a periodic timer or the existing plant timing logic. Keep the timer and trigger names consistent with the project naming convention; no specific identifiers are required by the workaround.

1. Duplicate or back up the working project before editing the logger.
2. Retain the same logged values and storage destination.
3. Create or select a periodic event with a nominal period of , derived directly from the original one-minute requirement.
4. Generate one clean event per interval. Use a transition or one-shot form so a true condition held across several scans does not request repeated records.
5. Assign that event to the data logger and disable the failing scheduled trigger to prevent duplicate records if scheduled execution resumes unexpectedly.
6. Download the controlled revision and place the CPU back in its required operating state using the site change procedure.

A cyclic timer measures elapsed execution time; a clock schedule may target wall-clock boundaries. If records must land exactly on minute boundaries, measure timestamp alignment after the change. Do not claim identical timing semantics merely because both configurations use .

Verify the workaround under production conditions

Prove both record creation and record quality. A logger that creates a file but misses triggers is not restored.

Verify across more than a single trigger. Review the timestamps after the system has operated through several cycles, then confirm that downstream reporting or collection software accepts the resulting records.

Control the workaround and preserve diagnostics

Mark event-based logging as a temporary controlled change tied to Productivity Suite 4.7.0.47. Retain the original scheduled configuration, the modified project, failure timestamps, logger settings, and a sample showing successful event-triggered records. This gives official support enough detail to distinguish the known schedule failure from media, project, or timing problems.

Track File attachment error separately. Include the verified SD-card file location, configured path, time of the failed send, and whether email without an attachment still operates. Do not combine both symptoms into one repair unless product diagnostics or official support identifies a common defect.

When a corrected release becomes available, test scheduled logging offline or during a controlled window before removing the event trigger. Run only one trigger method during the acceptance test unless duplicate records are intentionally part of the test plan.

FAQ