FC402 UTC_TO_LTIME: Resolving Shifted DATE_TIME Output

David Krause2 min read
S7-300SiemensTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

A two-byte-shifted local DATE_TIME from OSCAT FC402 was traced to missing OSCAT dependency blocks, not to the configured DB offsets. STEP 7 reported no PLC error, but the block-consistency check exposed the incomplete library installation. Adding the missing blocks restored correct UTC-to-local-time conversion and date extraction.

Observed FC402 conversion problem

SFC1 (READ_CLK) reads the CPU system time and passes it to FC402 (UTC_TO_LTIME). The application stores the system time beginning at DB1.DBB0 and the converted local time beginning at byte 8. The local DATE_TIME appeared shifted by two bytes, so the downstream FC6 (DT_TO_DATE) returned an incorrect date.

Signal Block or location Observed result
CPU system time SFC1 to DB1.DBB0 UTC/system-time value was stored
Local time FC402 to DB byte 8 DATE_TIME appeared two bytes late
Extracted date FC6 Incorrect because its input time was misaligned

Confirmed root cause

The STEP 7 project did not contain all blocks required from the OSCAT library. The CPU had not shown an error before the check, so the absence of a reported PLC fault did not prove that the library was complete. Checking block consistency identified the missing blocks.

The evidence does not identify the individual missing block numbers. Import the dependencies reported by the consistency check instead of guessing block identifiers or changing DB addresses to compensate for the apparent shift.

Resolution and verification procedure

  1. Run the STEP 7 block-consistency check for the project containing SFC1, FC402, and FC6.
  2. Identify the OSCAT blocks reported as missing and add them from the same library used for FC402.
  3. Restore a consistent project and test the conversion chain again on the CPU.
  4. Monitor the DATE_TIME beginning at DB byte 8. Confirm that it is no longer displaced by two bytes, then verify that FC6 returns the correct date.

This procedure resolved the reported installation using STEP 7 V5.5 SP2 and a CPU317F-2 PN/DP. The evidence does not establish that the behavior affects every project using those products; it confirms the fault and correction for this configuration.

FAQ

Why is FC402 UTC_TO_LTIME output shifted by two bytes?

In the reported project, the OSCAT library installation was incomplete. A STEP 7 block-consistency check found missing blocks, and adding them removed the two-byte displacement.

Can missing OSCAT blocks exist without a PLC error?

Yes. The CPU in this case showed no prior error even though required OSCAT blocks were absent. Use the STEP 7 block-consistency check rather than relying only on CPU diagnostics.

How do I verify the FC402 repair?

Monitor the local DATE_TIME stored from DB byte 8 and confirm that it is no longer shifted by two bytes. Then verify that FC6 produces the correct date from that value.

Back to blog