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

While I understand your concerns and do highly respect the concept of free and open. Like I said, it was not meant as an insult nor was it a "fit of rage". EtherCat is a simplification layer for deterministic control of machinery. Free and Open does not exclude a technology from at least seeking to match industry accepted standards so that millions of FrankenMachines are not out there.

One of the critcal and honestly best aspects of EtherCat is simplicity of setup. In regards to LCNC, that is no where near the case.

And lastly, I respect your helping this person with their unique concerns. I truly do. But, if the standards were in place his problem would not exist. And that is a fact.

Like I said, I was not blasting the budget user. Or I wasn't intending to do so. If I did, my apologies have already been issued in the original post. At the end of the day, if we can set aside our feelings maybe we can find a method to make this process easier through standardization. That is my argument and frustration with CNC. Not with users.

The reason for no custom setups is as I said, they should not be required. Period. The drive if it has followed ECAT drive ISO's already has everything it needs to what he wants. The issue is the LCNC side. Instead of a custom homing driver, a standard driver with deterministic behavior as I described should be used that way everyone involved speaks a common language. Take that for what it is, like I said it was not an insult not a fit. Just fact.

Instead of a custom homing driver, a standard driver with deterministic behavior as I described should be used that way everyone involved speaks a common language.

I think you are misinterpreting the term 'custom homing driver'. The reason custom homing modules were brought in is the simple fact that before the 'standard' procedure, that comes with an installation, had to handle all the possible homing scenarios which means that with every new addition the source code got more complicated. The custom homing module makes it possible to create homing procedures built for specific purposes without having to retain all the built in functionality. But if you want you can even use that custom module only for specific joints while choosing from the built in homing procedures for the others.
If you feel so passionate about a standard homing module for EtherCAT users then I would encourage you to open a thread about creating such a module. And, yes, that would then be the 'standard custom homing module' for EtherCAT.
I think @rodw is actually working on that. See here: github.com/rodw-au/cia402_homecomp

The general problem is that those who do the programming often don't have the hardware to test things and those that have the hardware just want the machine to start making parts and can't be bothered to get involved in testing. Can be very frustrating.



 

Well, I can help with both. I am working with LS Electric to provide some lab materials just for that fact. The hardware is affordable and LS has complete compliance with all cia_402 and EC ISO standards. With all options for setup available so a standard for all methods can be created in one file with zero need to "tweak" for special reasons. The only group who would maybe need to do some "tweaks" would be persons using robotics vs standard CNC use as they are typically 6 servo systems but only use 2 per axis to create XYZ.

I am currently going through all the LS docs and the lcec drivers. It is a lot of code. And a bit confusing. Once I have the hardware, I will work with Rod to hopefully have a single homing procedure for all methods in a single driver. Maybe an Enum to select the homing method. I can forsee a need to use an SDO though which in several of the xml's for Beckoff I/O use. But the few servo xml's available simply use the based RPDO/TPDO method. So that pushes that to the cia side on the slow bus. No worries, just needs to be figured out.

I am aware of Rod's work on that and his goals match my own. Hopefully with enough brains we can see some progress this year toward a solid integration using the ISO standards set forth by the ETCAT symposium.

Like I said, the idea of ECAT is determinism. Given a specific input a specific output is always realized in real time. The lack of free will and randomness is the secret sauce that makes it work so well and be so reliable.

Love the debate. Five thumbs up.

Hello, I am honored to be in such a forum.
First of all, I would like to say that I am new to Linuxcnc. I have 4 mtors and drivers that are not absolute encoders with ethercat cia402a support?? The drivers are working now but I couldn't manage to make it home. drivers manual link download.plcsystems.ru/Xinje/docs/DS5C1_servo_manual.pdf

