S7-1200 MC_Home Mode 3 Position Drift: Flying Saw Troubleshooting

1. Problem Overview

Engineers building a flying saw on a SIMATIC S7-1200 CPU 1212C with a PTO/PWM-controlled or PROFIdrive-coupled servo frequently report a cumulative positional drift that appears only after a few dozen or a few hundred cut cycles. The motion sequence looks like this:

1. MC_MoveVelocity synchronises the saw carriage to the material feed and triggers the cut at the calculated trigger point.
2. After the cut is acknowledged, the application issues MC_Home in Mode 3 (active homing to a reference cam/sensor) with a Position input of 0.0.
3. The drive finds the reference cam, decelerates, sets the actual position to the configured home coordinate, and the PLC drops the homing Execute bit.
4. On the next cycle, the carriage no longer lines up with the reference sensor - the visual "home offset" appears to walk away from the cam over time.

Because Mode 3 physically re-references the axis to a fixed cam, the encoder-derived actual position is force-overwritten to the home coordinate on every cycle. A real world drift of the encoder reading therefore cannot be the root cause. The drift is always caused by one of three logical families:

• The homing job never actually completes (it is aborted or superseded).
• The homing job completes, but a second job overwrites the position before the cut geometry is re-established.
• The application is writing a non-zero Position value, adding a software offset, or mishandling the Execute edge in a way that the documented block behaviour of MC_Home Mode 3 does not match.

2. Reference System Architecture

The architecture assumed in this article is the canonical low-cost S7-1200 flying-saw stack:

The PLC open blocks used in the application are part of the MC library shipped with TIA Portal and are documented in the S7-1200 Motion Control V6 function manual (Siemens Support, 109751049).

3. How MC_Home Mode 3 Actually Works

The behaviour of the S7-1200 axis MC_Home instruction in Mode 3 is defined in the TIA Portal help and in the S7-1200 Motion Control manual. The simplified sequence is:

1. On a rising edge of Execute, the axis accelerates from its current actual velocity to the configured approach velocity and moves in the configured approach direction.
2. When the reference cam is detected, the axis decelerates and (if configured) runs a reducing velocity profile in the opposite direction to find the cam edge with controlled accuracy.
3. Once the cam edge is reached, the axis stops and the actual position is set to the home position coordinate defined in the axis configuration (this is not the Position input on the block - that input is only used in Modes 0 and 1).
4. Output Done is set for one cycle; output Busy falls; CommandAborted or Error is raised on failure.

Three block inputs matter for Mode 3:

4. Symptom: Position Walks After 70 - 250 Cycles

The 70-250 cycle window reported in the original case is a strong fingerprint. The encoder, drive, and mechanical axis are not slowly degrading; the trigger is programmatic:

• After 70-250 successful homing attempts, some internal counter, edge, or memory flag in the application logic flips state. Common candidates:
  • 16-bit wrap of a "cycle counter" used to gate homing.
  • A flip-flop ladder that only re-arms every N cycles (e.g. the user thought they were homing every cycle, but they were homing every other cycle, and the alternate path skipped the cam check).
  • A watch-dog / fault latch that suppresses the homing Execute when the previous cut exceeded a tolerance window.
• The PLC internal task cycle (typically 1 - 10 ms in the OB1 cycle) is missing a homing Execute edge because the input or the request tag is updated faster than the OB is dispatched.
• The drive is in a follow-up state (e.g. SS1, STOP2, or fault) and the PLC issues MC_Home without first re-issuing MC_Power.Enable = TRUE; the job is queued, fails, and a subsequent MC_MoveVelocity starts with the encoder at its last true position.

Hence the visual signature: a flat, repeatable, accurate cut for tens to hundreds of cycles followed by an accumulating offset that grows at exactly the rate of the missed homings.

5. Root Cause Matrix

Use this matrix to map the symptom to the most likely category of fault. The first three rows cover 90 % of S7-1200 flying-saw drift cases seen in the field.

6. Diagnostic Procedure

Follow this sequence in order. Stop the line safely and run the saw in manual jog with TIA Portal online attached to the CPU.

1. Pin the homing tag to a watch table. Add the MC_Home instance DB tags to a watch table: Execute, Busy, Done, CommandAborted, Error, ErrorID, Mode, Position.
2. Single-step 300 cycles. Run the line at slow speed and increment a counter. Every cycle, screenshot or log the homing output states. Look for the first cycle where Done is replaced by CommandAborted=TRUE or Error=TRUE.
3. Capture ErrorID and AbortID. Typical S7-1200 motion error IDs (per the Motion Control V6 manual):
   • 16#8001 – Job aborted by another job.
   • 16#800D – Homing error (cam not found / overrun).
   • 16#8012 – Encoder error / telegram failure.
   • 16#801C – Drive not enabled (MC_Power off).
4. Confirm the cam is seen by the drive. In the drive's parameter list (V90 / S120), monitor r2526.0 (status of homing cam) and the digital input status word. The cam must transition 0→1 during the homing run.
5. Plot actual position vs. cycle number. The plot must be a flat line at the home coordinate (with a single saw-tooth swing during the cut). Any linear slope proves that one of the homing jobs did not reset the position.

