Ethercat - newbie guidelines

found the error:

your change to the cia comp does not realy work....

you have to think in rt / plc programming.

-first you last switch case does never get action, because you are clearing home in the step before, but the whole switch statement is only executed if home is true...

- pos_fb = pos cmd does not work at this place . you have put it in the write function , this function is executed at thread end. at the next thread start pos_fb is readed again.

related to that motion , pids, etc. is placed between the read and write function, motion never gets noticed of your overwritten pos_fb. you have to place this in the cia read funciton.

if (stat_homing [or an flag you set in your switch]) {
pos_fb = pos_cmd;
}

Note:
If you start halscope after lcnc start and did it not hardcoded in the hal. Halscope is placed at the end of the threat cycle. So halscope did read your pos_fb, but it is not the same value motion has seen....

Thanks, I get what you are saying so I'll revise the code when I have some time.

I did make some changes to homing.c but have not fully tested it. The intent was to not have any moves while homing  if HOME_EXTERNAL=TRUE for the joint.
My commit to my test repo branch shows what I changed
github.com/rodw-au/linuxcnc/commit/0ae7b...03860c47a2526bf6e46b

OK, that works! Thanks so much for catching my silly mistake. I've never had to worry about the order of things before in components I've written.

What I ended up with
 

I need to check it against a standard version of homing.c But I'm sure it will work!

Actually, its not right yet. It needs some logic to manage if the sensor is enabled when homing is requested. It does not like that at all. Another day!.

I think we can check if the home switch is enabled in 0x60FD and set my homing_mode to HOME_CONFIRM if the home input is true when homing is requested

I think also we need a pin to unhome the drives as they can be left in a unexpected state sometimes.

Anyway, its looking good.
 

okay, but these cases have to be caught by the drive. Maybe the drive config is not right, yet.

-the home sensor is only connected to the drive?

at the moment the drives gets an rising edge of the home bit after the opmode is changed the drive should:
-clear the is_homed bit (unhome)
-start its home procedure and set the is_homing bit
in the case the home_switch is enabled while starting homing, the drive adds an step to leave the sensor first or skips the search step.
-after finishing its internal procedure, the drive clears is_homing and set the homed bit (this is noticed by the cia comp and triggers lcnc)

this is the normal behaviour of an home function and all drives that i know are working like that...

Yeh, I had a bit of a play this morning before work and did not have much luck.
I added an input for the home switch which is fed by an output from lcec.
Take homing method 19
 
When the home switch (attached only to the drive) is activated per the top diagram, the drive halts movement. It should halt and reverse to find the edge which its not doing. Deactivate the switch and the move to position finishes (applying offset set in the drive).

I did get it to force lcnc homing but the drive was not in correct state. I will try your ideas.

Somehow I think linuxcnc still has its finger in the pie and possibly overriding our desired behaviour.