Help Needed: Cracking the Code on LinuxCNC Servo Homing Setup!

Yeah I see what you mean. Like you said in your other post, LCNC is not a company so therefore cannot itself become a registered or certified compliant OEM. Which places the burden on the community to decipher the proper logic and exactly where to place that logic to get the results you want.

As for tandem axis control such a gantry, wouldn't that be the job of LCNC? The drive is merely a slave. Sure it knows how to the job requested but each slave is an individual. But, I have read that ECAT has the ability to manage this axis configuration. I am not 100% on whether the control is in the master domain or slave domain. I will see if I can locate that document. It may help understand where the logic needs reside.

At the end of the day, most ECAT setups I have worked with use pure ABS and very seldom rely on limit switch/index. On Fanuc, even though the ABS value is valid and stored the user can still tell the axis to home to the switch even though the switch is not considered and stops at the pre-stored ABS value. This was done back years ago because users complained they did not trust the "home" position from the 23bit ABS encoder. Lol.

Both Siemens and Fanuc have a quasi ECAT bus. Fanuc calls theirs FSSB and Siemens the MPI bus. In their controls tandem axis control is relatively simple. If there is a squaring issue, the axis motors can be temp separated allowing for the MPG motion handwheel to be used individually for each motor(X>U) or X1>X2. The user moves the axis into a squared position and then looks at the ABS position for each motor. Then sets each motor to use those as the permanent home location. The motors are then rejoined as a tandem. When you call the home procedure, both motors move their respective offset locations remaining square. These motors are still treated as individuals in reality but shared the same motion thread meaning both X1 and X2 receive the same motion commands. Now, this works because the machine is highly rigid. If you have a "soft" machine the frame can twist forcing the frame to rhombus or the machine has R/P not ball screws. In this case, one would need to have some logic to "square" from the master through routine. Difficult for sure.

There is an ISO on the CiA402 schema, but on the slow bus side this is where the ability to use the extended params of your drive. On the PDO high speed bus, the standards are quite firm and I see no builder trying to shortcut that. It would be a 10 thumbs down and they would be warned by the ECAT Found. If they not a "certified vendor" then it would be anyone's guess on all of the drives workings. Sadly, there are many who "gray market" knock off drives that are "compatible". Only not so much and the docs they provide are useless.

I think the most successful hardware should be a true multi-turn battery backed encoder with a drive that uses the stored value for homing and LCNC position updates. The work around you found POS_ABS = POS_FB or something like that would work as long as you can tell LCNC homing is complete, set the is_homed flag, and use the value from pos-act from the drive as the current machine position location for this session.

In the event that a user does not have the higher grade drives with mutli-turn and stored ABS then the routine would be 100% controlled by the LCNC side no different than if an FPGA was used if I understand correctly. The switches would be directly hal'd to the LCNC controller and use the existing LCNC homing routine in CPM mode. Just like it was a simple ParPort emulated S/D axis. The drive would have to have an Index pulse output for that to work. So there is that. Lol. Complicated stuff. But, imho this defeats the EtherCat solution to the problem this creates. Sure you can stick a stepper on the ECAT network and use inc encoders, but you are outside the box of the intended design of ECAT. These are far less expensive, but what is lost in the "customization" aspect has a cost also. Time is money. So, what is the true cost benefit? Hard to say.

For me, I am retrofitting a DMG DMU 50. It is used and I am rebuilding the machine to new condition. Because it is 5x and the project will cost me $150k+ it makes sense for me to use ECAT with solid drives and motors at $1000+ per axis. If I were to install the latest Siemens control with motors and drives my cost would exceed $225K total. Which is outside my exposure limit. If I were building a home brew machine with low rigidity, I would stick with a MESA card with S/D because the ROI would never be realized based on the complexity of building a FrankenSolution to force ECAT to work with my machine. Can it be done, absolutely. But at what cost.

Just my 2 cents minus taxes for net -2 cents with current inflation. Lol.

Here is an example from Delta for Gantry control. Is this ideal, I would think not. But it would work for sure. The issue would need some research and direct questions to Delta on how homing/squaring is completed. Delta is a sharp group and most likely have this solution ready if asked to provide the details. I will review the manual to see if they detail this.

As shown only one axis is on the ECAT bus with the slave axis being controlled via the master drive via S/D with encoder FB from the slave closing the loop. 
 
Scroll to about the middle of the web page to "Gantry Control". The graphic is pretty simple to understand. 

www.pbasystems.com.sg/product/asda-a2r-delta-ac-servo-motor/


 

This is what I`m implementing now, but delta and leadshine are not correct and did not advertise just the half of the truth of gantry control. They both working on it, and many functions are not implemented yet. Like homing at all, rigid gantry function and align function. But I have the promise from leadshine they will finish the dual homing for the end of the month and will release a new fw.

Thanks for the effort putting in this modification! Now I have time to test it. 

This is what I do:
Download the file el8_homecomp_mod.com and after giving the path to homing.c compile with halcomp
"sudo halcomp --install el8_homecomp_mod.com"

This went ok without errors. 

I changed the Marco's component from the ini to yours:
HOMEMOD=el8_homecomp_mod

Uncommented the drives internal homing in hal on every axis:

net x-home-request         joint.0.request-custom-homing     =>         cia402.0.home
net x-homing             joint.0.is-custom-homing         <=         cia402.0.stat-homing
net x-homed             joint.0.custom-homing-finished     <=         cia402.0.stat-homed

run the lcnc, and the hal pins show up:


I set a hal part for toggle the custom home request:
#custom home request
sets joint.0.custom-homing-is-requested true

After that I have errors, this pin not exists. But is there. Whats next?

Thanks!

change this line:

to


Then the pin 'joint.0.request-custom-homing' (the uppermost entry in your 'WATCH' list should give your the options 'Set' , 'Clr' to manually set the pin to true (ie 'Set'))

The problem is with: joint.0.custom-homing-is-requested

When I set to true to change the state in hal to toggle custom homing, I have this error:
/home/eduard/linuxcnc/custom/M5_EtherCAT.hal:33: signal 'joint.0.custom-homing-is-requested' not found

this is the toggle in hal:
sets joint.0.custom-homing-is-requested true

But I have this hal pin, based on halshow as I attached in prevous post.