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

So really the gantry function is not needed / helpful when we have a full controller (such as LinuxCNC)

And what we need is to be able to configure 'home offset' whether homing is done fully in LinuxCNC or in a servo drive

Possibly. I work with Siemens and Fanuc extensively. Daily in fact. For a myriad of reasons all motion for any purpose is controlled by the controller/master domain. It makes sense if you think about it.

In the Delta scenario, D1 drives the motion of D2. If D1 sends erroneous commands to D2 the controller would not know which violates the Functional Safety standards used internationally.

On both Siemens and Fanuc the gantry or tandem control is done fully closed loop per drive. Both use active position control to maintain the sync between the 2 axis positions. All commands for both are mirrored but the net motion is constantly being updated to keep error aka following error as close to zero as possible. The drives are set to Torque mode over the bus using the drives ABS position feedback and direct scale feedback(connected directly to the controller not the drive) or simply use the drives ABS FB POS.

Essentially, this makes the drives although ECAT based a dumb terminal that just does what it is told. For CNC where high precision is required at high velocity this makes perfect sense. If I am simply controlling a Pick and Place machine then precision is required but within a wider error spectrum.

I am thinking the best solution for the entire LCNC and ECAT is to do the same as what Siemens/Fanuc have done and find a solution for homing that makes sense based on true ABS encoder technology. There is a net savings in cost in doing this as well as ensuring the precision required. The cost savings comes in the wiring and reliability aspect. Less wires less cost and less chance for things to break. And it maintains proper separation of concerns with a true master slave setup.

I will be looking at how to change LCNC to act more like the CNC ECAT standard vs. trying to reinvent the wheel. Currently LCNC has a single mode for positioning. Command Position Mode. Which is the same as S/D mode using a Mesa. The drive is in follow my lead more or less. This creates some questions as to whether the ECAT interface in LCNC can use the same functionality of the standard interface within the ECAT interface. Can LCNC use the ABS POS FB as the FB to close the loop on the LCNC side? Will the driver do an actual tandem control? Can LCNC custom homing work with a "home in place" "update position to current ABS POS FB, then assume homed?

These are all questions that need to be answered. I will try to do so, but the documentation on the LCNC ECAT interface is lacking a bit. Once you figure out the best practice for how to control the axis over ECAT in the available mode, then how to tandem and how to home become less obtuse. In my honest opinion, using the drives as a dumb terminal similar to Siemens/Fanuc is the best course to take if one wants a gantry axis setup with homing and sync.

I wonder if we could use the ECAT to move the servo and a Mesa for scale feedback simply for a gantry axis to close the loop allowing LCNC to provide the requisite sync/error control along with the homing to index/ABS case? It works in S/D mode...???

Remember Linuxcnc is THE MOTION CONTROLLER!
Linuxcnc will control two motors in unison. 
To Home a gantry though, I think we would need to extend custom_1joint_state_machine()
github.com/rodw-au/cia402_homecomp/blob/...2_homecomp.comp#L139
You can see the code calls the homing.c state machine
github.com/LinuxCNC/linuxcnc/blob/master...motion/homing.c#L718
which deals with offsets.
It's probably not a big deal as it would just move the two motors in unison after they are both homed by the home_offset if HOME_SEQUENCE is negative.
But lets just get one joint homing first.
 

Donb9261 wrote:

I am thinking the best solution for the entire LCNC and ECAT is to do the same as what Siemens/Fanuc have done and find a solution for homing that makes sense based on true ABS encoder technology. There is a net savings in cost in doing this as well as ensuring the precision required. The cost savings comes in the wiring and reliability aspect. Less wires less cost and less chance for things to break. And it maintains proper separation of concerns with a true master slave setup.

I will be looking at how to change LCNC to act more like the CNC ECAT standard vs. trying to reinvent the wheel. Currently LCNC has a single mode for positioning. Command Position Mode. Which is the same as S/D mode using a Mesa. The drive is in follow my lead more or less. This creates some questions as to whether the ECAT interface in LCNC can use the same functionality of the standard interface within the ECAT interface. Can LCNC use the ABS POS FB as the FB to close the loop on the LCNC side? Will the driver do an actual tandem control? Can LCNC custom homing work with a "home in place" "update position to current ABS POS FB, then assume homed?

 

Don't get to carried away. Linuxcnc has been homing for a long time. Many of us don't want to spend on high quality absolute encoders and that is not mandated by the  ethercat standards. In fact, the cia402 standard does not care how a joint is homed and neither does Linuxcnc.

Whilst the documentation may be sparse, the code base isn't. You need to read and understand homing.c and how homing works as discussed in the docs under homing configuration. When you read that you will see that our home comp knows the home offset and homing sequence of each joint.
so we now know that after a joint is homed, we need to move the home offset and if the home sequence is negative we need to move it in unison with the matching joint with the same negative home sequence number.

So gantries don't sound hard at all!
But said, we need to get 1 joint homing first.
I'm quite happy about what I found out tonight because we don't need to litter our home comp with additional pins!

 

