Position vs Velocity mode

The problem with LCNC and ECAT is that the master which is lcec driver from EtherLabs has a lag over the true ethercat comm cycle. In their docs they show a .0005-.001 ms offset from the true 1 ms tick cycle required for true ether at frame rate. That means that the FB of position is at a lag. Therefore by the time the position is returned to LCNC and LCNC recalculates the new position and determines the error the data is outdated. So Lcnc will never be able to show the true error nor fully close the loop over ether at in the purest sense.


So yes, set the pos error in LCNC outside the theoretical value it derives from the outdated error value. If you see .22 set it twice the value. And forget about it. The drive error position if you want to actually see the true value can be assigned to a PDO on the Tx side if your drive supports this. But in order to use it in LCNC you will have to use a side routine to monitor it and stop if nth value is exceeded.

The other course of action would be to install a scale and set LCNC to use that position to monitor the actual position to derive error from. But it would be overkill and a waste.


With LCNC over ethercat think of LCNC as a GCODE sender kinda. The sender has no idea if the axis did its job for the most part and assumes it did. But since I have a really smart drive, my assumption can within solid parameters be correctly assume it did its job.

This is the best you will get with LCNC.

Vital Systems has developed a board for MaCh4 that uses an external ethercat controller over an Ethernet connection. It works very well and has the true 1ms tick cycle.

They will not develop one for LCNC due to the license issue with Open Source LCNC. They will only make black box devices. If the connect to LCNC by license they must expose the inner workings of their device. While I support open source software I do not on the hardware side. It is very expensive to develop and it would basically give company b the ability to bypass the cost of developing their own at the expense of company a. That is communism. Not my cup of tea. lol.

In any case in full summary, if you have a mean position tolerance near .0005” or .01mm then you be 99% sure that your motors will maintain the correct position at all times. The only variable after that to maintain that accuracy at the part is the mechanical system the motor is attached.


Hope that helps.

0.22 mm following error at 3000mm/s (and the fact that the error scales
with speed) means there is a ~73 usec difference between where the
drive sampled the position and LinuxCNC's commanded position.

That would be the combined lag for all users of that stream of data. Yes. But this does not actually matter.

LCNC is just 73ms behind the truth. But the truth is still happening at the part. Kinda like a time continuum. But the accuracy is not impacted because LCNC is not closing the loop. The drive is. LCNC is just a postman and a UI that also happens to pass out positions on an EtherCat stream.

Unless your round parts are not so round after all, there should be no real concern at all. The time it takes to make a round trip is not effecting the accuracy or overall outcome. The position displayed on the DRO will match the position that is in the drive. The error is only a concern of the actual loop controller which in this case is the drive. If it is within a desired tolerance on the drive then it is good.

Hope that helps.

Actually I would expect the drive to be behind LinuxCNCs command.
This can be determined by the sign of the velocity and sign of the
following error.

The realtime command yes. But the calculated error is downstream of the command and is calculated using the Tx PDO returned by the drive. The round trip time is what the original question was about.

But, like I said LCNC is not closing the loop, that is isolated to the drive in ECAT under LCNC. Hence the document from Etherlabs telling you that position mode is all that is really supported although the v and t modes are available.

The error in LCNC is really just showing the comm delay and not real error. Which if you compare the actual in the drive to LCNC you would see that LCNC has exponentially larger error. Which based on the 2-3ms tick cycle that lcec is capable of managing. The doc is available at Etherlabs.

Thank you Don Bozarth! You saved me a lot of hassle I would undergo with velocity mode!!

Thanks for laying this out. One question remains: what if linear scales come into the equation? Specifically ones that are connected to the servo drive and fed back to linuxcnc via ethercat.
I’d assume thatcher best approach would be to handle this feedback in the drive (again). However, what about gantry setups?

The gantry question is till open ended but I would have to assume like with standard Mesa or any other motion controller using the XXYZ, or XYYZ axis setup would send the synchronized commands for tandem motors. This works. As far as whether this is the case with ECAT, I have nothing specific to offer as I do not use tandem axis control aka gantry.

As far as scales, many drives offer a scale interface that can used within the drive as the primary position FB device and that position from the scale would become the FB sent to LCNC. But, again it is open loop from drive to controller and closed loop in the drive. Nothing changes there.

The difficulty with gantry is if you wanted use an auto squaring routine. Typically, if a 23bit encoder is used this makes the alignment pretty easy. You would unlink the tandem motors and and then use step jog or MPG mode to square the gantry by moving each motor until they are square to the opposing axis, say square x to y. Once complete and you like the final position, you would then use the drives routine internally to set the current locations of both motors to zero and store the motor positions in the drive. At that point you would need to somehow tell LCNC that when the axis FB is known from the drive, assume it has been homed. Or some variation otherwise.

There is another thread on the homing issues. A custom homing function is being tapped about with Rodw. There is a link to the github file. But, as far as I know, it is beta and does not show functionality for gantry type homing for those who do not have the higher grade 23bit multi turn Absolute encoders with battery storage of the encoder position through power cycle. In my opinion this would be the only way as I can tell with LCNC to have homing with a gantry. Given the pure open loop controller/drive interface and the I/O lag based on the Etherlabs ECAT driver, if you tried to use the I/O from the drive to catch the home switch and then catch the index pulse, you could have a roving home target.

