Technical questions about CIA402 and homecomp.comp on A6

  • andrax
  • andrax's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
More
14 Feb 2026 10:01 #342930 by andrax
@rodw Yes, I would have implemented it in the same way in a PLC. The only thing missing is the safety timer from start homing to axis in motion. Then the homing would be practically monitored. Regarding the axis jumping, you could set the feed rates to minimum after completion until Linuxcnc has synchronized.

@Hakan, aren't the csp csv and pv modes managed by the driver? I believe that torque mode is not supported by the A6 during homing. However, it would be an option if you let Linuxcnc manage homing again. Since the Z pulse is not output by the A6, you could perform the torque search. 

 
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
15 Feb 2026 04:11 #342980 by rodw

rodw, I kind of think of a structure like this
if drive ready
  if csp

  else if csv

  else if pv
...
  else if probing

  else if homing
     if homing_method == 1
     else if homing_method == 2
     else if homing_method == 37
        Do the torque homing. Although it doesn't seem to be standard
     

Keep track of what op-mode we were in last time so we recognize a transition
between op-modes. To deal with offsets and such things.

Great feedback I wasn't really happy with what came after the state machine but I've had to put this project down for a week or so and you forget everything when its so complex. 

Please Log in or Create an account to join the conversation.

More
15 Feb 2026 04:23 #342982 by rodw

@rodw Yes, I would have implemented it in the same way in a PLC. The only thing missing is the safety timer from start homing to axis in motion. Then the homing would be practically monitored. Regarding the axis jumping, you could set the feed rates to minimum after completion until Linuxcnc has synchronized.
 

Can you explain this timer? I would have thought you get the homing signal from linuxcnc, pass it on to the drive then  loop until bit 12 goes true keeping lcnc in sync.. I can't remember off the top of my head how we check that the homing request has actually stuck but I seem to remember we could do this too before doing the loop. Bit 13 will tell us if there is an error during homing.

Please Log in or Create an account to join the conversation.

More
15 Feb 2026 05:10 #342983 by Marcos DC
While waiting for Andrax’s view, IMHO for a generic CiA402 setup there’s no standard “homing started” bit, so I’d supervise it with two simple triggers/timers.

I’d start the overall homing timeout when the drive actually confirms Homing mode (6061 == 6). Then, when we assert the homing start (opmode-specific, e.g. the bit-4 flip after 6061 confirms), I’d start a short “start→motion” watchdog and look for real motion as proof (e.g. |6064 - pos0| > eps, or 606C > threshold).
The following user(s) said Thank You: andrax

Please Log in or Create an account to join the conversation.

More
15 Feb 2026 07:15 #342987 by Hakan
When homing 2X axis, get the position and watch to keep axises difference small.
Position disconnected from joints when doing this.

Please Log in or Create an account to join the conversation.

More
15 Feb 2026 08:54 #342988 by Marcos DC
For tandem gantry (X/X2) with squaring, I think we need the usual per-axis homing supervision (start→motion watchdog + overall timeout) and a gantry delta monitor using 6064 feedback (abort if |Xfb−X2fb| grows beyond a reasonable limit during homing, and check final delta tolerance once both bit12 are true). While internal homing runs we keep pos_cmd slaved to pos_fb for both axes.
The following user(s) said Thank You: andrax

Please Log in or Create an account to join the conversation.

  • andrax
  • andrax's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
More
15 Feb 2026 09:45 #342992 by andrax
So, I see two ways to monitor the reference run.
I can only describe it using SCL Logic.
If I have understood the documentation correctly...
in principle as follows:

case homing_status of
0:
     0x6098 := (-2 to 35);
     0x6099-01 := 13981013 or default from .ini;
     0x9099-02 := 1398101 or default from .ini;
     0x609A := 131072 or default from .ini,
     0x6040 > Bit 4 :=1; // start homing with rising edge
     homing_status :=  10:  // next step