I have 4 units of the 750w model, I can buy more After installing rodowan step by step and making the settings I knew, I made the step settings of the motors and started them.
Now the home and limit switch are not working????
All are in working order, so tested on Linux CNC The drive has h cw and ccw limit siiwtch inputs, but I did not understand how to connect it as a tom and I could not find enough information in the user manual for the connection.
All the additional linear rails and screw precision mills required for the machine I want to build are available, all of them are THK or Bosch brands.
I would be honored to test it I'm new to linuxcnc But I bought all the necessary hardware and all that remained was testing and processing.
If you wish, I am open to testing via remote access. ???? Please note that I have limited knowledge of Linuxcnc. I have a thinkercentre pc, asus touch lcd and many other hardware,
even a second cnc. I BOUGHT MES 7i95T, I will open a topic soon and add my progress for two cncs.
I will continue with the drivers of the other CNC, a delta asda-m-0721 3 axis single driver, a special driver. I am ready to test anything regarding ethercat. I am open to anything if desired. I speak a foreign language. I would like to thank Google Translete for its valuable contributions every time. I'M SO SORRY IF I DROPPED THE TOPIC.   

I think Linuxcnc predates ethercat by 20 years or more so linuxcnc had to do it all. Don't forget there is a lot of other things involved in homing like squaring the gantry etc. How do you tell an ethercat drive it has a mate on the other side of the gantry and they are not perfectly aligned so it needs to move 2.0mm more to be square by a HOME_OFFSET? What about the HOME_SEQUENCE to lift the Z axis up above possible obstacles before moving X & Y? This is not specific to ethercat. We still need some of the standard elements of homing.c

The whole concept of the custom homing module is to do exactly what you seek. That is to tell linuxcnc to get out of the way so the drive can home itself. But the custom homing module was only a conceptual skeleton written by one very smart LCNC developer and its not just for ethercat. Its up to us to make it work for ethercat it.

If you read some of the lengthy issues on Scott Laids Git repo, you will find that CIA402 is not as rigid a standard as you think it is.

The other issue is that there needs to be a method to enable the drive and commence homing at the right time. Thats not in the homing module or the hal driver.

When I got involved in this, I was really stuck because I could not get ethercat installed on Bullseye that I had to run to get kernel support for my NIC drivers. Grotius was a life saver as he built a .deb file for me. At the time we were relying on an obsolete ethercat master code repository. Eventually I found the igh Repository on Gitlab and finally worked out how to simplify installation which I documented on the forum here. Over time Igh improved their repo as it came out of beta. I was really lucky to get some support from the guys at igh who contributed to some of my work by debugging the hal driver that had not been worked on for a long time

I built the 2.9 Bookworm installation ISO on the downloads page and moved  elements of my sticky into the ISO. Initially, I was hosting a repo for the hal driver. Then igh struck a deal with Sasha Ittner who initially wrote the hal driver to host the debs on their ethercat repo. This let me retire my repo. Not long later, Scott Laird got permission from Sasha to take over maintenance of the hal driver and started to do some significant upgrades to it. I was able to join the dots and before long, with help from igh, Scott had an automated build and test environment on his repo and his debs are automoatically built and deployed on the igh repo with the ethercat driver debs thanks to Bjarne at igh. 

So we now we finally have a reasonable ethercat installation path  for users in comparison to the dark mysterious abyss that existed before I got involved. There is enormous interest in ethercat now and many users are taking the plunge.
The time is finally right to push forward with ethercat as the build and distribution environment is in place.

So lets assume we get this homing sorted out in the short term, the next step is the sequencing of the switch on and start homing  logic.
I dd a lot of work to attempt to bring this into an earlier homing module that was never finished because it was obsoleted by big (but positive) changes to the custom homing framework and i lost interest in this for a long time and nobody attempted to take it on until recently.

I subsequently have formed a view that this is the wrong place for it. The reason  is that while homing is serviced by the servo thread, because it is an internal module, it will sit outside of the lcec ethercat loop. At best, this means our cia402 control will lag one cycle behind and at worst things will break. So the sequencing needs to happen in the hal loop (between lcec read and lcec write ) either as a seperate component or built into a ethercat driver module.

So sorry for the long winded essay, but ther is a lot of history to understand to go forward.

This have gotten out of hand in a jiffy !
Thank you all for keeping it civilized, i do read everything all the time but had no time to reply.