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

I am confused in the whole idea. EtherCat drives are not like hardware(FPGA) motion controlled drives. They actually have the motion controller built into each drive. All LCNC should have to do is set the OP states correctly.

If in OP State 8, listen for Pos PDO's and act on messages indexed to my slave ID. Do what the master says. If I have an issue, send an EMG packet to the master. While driving the motor send back pos/vel data. There isn't a real need to even close the loop. Given the DC(Dis Clk) all slaves will operate at the same overall timing of 1ms. Basically just like an open loop S/D system driven from a MESA card but deterministically. If I understand the purest concept of the benefit of EtherCat motion over 402. In other words, LCNC just needs to generate the Trajectory for each axis in RT and send the data via PDO's so the drive can do all the work. Why would you want to have LCNC double check whether your drive is doing the assigned task it is given? Seems redundant in my opinion. LCNC > Drive >> move .001mm then tell me you did. Drive moves .001mm then << LCNC I did it. LCNC >> Good job little boy. Drive << LCNC Thanks Dad. That defeats the entire concept of EtherCat. The loop is open because the loop is closed at the drive level. The position/velocity command is closed at the control level. This creates a very slim and very fast deterministic system based on separation of concerns. A P/C to P/C relationship.

OP Mode 6 - Homing

All EtherCat drives with any real value should have a completely internal homing sequence. Many simply have ABS encoders with battery backup that maintain the ABS position even if power is lost. This value can only be lost if the battery dies. If it does, you replace the battery and reset the ABS coordinate stored in the drive so that the encoder and drive are in sync. Then update the CNC controller who does it's own stuff to sync with the drive. The drive does drive stuff and the controller does controller stuff.

On Fanuc and Siemens controls the ABS value is gathered from encoder ABS position from the drive. This value on Fanuc is stored in a parameter once P 1815.4 is set to zero and then back to 1. The stored value on the control after setting this parameter is then to compare the ABS V on the drive to the one stored in the control at startup. If they differ, the control request an update to the actual encoder position that is then calculated by the drive and then sent back to the control which then updates the machine position value of the control. Fanuc and Siemens also have a special bit that tells the control the drive has not lost the stored ABS value of the encoder. If the bit is high, meaning the drive has lost the ABS because of a battery loss, each have a procedure that then tells the drive to reset the ABS position and store it. From that point forward both the control ABS and drive ABS match. Regardless of the control OEM there is some method for the control to know where the encoder is based on the data maintained by the drive. The control acts as a master for sending the Pos commands the drive needs and the drive acts as master to control the feedback loop. A purely producer consumer relationship.

So, basically what that means is somehow LCNC needs to stop trying to master both sides as it is not required. As far as homing and ABS feedback the drive does all the work. LCNC simply needs a method to know when the drive is done homing. The drive needs to know when LCNC is ready for it to do the job. The soft and hard limits should be controlled and monitored by the drive not LCNC, The homing switch if even needed(Multi-Turn ABS encoders do not) is monitored and wired to the drive.

Let's say I want the machine in a very specific spot in the travel and I have the multi-turn ABS encoder, I can jog the machine to that coordinate, tell the drive "hey I am where I want the axis to be, stored the current ENC ABS POS as zero. The encoder may be a 23 bit with 8M possible "pulses" and number of turns the actual encoder may be at exactly 180 degrees in rotation, it sees the 4M+*number of turns in the counter(Could be a value of 1,000,000,000 or more), stores that value from that counter, then sets the POS register to zero. The ABS position is then calculated based off the offset in PPR+Turns in both directions +-. The value given to the control is the final calculated true ABS position.

Now that I have that value fully stored and maintained within the drive, the controller only needs the calculated ABS from the drive which arrives in the PDO every 1ms. Both the control and the drive use the calculated ABS position to derive their respective soft limits. I can then use my control side soft limits or simply allow the drive to do the work for me which is ideal since the hard limits are wired to the drive anyways. You can still use the hard limits in the control and the soft limits in the control if you so desire. The result should be the same. But, homing in EtherCat is the job of the drive.

Let's say, the battery died and the original ABS REF is lost. The soft limits will longer work. But this should not be an issue. If you have a home to limit setup. the drive has params that control the vel to search the switch and a procedure to follow in order to find the switch which it will do if commanded to do so. From that point, the switch is found, the axis moves to index, then if it has an offset from that position will make an additional move then store the encoder counts+turns into a non-volatile register. In most cases, the drive should never need to actual use the switch unless once again the encoder lost power from the battery. If the drive has full respect and knowledge of the physical location of the drive, I should then be able to send and OP 6 state to the slave, which will immediately send back a response that it is complete without ever moving. That is ideal and based on current modern hardware will be as accurate and reliable.

