Define a Clear Interface for Custom Homing Component and Integration with Pokeys

[zarfld]

Issue: Define a Clear Interface for Custom Homing Component and Integration with Pokeys

Description:

A clear interface for the custom homing component pokeys_homecomp.comp needs to be defined. This will standardize the communication between the homing procedure and the PoKeys components, ensuring smooth operation in LinuxCNC. The separate HAL file pokeys_homing.hal should be created to define the linkage of pins from pokeys_homecomp.comp to the relevant PoKeys components.

Additionally, the following components must follow this newly defined interface:

• pokeys.comp (userspace component)
• pokeys_rt (realtime component)
• pokeys_py (Python-based userspace)

Tasks:

1. Define pokeys_homecomp.comp Interface:

   • Establish the canonical structure for the custom homing component.
   • Ensure proper pin definitions for homing control, feedback, and status reporting.

2. Create pokeys_homing.hal:

   • Link the pins from pokeys_homecomp.comp to the appropriate PoKeys components.
   • Ensure proper connection to PoKeys digital IO, PEv2 axis homing signals, and feedback signals.

3. Update pokeys.comp (userspace):

   • Modify the userspace component to conform to the new homing interface.
   • Ensure that homing signals and status are handled properly.

4. Update pokeys_rt (realtime):

   • Adjust the realtime component to manage the custom homing interface.
   • Synchronize realtime homing behavior with the defined pokeys_homecomp.comp.

5. Update pokeys_py:

   • Implement the custom homing interface in the Python component.
   • Ensure that the Python script manages the homing signals correctly and adheres to the defined interface.

References:

• pokeys_homecomp.comp
• LinuxCNC HAL Documentation
• PokeysLib
• LinuxCNC Motion

Expected Outcome:

A standardized interface for the custom homing functionality that integrates seamlessly with the PoKeys family of components in LinuxCNC.

Branch Suggestion:

• Branch Name: custom-homing-interface

Issue: Define a Clear Interface for Custom Homing Component and Integration with PoKeys

Task Description

A clear interface for the custom homing component pokeys_homecomp.comp should be defined to integrate homing functionality with the PoKeys hardware. The interface should cover the following areas:

• Homing signal handling
• Pin and parameter definitions following LinuxCNC canonical interfaces
• Integration with userspace (pokeys.comp), real-time (pokeys_rt), and Python (pokeys_py) components.

The pokeys_homing.hal file should link the pins from pokeys_homecomp.comp to the corresponding PoKeys components.

Goals

1. Define a custom homing interface (pokeys_homecomp.comp) that can integrate seamlessly with PoKeys devices.
2. Ensure that pokeys.comp (userspace), pokeys_rt (realtime), and pokeys_py components follow the defined interface for handling homing signals and state.
3. Define the necessary HAL pins and parameters to reflect the homing state, switch inputs, and position feedback, according to the canonical LinuxCNC interface.

Restrictions to Consider

Userspace Components (pokeys.comp)

• Latency Considerations: Userspace components are non-realtime and may introduce delays when handling homing signals.
• Polling vs. Event-Driven: Avoid relying heavily on polling for homing state updates. Prefer event-driven signal handling where applicable.
• Limited Realtime Access: Ensure status updates from homing are synchronized and reflected in userspace without requiring direct access to realtime hardware timers.

Realtime Components (pokeys_rt)

• Strict Realtime Constraints: Homing should be handled with hard real-time constraints to ensure accurate, time-sensitive motor control.
• Interrupt-Driven Behavior: Homing procedures should trigger based on interrupts from home or limit switches.
• Deterministic Behavior: Ensure deterministic behavior in the homing sequence, especially during slow homing steps and position resets.

Python Components (pokeys_py)

• Non-Realtime Nature: Python components cannot manage homing directly due to timing constraints. They should be used for high-level decision-making and monitoring.
• Polling Frequency: Define an appropriate polling frequency to retrieve homing status updates, without relying on real-time execution.
• State Synchronization: Python components should focus on relaying homing status to user interfaces or logging systems but should not control homing sequences directly.

General Interface Requirements

1. Pin and Parameter Definitions: Follow LinuxCNC canonical pin definitions, such as:

   • pokeys.[DevID].digin.[PinID].in
   • pokeys.[DevID].joint.[AxisID].homing
   • pokeys.[DevID].joint.[AxisID].pos-fb
   • pokeys.[DevID].joint.[AxisID].enable

2. Status Pins: Use status pins to reflect homing states:

   • pokeys.[DevID].PEv2.joint.[AxisID].homing
   • pokeys.[DevID].PEv2.joint.[AxisID].in-position

3. Mapping to Homing States: The PoKeys homing status (AxisState) should be mapped to the LinuxCNC joint and axis state pins.

   • PoKeys homing states:

     PK_PEAxisState_axHOMINGSTART  = 11
     PK_PEAxisState_axHOMINGSEARCH = 12
     PK_PEAxisState_axHOMINGBACK   = 13
     PK_PEAxisState_axHOME         = 10

   • Corresponding HAL pins for the above states:

     joint.[N].homing
     joint.[N].pos-fb
     joint.[N].amp-enable-out

4. Error Reporting: Define error handling pins to reflect any homing errors or limit switch trips during the process:

   
   pokeys.[DevID].joint.[AxisID].error
   pokeys.[DevID].joint.[AxisID].homing-error

[zarfld]

pokeys.comp not yet updated