7. Step-by-Step Correction

Apply the corrections in the order listed. Each is independent and can be verified before moving to the next.

7.1 Make MC_Home.Execute a one-shot pulse

The classic S7-1200 homing pattern uses a positive edge on Execute and drops it after Done:

// FB "FlyingSawControl"
// Tags
VAR
  bReqHome   : BOOL;          // request from cycle sequencer
  bHomeStart : BOOL;          // one-shot pulse
  bHomeBusy  : BOOL;
  bHomeDone  : BOOL;
  bHomeErr   : BOOL;
  wHomeErrID : WORD;
END_VAR

// Edge generation
bHomeStart := bReqHome AND NOT bHomeBusy;

// Call
"MC_Home_DB"(Execute := bHomeStart,
             Position := 0.0,
             Mode     := 3,
             Busy     => bHomeBusy,
             Done     => bHomeDone,
             Error    => bHomeErr,
             ErrorID  => wHomeErrID);

// Self-reset: drop the request as soon as homing starts
IF bHomeBusy THEN
   bReqHome := FALSE;
END_IF;

7.2 Block other motion commands during homing

If MC_MoveVelocity or MC_MoveAbsolute is called while MC_Home is busy, the homing is aborted. Add a state machine gate:

CASE iState OF
  0: // Idle
     IF bSeq_CutDone AND NOT bHomeBusy THEN
        bReqHome := TRUE;
        iState   := 10;
     END_IF;
  10: // Homing in progress
     IF bHomeDone THEN
        bReqHome := FALSE;
        iState   := 0;       // ready for next cut
     ELSIF bHomeErr THEN
        // fault handling, latched
        bFault := TRUE;
     END_IF;
END_CASE;

7.3 Ensure MC_Power is healthy before homing

Insert a guard so that homing is only allowed when the drive is in "Operation Enabled":

bPowerOK := "MC_Power_DB".Status AND NOT "MC_Power_DB".Error;
bReqHome := bReqHome AND bPowerOK;

7.4 Pin Mode to a constant

Hard-code Mode := 3 at the call site. Do not route it through a DB that other FBs (especially a recipe block) can modify. Add a comment: "Mode 3 = active homing to reference cam; home coordinate from axis TO".

7.5 Verify the cam and digital input

Open the axis technology object in TIA Portal, go to Hardware, and check:

• Selected digital input matches the physical wiring.
• Input filter (in the CPU properties) is < 0.5 ms so the cam edge is sampled reliably at the configured approach velocity.
• Cam is within the axis travel range; Permit auto reverse at hardware limit switch is enabled if the cam is beyond the start position.

7.6 Confirm telegram and scaling on PROFIdrive

For SINAMICS V90 PROFINET, set p0922 = 3 and verify:

Cycle power after a parameter change. The drive will need a new absolute reference; issue an active homing once before resuming production.

8. Verification Tests

Run the following regression before re-qualifying the line for production.

1. 1000-cycle homing test, no cut. Jog the axis to mid-travel, issue MC_Home Mode 3, monitor Done, repeat 1000 times. Pass criterion: Done = TRUE on every cycle, actual position returns to the same value within 1 encoder increment.
2. 1000-cycle cut test, full speed. Run the production cut sequence. Plot the position at the trigger point. Pass criterion: standard deviation of the trigger position < 0.05 mm (or the tolerance required by the cut length).
3. Power-cycle resilience test. Power off the CPU, power back on, run a homing cycle, run a cut. Pass criterion: first cut is on target.
4. Forced abort test. While MC_Home is busy, issue a MC_Stop. Pass criterion: Error = TRUE with ErrorID = 16#8001 (job aborted) and the axis stops without jerk or overshoot.

9. Best Practices for Flying Saw on S7-1200

• Use a synchronous axis (TO_SynchronousAxis) for the saw carriage and a virtual leading axis (TO_ExternalEncoder or a counter-based virtual axis) for the material. The MC_GearIn / MC_CamIn commands handle the synchronization; reserve MC_Home for setup only.
• Home once at power-up, not every cycle. The original post mentions homing after every cut. That is unnecessary wear on the brake and on the reference cam. A clean implementation homes on the first motion enable, then uses MC_MoveAbsolute for the return stroke.
• Use MC_MoveAbsolute to the home coordinate rather than re-homing. The axis can be moved to Home position directly if it is already referenced. This avoids the cam and is faster.
• Watch the MC_Home Execute tag with a rising-edge detector (R_TRIG) in every code path. A held Execute does not re-trigger homing; it just keeps the job queued.
• Keep the homing Position input at 0.0 in Mode 3 for code clarity, but also document in the comment that the value is unused in Mode 3.
• Latch ErrorID in a fault log so that the support engineer can see the history when the next line call comes in at 3 a.m.
• Validate the encoder on every power-up by issuing a slow jog in both directions; if the actual position changes proportionally, the encoder is healthy.

10. Related Axis Parameters and Their Failure Modes

For the canonical S7-1200 motion configuration procedure, see the Siemens S7-1200 Motion Control V6 function manual and the S7-1200 Easy Speed Control application example. For SINAMICS V90 telegram configuration, see the SINAMICS V90 PN Function Manual.

11. FAQ