Many modern drives allow for a no limit required homing method. In the case of many high end CNC Machines, Toyoda, Mori Seiki, Toshiba, etc. they have no hard limits nor homing switches. What would they be there for? The encoder is ABS and knows where it is at all times. Even most scales if using one work without homing switches. This standard has been around for over 20 years. EtherCat drives have had this standard for 10+ years.

So, all that said which is a lot, why is LCNC when utilizing the lcec setup trying to control the drives job. The drive has the full recipe to make the cake. All it needs is the command to make it. LCNC should be only concerned with trajectory planning based on the RS274 Interpreter sending data to the planner. The planner then sends that p/v info over the wire to the drive that makes awesome and perfect cakes. As long as the drive has no issues and LCNC knows the drive is healthy, LCNC should by all measures just keep sending commands to the drive. LCNC has its' own fail safes and can stop sending commands or tell the drive to reset to noOP mode. It would respond in 1ms stopping all motion. Period. If the drive sends a EMG on the error pipe then LCNC should also stop sending commands within the same tick cycle stopping the entire system if say the X axis drive poops out, all the other drives in RT stop receiving commands and the machine fails to a stop condition. There is more in the safety side that is possible but for the basic functionality for Hobby or Light Industrial use where a strict compliance to "STO, etc" are not required the system stays quite slim.

LCNC Behavior As I See It Should Be With ECAT -

1. Power on
2. Reset all drives to OP 6 if all drives report boot healthy
3. LCNC ignores all POS FB, (if used - limits, home switches) until the drive sends back Home Complete regardless of home style.
4. LCNC reads the position actual PDO and then position actual updates the register for the session internal to LCNC. If the drive says I am zero and home, the DRO should match the drive. If the drive is a Home In Place using multi-turn, then the DRO should read the drive ABS position and the LCNC machine position register should be updated to the value from the drive.
5. LCNC should now be ready to send the OP 8 mode to the drives once LCNC has run through its' final sequence and is ready to run.
6. Set Op 8

Maybe I missed a step but 99% of all other CNC controls of any real value work exactly as described above. It is a standard. The only variable is the actual procedure to lock in the stored encoder value. But the control operations work as explained above. Swap out LCNC for Fanuc. Swap it for Siemens. It is always the same for the control if using bussed motion and multi-turn ABS encoders with battery backup. Which almost every ECAT(registered) porvides as a standard model.

It seems highly illogical to try to make some custom this and that to accommodate any drive that is A. Not a registered ECAT OEM and B. Uses antiquated technology. For those who cannot afford the higher price points to step up to ECAT should continue to use the basic ParPort versions with S/D motion controllers. It is way less expensive.

One of the most frustrating aspects of LCNC is the lack of pure standards. If EtherCat with LCNC is to become a mainstream a strict set of standards must be adopted by all users. No custom setups. Either the hardware and implementation follows the standard or it doesn't get done. No use of non-registered ECAT drives or knock off I/O modules from Amazon/Alibaba that will never be registered should be allowed to enter the discussion. CNC machines are very dangerous and the barrier to entry above a threshold must be maintained to keep novice users from hurting themselves or others. Period.

My comments here might be taken as an insult. It is not meant to be by any stretch. But, as an engineer in the CNC control and machine business for over 30 years, I think I have the experience to say we need higher standards for this advanced usage of LCNC. If I offended anyone please accept my apology in advance.

Maybe can start a thread that strictly deals with developing a way to have LCNC follow industry standards as we develop drivers and integrations. I am certain I am not the only one on here with the requisite experience to contribute. Regardless, of knowledge of the entire LCNC Eco System we should be working toward KISS methods and standards that keep people safe and give them the greatest opportunity for success at the same time.

It seems highly illogical to try to make some custom this and that to accommodate any drive that is A. Not a registered ECAT OEM and B. Uses antiquated technology. For those who cannot afford the higher price points to step up to ECAT should continue to use the basic ParPort versions with S/D motion controllers. It is way less expensive.

Thanks for your thoughts but to be honest I do not see much point in statements like this.
I know a fair number of people who think the whole idea of a free and open source machine controller is a waste of time. 'If somebody can't afford to buy a proper machine controller then they should just simply stay away from CNC.'

One of the most frustrating aspects of LCNC is the lack of pure standards. If EtherCat with LCNC is to become a mainstream a strict set of standards must be adopted by all users. No custom setups. Either the hardware and implementation follows the standard or it doesn't get done. No use of non-registered ECAT drives or knock off I/O modules from Amazon/Alibaba that will never be registered should be allowed to enter the discussion. CNC machines are very dangerous and the barrier to entry above a threshold must be maintained to keep novice users from hurting themselves or others. Period.

'No custom setups.' Are you serious? I'm sorry but I my opinion this just simply goes against everything LinuxCNC stands for. 
All I'm trying to do here is help a user to get homing working on his setup the way he envisions it and get a better understanding of the custom homing component in the process and frankly, I don't see why you would need to have such a fit about that.

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.

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/