Separating CiA402 Logic from EtherCAT (lcec): Modular Adapter + Drive Stub Valid

How about if we don't blame the drive for moving by itself during homing,
and instead make "motion" understand that it should follow the position feedback?

I already have a pure SIM validation setup working (HAL adapter + drive stub). The goals there were to make the logic deterministic and debug wiring/handshake issues before touching real EtherCAT hardware. In SIM I’ve validated:

6060/6061 opmode handshake

bit4 start pulse generation

done mask/value detection

stable statusword behavior (no flicker)

basic “homed” behavior (latched)

So the current work is no longer “does it wire up?”, but refining the architecture to match industrial semantics.

@rodw — yes, exactly: your procedure returning 1 at Operation Enabled is the clean gate. I’m using your barebone logic as the base for a dedicated PDS manager layer: until op_enabled == 1, nothing else (homing or motion modes) is allowed to run. Once op-enabled is reached, then we proceed with homing / CSP.

@Hakan — I also really like your point about not blaming the drive for moving during internal homing. That’s actually the main remaining behavior I’m refining now: instead of freezing targets in a hacky way, it seems cleaner to make the controller follow feedback during drive-internal homing.

So while homing is active:

motion/target follows feedback (pos_cmd := pos_fb)

when homing completes, CSP can resume with zero discontinuity (no jump)

Next steps:

implement the separate PDS manager (based on rodw’s barebone + timeouts + fault reset pulse)

implement mode modules (homing/CSP/etc.) gated by op_enabled and 6060/6061 confirmation

once the layers are solid in SIM, re-integrate with lcec + real hardware

If either of you sees a pitfall in the “motion follows feedback during internal homing” approach, I’d love to hear it — but it looks like the cleanest way to avoid discontinuities when returning to CSP.

A new homing method, external_homing. Can box in motion with limits and time.
A variant could be external_synchronized_homing for gantry homing.
With additional limits on start positions maybe and max difference in position.
And so on. Done by motion/motmod. Communicates with pins to the drive component as usual.

Maybe also a new freewheeling mode and pin for motion/motmod.
For opmodes that disconnects the position.
Position is usually right from the drive even when opmode changes.
But you don't need to control the position, just follow it.
I think one need to go over all  opmode switches and see which situations can appear.
 

Hi Hakan,

That’s a very interesting direction.

An external_homing method handled by motion/motmod — with limits, time supervision and synchronized gantry constraints — would definitely be a robust long-term solution. The idea of a freewheeling/follow-feedback mode in motion is also conceptually very clean.

However, changes in motion/motmod are a much larger step. They require core discussion, review and consensus, and can easily turn into a longer-term architectural effort.

Right now my plan is to stay focused on the original scope of this thread:

• ]Finalize a clean modular CiA402 stack (PDS manager + opmode modules + drive-agnostic app layer)
  • Validate everything in SIM
    • Then test and stabilize it on real hardware
      
      My short-term goal is to get it to the point where it becomes “boringly stable” on at least one real drive. Once that is achieved, I think it makes much more sense to revisit motion-level enhancements like external_homing or a freewheeling mode.
      
      Otherwise we risk expanding the scope too early and spending a lot of time discussing architecture before finishing the current layer separation.
      
      If we decide to explore motion-level changes seriously, I think it would be better to open a dedicated thread for that topic, since it would likely require deeper discussion and take some time.
      
      For now, I’d prefer to close the CiA402 separation work first and build from there.
      
      — Marcos

Hi,

Now that we won't be getting any support from the German PLC forum, I did some searching myself and found this interesting project. In my opinion, it could serve as a good template, as all the code I've seen so far uses a similar topology.

I would also like to emphasize that there is no need to reinvent the whole concept. We already have functioning components (CIA402; homecomp.comp) that form a good basis. Many thanks to @rodw and @MobiusToast for their excellent pioneering work. What is missing now is the further development of these components.
I fear that even this thread, with its good approach, will ultimately be forgotten.

For my part, I will take a different path.
Since I continue to have homing problems and have now ruled out EMC and configuration errors, I think the problem lies with the A6 itself. Yesterday, it took 3 minutes for the x-axis to start the reference run! 
I will now try to expand my system to include battery-buffered encoders.
At least according to the documentation, this should be possible. This would make homing obsolete.

 

I want to clarify something.

My goal in this thread was never to “reinvent everything”.
It was to separate CiA402 logic from EtherCAT transport and validate it deterministically in SIM before going back to real hardware.

Rodw already showed the essential backbone:

• A proper PDS state machine gate
• Only allow homing/motion after Operation Enabled
• Explicit opmode request (6060) and confirmation (6061)
• Controlled homing start sequence

That is exactly what I am implementing — but modularized and testable without depending on a specific drive.

If someone believes this “will lead nowhere”, that is fine — but then please explain technically why isolating CiA402 logic, adding deterministic state transitions, mask/value evaluation, timeouts, and SIM validation would be a wrong direction.

Negative predictions without technical arguments do not help anyone.

Also, individual hardware purchasing decisions (A6 or anything else) are unrelated to the architectural question being discussed here.

The objective is not to fix one specific drive problem.
The objective is to build a clean CiA402 logic layer that can be validated independently and reused.

If anyone has constructive input (state diagrams, PLCopen-style Execute/Busy/Done patterns, hardware traces, mask definitions, timing constraints), that would be very welcome.

Otherwise, I will continue implementing the modular adapter + PDS manager approach and share results for review.