Thanks for the clarification. But, I was talking respect to the Delta tandem axis solution which gives LCNC control of only one drive while that drive controls the tandem drive. Not ideal at all.

I have not seen where the tandem axis control is open to ECAT. Did I miss that? I know for the standard non-lcec servo thread it is. If so, where is the documentation for that to setup the ini and hal for ECAT tandem axis(aka Gantry) control. If this is already available, then yes homing becomes much easier and can be controlled by LCNC in isolation for at least the ABS multi-turn condition.

So, let's understand this. Can LCNC with lcec provide proper tandem axis control of sync'd motion? IDK... If so, what is the best practice for the ini and hal configs?

On that thread, what is the best practice for providing a known datum(homing) that satisfies the tandem axis problem?

Option 1 - Use the drives encoder out pins to a Mesa card and let LCNC see the Z index for each motor for non-multi-turn encoder drives
Option 2 - Use a scale with Mesa to do the same thing if the drive does not support RS422 output and also uses the home to index/ref marker from the scale
Option 3 - Use the ECAT derived FB POS as the failsafe actual position and write routine in custom homing that simply uses the multi-turn recorded and stored position value to call the axis "homed" then simply move the axis or tandem axis to the zero location from that derived position

Once homing is complete, will LCNC close the loop for the tandem axis as it does in the non-lcec setup? Or is open loop good enough? I would think so given the drives are ECAT on 1ms ticks. More than ample for low error sync. That is how the big boys do it. I see no reason why it would not work here other than the slight .02ms lag over the lcec bus as compared to a standard ECAT system. iGh has the timing table in their docs. I don't see an issue unless the machine exceeds 2000IPM. Which if so, I would not use LCNC. I would buy a Siemens control. ECAT chips are mature enough now but I am still always suspicious of motion at those speeds. For good reason.

I think we are making progress here at least in terms of speaking a common language. It inspires me that soon a solution for the problems will be found. Thanks for your kind assistance. LCNC may soon be let loose from the stone age! Lol!.

pippin88 wrote:

So really the gantry function is not needed / helpful when we have a full controller (such as LinuxCNC)

And what we need is to be able to configure 'home offset' whether homing is done fully in LinuxCNC or in a servo drive

Ys, this is all that's needed. we include homing.c in our homecomp which in turn loads homing.h
This code that sets these parameters is called from our homecomp github.com/LinuxCNC/linuxcnc/blob/master...motion/homing.c#L607
 

On L615 there is a bool for volatile_home. What is the meaning of this state?

Okay so if true then the axis must home on start up.

3.10. VOLATILE_HOME
If this setting is true, this axis becomes unhomed whenever the machine transitions into the OFF state. This is appropriate for any axis that does not maintain position when the axis drive is off. Some stepper drives, especially microstep drives, may need this.

Wouldn’t this assist with the home routine where the axis home is stored in ABS and required no home? If false, then read the ABS, set joint homed true. Set the machine coordinate to the current ABS. Homing done. ?

Seems you could also create a bool to switch back and forth between the gantry mode and independent mode. Say you had X and U as your tandem axis set. You could then when independent move the motors and measure the square of the gantry. Once square, set the ABS for each drive, then switch back to tandem axis control in LCNC. Done?

Seems somewhat logical to me, but unsure what has to be done get that into code yet.

The final word from Delta on Gantry axis control.

Quote -

This gantry mode, intended for our EtherCAT controllers  did die.   However; they left some features in the drive that can help you accomplish this.
 
There is no substitute for the upper EtherCAT CNC control to have a gantry mode.  If the two controllers mentioned below don’t have a gantry mode, then you may be able to use some extra features in the B3A-E
(example part number for 400W, 220V ASD-B3A-0421-E) that can help. There can be two methods.

 

The B3A-E servo drive has “pulse train” mode.  Meaning when you use it, the drive is not in EtherCAT mode.  It can be set up to follow the encoder of
another drive – the slave of the gantry.  The position of the send drive can be monitored via EtherCAT and the other general operational status can be monitored via General Purpose I/O .If you can put both on the network, and use the control’s gantry mode, you can connect the encoder output of each into the other and EtherCAT can monitor
it.   

You may need to sacrifice (swap out) a PDO for this extra encoder into each of the gantry drives.Extra logic for the machine will need to be written to monitor for skew.It would be better to do this with Absolute encoders, correct skew on power up and make sure it does not go out of skew during operation.


 
Above is just an overview.  There is not white paper because the next step of control was supposed to be implemented in our EtherCAT controls, but never was. 

However, because the drive can be set-up to monitor and send the secondary pulse input over EtherCAT, it is possible for a third-party control to use it for gantry mode

I think the framework is already there in Linuxcnc but will need to be ported to the custom homing module
if home sequence < 0 then find the other joint(s) and home together.
Once both homed, if a home_offset exists, move each joint by the home offset

So if a gantry needs to be squared, the home_offset for each side will be different and account for the squaring.

I have not looked at the various homing modes again but it might be possible to do this internally by setting the parameters in the drive accordingly. without linuxcnc involvement.