You could however, use the RS422 encoder output from your drive which many have to catch the home switch input and then the subsequent index pulse using a mesa card. I do not know if it is 100% possible to do as I have never tried it, nut it is plausible. But, this adds wires and a Mesa card which may be nearly the cost of the upgraded encoder requiring the already available internal drive homing to all the work.

I am still running down this rabbit hole and if by chance I figure it out, I will post it with all the files needed.

I hope you'll do the same.

Glad I could help. This is what I do for a living but not with LCNC. I still learning the ins and outs just everyone else. Some of it makes sense, but much of it is wrapped around older technology with ParPort emulation through hal using step and direction drives. While they work and are cheap, they do not serve my specific interests or needs. I am a CNC engineer so I expect my machines and my builds to be as precise as the ones I build and design for my clients. If not more so. LCNC, is a free software that has ECAT, TCP, and some other functionality that make it affordable for my needs leaving me extra cash for the better hardware. Mach4 also has EtherCat but no TCP nor kinematics. That makes it very hard to to do true 5x work. So, I am going to use LCNC to build a very accurate +-.005mm volumetric 5x mill for my needs. Well, hopefully.

Have a great night guys. Feel free to reach out, I either know or know someone who does and will gladly help as much as I can.

Donb9261 wrote:

There is another thread on the homing issues. A custom homing function is being tapped about with Rodw. There is a link to the github file. But, as far as I know, it is beta and does not show functionality for gantry type homing for those who do not have the higher grade 23bit multi turn Absolute encoders with battery storage of the encoder position through power cycle. In my opinion this would be the only way as I can tell with LCNC to have homing with a gantry. Given the pure open loop controller/drive interface and the I/O lag based on the Etherlabs ECAT driver, if you tried to use the I/O from the drive to catch the home switch and then catch the index pulse, you could have a roving home target.
 

There is nothing beta about the Custom homing method. Its part of Linuxcnc and documented for over two years. In fact some people have quietly implemented it.  But its up to the user to implement a version for his needs. Nobody wants to do the hard work of coding.  If you want to home a gantry using custom homing, its up to you to include support for it.

I might be wrong, but I see this is pretty trivial to add for Ethercat drives that have been homed internally. Once homed, they just need to move each side of the gantry  by the amount of the home-offset specified in the INI file in unison and reset the position as 0,0. Whether that works for drives with absolute encoders remains to be seen.
 

Sorry, Rod I was talking about your version in regard to Beta you have been working on. Not the custom homing overall. That is well established.

After too much coffee, and some serious good nerd time I agree the issue for gantry homing is trivial. Based on Rod's feedback I think the drives can handle the entire scope of homing using the cia402_homecomp.comp driver. Correct me if I am wrong. You know more about the LCNC side than I do.

Based on the LS Electric iX7 drive manual there are many homing methods. All that use the index and home switch seem to match that of Delta and other EC drives and follow ISO methods.

Regardless of whether an int n_extrajoints, the method in the drive should work by simply setting OP Mode 6 to the respective drives. In the case of extra joints(XYYZ), both YY motors would receive the OP 6 control word when it was their turn to home, and the drives would start the homing procedure at the same tick cycle(sync'd +-.001ms). This requires careful thinking on the drive side since the motor direction is opposite per motor. Which I think the direction of travel per motor should be set in the drive and not controlled by LCNC. Both drives must have the exact same homing method setup. Also, acc and dec should be the same which is typical. FF gains the same. Homing speeds(based on the drives home speed params for your drives) must be the same. The home limits must be pretty close to the same actuation time with a tolerance of around .125mm or .005". Both drives need to home to index since that value never changes(unless one motor slips the coupling or is changed). Each drive will have its' own home offset and each motor after finding the index will stop at the offset potion and call that zero or home(each motor has its' own home_offset in the drive not LCNC). At this point the home complete Tx is sent to LCNC and LCNC sets homed pin for each motor and resets the LCNC POS Counter/register to zero, update halui for gui. Set OP 8. Next drive in line to home until n_joints is satisfied for all joints.

The reason you need to have the home switches set very tightly is the reversal once the home switch is found so as not to create a large error between the 2 motors causing ballscrew or pinion damage if say they are .250mm out of sync mechanically. This will cause wear and eventually loss of accuracy.

Other than the above, I see very little need to make any real custom homing methods as long as the drives follow the cia402 homing methods. Mitsubishi, Delta, Yaskawa, Panasonic, Sanyo Denki, etc. all use the same or more homing methods as this home and index type has been standard for well over 4 decades.

Each drive will have to be set up according to the drive OEM properly and accurately. But, based on the above if correct the homing issue can be standardized without much fuss or C coding at all. Which is nice.

But, all the above is contingent on whether your drive supports this functionality.

Hope that helps.

The LS Electric iX7 manual is here:

cdn.automationdirect.com/static/manuals/.../ix7nhusermanual.pdf

Section 5.6 describes each homing method available.

Page 136 shows the breakdown of the homing PDO's. The Home Offset PDO is R only. You can RW the other values but I think this is best handled at the source which is the drive and hard coded in the drive. This will keep the fat fingers to a minimum and not send erroneous data on the pipe. KISS method applies as always.

I include LS Electric drives because they are my chosen vendor not as a sponsored endorsement.