10: // 1st safety monitoring 0x6041>Bit 9=1 Homing started
      // 0x6041>Bit9=0 start timer

     IF  (0x6041>Bit9=0) THEN  
           TON(IN := TRUE, PT:= T#1s); // example 1 second
           Error_Bool:= TON.Q; // time expired error is set
    ELSE
          TON(IN:=FALSE) //timer break
          homing_status:= 20
          END_IF

20: // 2nd safety monitoring Speed comparison
     IF target speed <> current speed THEN
            TON(IN := TRUE, PT:= T#1s); // example 1 second
            Error_Bool:= TON.Q; // Time expired error is set
     ELSE
           TON(IN:=FALSE) //Timer break
           homing_status:= 30
     END_IF

30://wait for homing to finish 

IF (0x6041>Bit15=1) THEN
     //prevents the axes from jumping and gives linuxcnc the opportunity for synchronization
    set halui.axis.n.jog-speed 0.06
    homing_status :=0
END_IF
 

Please Log in or Create an account to join the conversation.

More
15 Feb 2026 10:35 #342995 by rodw
I always worried about joint axis homing but I think now it can be done in the drive with homing offset 0x607c which is really the same as our HOME_OFFSET. This probably would need to include  an indrive position adjustment for the last joint that makes it home to square the gantry. I need to think through the application of this as its just at the idea stage now.
I really appreciate the input here about the state machine. Homing sounds simple until you go to do it!

I think the homing bits I mention are often described as mode specific or some such garbage, but it is part of the cia402 homing standard that is not well desribed by many manufacturers.
The following user(s) said Thank You: andrax

Please Log in or Create an account to join the conversation.

More
15 Feb 2026 14:12 #343003 by Marcos DC
Good point about the homing bits being mode-specific / poorly documented. I initially mentioned bit12 as an example, assuming we’re aiming for a generic solution, but that’s clearly not something we can rely on.

I think the right approach is to keep the core logic generic (state machine + timeouts + progress watchdog), and make the actual homing status (done/active/error) configurable per drive, e.g. via masks on 0x6041.

While internal homing runs, keeping pos_cmd slaved to pos_fb still seems necessary to avoid the jump when control is handed back.

With that, A6 becomes just one mapping, not a special case baked into the algorithm.
The following user(s) said Thank You: andrax

Please Log in or Create an account to join the conversation.

  • andrax
  • andrax's Avatar Topic Author
  • Offline
  • Elite Member
  • Elite Member
More
15 Feb 2026 16:51 #343010 by andrax
I have an idea.
rodw: Can you make the bits from 0x6041 available as pins?
Then we can observe the bits during the home run.
If we know which bit is set when, the state machine could be set up accordingly.
But maybe we're overcomplicating things.
I took a look this afternoon and looked at various CIA drives. 0x6040 and 0x6041 are standardized. All CIA402-compatible drives use the same bits. 
See here:
Bosh Rexroth CIA Status word

That means all we really need to do is find a suitable SCL code from Beckhoff or Siemens and rewrite it for Linuxcnc. For example, this one:
VAR
    // PDO mapping inputs (from the drive)
    wStatusword : WORD; // 0x6041
    iActualMode : SINT; // 0x6060
    
    // PDO mapping outputs (to the PLC)
    wControlword : WORD; // 0x6040
    iModeOfOp    : SINT; // 0x6060
    
    // Control / Monitoring
    bStartHoming : BOOL;    // Trigger
    bHomingActive: BOOL;    // Status
    bHomed       : BOOL;    // Target reached
    bError       : BOOL;    // Monitoring: Error
    iState       : INT := 0; // Step chain
    
    // Monitoring: Timer
    fbTimeout : TON;
END_VAR

// --- Read status bits from status word (0x6041) ---
// Bit 12: Homing process running / successful (depending on method)
// Bit 13: Homing error
// Bit 10: Target reached (often used during homing)
bHomingActive := (wStatusword.12); // Homing operation in progress
bHomed        := (wStatusword.12) AND (wStatusword.10); 
bError        := (wStatusword.13); // Homing error

// --- Monitoring (timeout) ---
fbTimeout(IN := bHomingActive AND NOT bHomed, PT := T#10S);

// --- State machine for homing (CiA 402) ---
CASE iState OF
    0: // Wait for start
        IF bStartHoming AND NOT bError THEN
            bStartHoming := FALSE;
            iState := 10;
        END_IF;
 10: // Set mode of operation to “Homing” (6)
        iModeOfOp := 6;
        IF iActualMode = 6 THEN
            iState := 20;
        END_IF;

    20: // Set drive to “Operation Enabled” (standard CiA402 state machine)
        // Simple example: Set control word to 0x0F (Enable)
        wControlword := 16#000F;
        IF (wStatusword AND 16#006F) = 16#0027 THEN // Ready to operate
            iState := 30;
        END_IF;

    30: // Start homing: Set bit 4 in control word (start homing procedure)
        wControlword := 16#001F; // Bit 4 high, enable op
        IF bHomingActive THEN
            iState := 40;
        END_IF;
        IF fbTimeout.Q OR bError THEN iState := 999; END_IF; // Monitoring

    40: // Wait for completion
        IF bHomed THEN
            wControlword := 16#000F; // Reset homing start bit
            iState := 0;
        END_IF;
        IF fbTimeout.Q OR bError THEN iState := 999; END_IF; // Monitoring

    999: // Error state
        // Error handling: Cancel homing, set message
        wControlword := 16#000F; // Stop
        bError := TRUE;
        IF NOT bStartHoming THEN iState := 0; bError := FALSE; END_IF;
END_CASE;
 

Please Log in or Create an account to join the conversation.

Time to create page: 0.110 seconds
Powered by Kunena Forum