M19 orientation drift with external encoder and orient component (LinuxCNC 2.9.4

Hello,I am trying to configure M19 spindle orientation on LinuxCNC 2.9.4 using the standard orient component.My spindle is driven by an analog servo drive (0–10 V speed command) and direction is selected by a relay (CW/CCW). Because of this hardware, the PID output is converted to an absolute value and the direction is handled separately. The orientation itself works surprisingly well, but I have a strange drift that I cannot explain.Hardware

• LinuxCNC 2.9.4C10 breakout boardParallel portAnalog servo drive (0–10 V speed reference)External incremental encoder (100 PPR, TTL, A/B/Z)Encoder position-scale = 400 (quadrature)

  encoder.0.position

  increases by exactly 1.0 per spindle revolution

HAL architectureThe orientation chain is:

• orient

  pid

  mux2

  PID output →

  abs

  Sign handled separately by logic (

  and2

  ,

  or2

  ,

  not

  ) driving the CW/CCW relay.

The relevant HAL section is attached below.What works

• M3 and M4 work correctly.Rigid tapping (G33.1) works correctly.M19 works mechanically.

The problemBetween different executions of the same G-code program, the spindle zero slowly drifts.1–2 degreesAdditional observationsAfter M19:

• orient.0.is-oriented

  is always FALSE.

  spindle.0.is-oriented

  is also always FALSE.

  orient.0.poserr

  is typically around 73 degrees.

  orient.0.tolerance = 0.5

  Visually, however, the spindle is correctly oriented.

Signal values:

• encoder.0.position = spindle.0.revs = orient.0.position

  Position is in revolutions (1.0 per revolution).

Another observationWhile debugging I discovered something unexpected.With the servo drive powered ON (motor stopped), the external encoder produces random A/B/Z pulses.The encoder is even removed from the motor and rotated by hand.If the servo drive is powered OFF, the encoder signals become perfectly clean.This may be a separate EMC issue, but I do not know whether it could also explain the orientation drift.QuestionHas anyone seen a similar behaviour with thecomponent?In particular:

• should

  orient.0.is-oriented

  become TRUE after a successful M19?is a

  poserr

  of about 73° compatible with a visually correct orientation?could the drifting reference be caused by the encoder/EMC issue, or is there something wrong in my HAL logic?

Any suggestions would be greatly appreciated.I can provide the HAL file if necessary.Thank you.jelost

It does sound like the issue is EMI causing miss-counts.

Software read encoder counters are more susceptible to noise
because they do no have a high enough sampling rate to allow
oversampling/ filtering of the A/B/Z signals. This means  that very
short noise pulses on the inputs can result in a miss-count

Possible fixes:

1. Use differential signaling on the A/B/Z  signals and a differential --> single ended converter
to convert the differential signals to the single ended parallel port signals.

2. Use some RC filtering of the A/B/Z signals at the parallel port end of the wiring.