Position vs Velocity mode

Hi,
you lost 3 orders of magnitude there.
1000mm/s * 0,001s = 1mm
3m/min *0,001s = 0,05mm
so there is a LOT of justification in trying to achieve more.

Plus there is people (like me) that build air bearing machines and want to achieve less than 50nanometer following error on dynamic applications with linuxcnc.
There is a reason why industry controllers run anywhere between 1 and 10khz position command cycle.

Regards
Leo

Hello,

At 60000mm/m the velocity is 1m/s or 39.37 IPS. In the world of linear motion this is quite fast. In the world of CNC, that is astronomical speed. Typically reserved for G00 commands for initial positioning. The limiter here would be the cutting feed. No tool can cut effectively at that speed of 60000mm/m. The scale of limitation is determined by the material being cut as a measure of chip load. Even the softest materials such as MDF have a finite chip load that will limit the overall max velocity of the command. Typically near 8800mm/m or 8.8m/m. Pretty simple.

If I have a 10mm pitch ball screw which will provide 10mm of linear travel per rotation I would need to rotate the ball screw 880 times to move exactly 8.8m over 1 minute. Again, pretty simple. That also means my motor will rotate at exactly 880 RPM. Or 14.6 RPS. If I need to move 1mm at that velocity of 146mm/s I would arrive at my desired position in .146 seconds or 146ms. If I use the same velocity for .5mm then my time of arrival is cut in half. and so forth. Since we are on a 1ms tick cycle and assume 50% of the time on the bus for sending the data to the slave and the slave responds in real time we can assume that the slave can effectively make the 1mm move 6 times +- per second. Not that anyone would ever do this, but for example sake... If I use a 20mm pitch ball screw I can double my speed to desired position of 1mm@8.8m/m at a reduced force arriving in .073ms(assumes a command multiplier in the slave). Now having the ability to move this distance more than 10 times per second. I can further modify this by increasing the command multiplier through EGR or additional pitch on the ball screw to say 50mm. The above only allow for less transmitting of positional data without having to lower the bus speed because the controller need only send half or less the moves to achieve that same ends. *Note - The above assumes you have a 23bit ABS system to allow for maximum PID control at such speeds. Since LCNC is Position Mode only you need the drive to have as much feedback data as possible so that the PID sampling is very tight keeping actual error low.

As you can see, if one is trying to use EtherCat via CoE at 1ms tick cycles, the machine performance with LCNC is more than ample to meet the specifications required to match the maximum effective cutting performance.

The positioning error is also easily managed by a drive that has a 1Khz sampling cycle at the speeds above. Although most drives of substance have a 10Khz sample rate such as Omron, Yaskawa, LS Electric. This is a function of the drive and not of LCNC since it is in Open Loop from LCNC to the drive. The drive closes the loop and uses its' internal algorithms to control the PID.

The accuracy of each move is determined by the drive/mechanical as a function of inertial load and the ability for the drive to control the jerk loads and closely manage settling time. Settling time being a function of the ability for the drive to acknowledge position arrival once settling is complete and is ready to accept the next command given.

At the end of the day, the performance of LCNC is well within tolerance for machine tool applications as long as the hardware choices by the end user are sufficient to drive the given load at desired velocities within a desired overall accuracy.

For nm following error, one would have to have a RT kernel written specifically to only handle the Ecat bus and have a dedicated driver for the PHY(Ethernet Port) to only allow for ECAT bus frames with no interrupts and absolutely zero addressing. This system would be a subsystem of the main kernel. More or less a PC in a PC. Kingstar uses Interval Zero RTX64 in a windows environment. The RTX64 RT is a sub OS that runs along side Windows. Kingstar layered in the ECAT framework inside the RTX64 OS and has achieved a true PC based ECAT with 100 um tick cycles with DC. It works flawlessly. But, it only works in Windows. Mach4 worked with them with me as an advisor to form the integration about 8 years ago. It still works today.

Mach4 has an issue though. They use wxLua for the GUI control and it crashes a lot making it unreliable. Hence, I never pushed forward due to the fact that Mach4 staff would not move away from the terrible wxLua system. The TP designed by the lead programmer is bar none one of the best but I require 99% uptime for my controllers. Mach4 barley breaks 90%. One side note is that I was able to during the same time have Mach4 built with custom Macro B and exactly mimic Fanuc macro variables for a linear compat for my clients who wanted to shift to Mach4 for cost but not sacrifice the overhead of rewriting hundreds/thousands of fixed programs that utilized Macro B. Still works today. But like I said, the wxLua aspect was a deal breaker.

If application desire is to have nm error at speed, you need to use Torque mode over ECAT and use a controller that accommodates that functionality to which, as far as I can see LCNC/Etherlabs has not implemented fully. You would be on your own to write the kernel config and PHY driver for that. Possibly even move it away from the uspace domain. Hard to say. If I were to do what you attempting, I would use a different CNC software specifically deigned for that purpose. But, I do fully understand the cost factor. Unless maybe you can get Biden to subsidize your desires... Lol.

I would find it more than interesting to see if you can achieve your goals in LCNC. Is it possible? Sure. Anything is possible.

I think people get obsessed with numbers that really are not relevant as there are many sources of errors in the final part. For example, 50 nm seems pointless given the thermal expansion of carbon steel is 1 mm/metre from 0-82 deg C. That's 12.2 micons or 609 nm microns on a part 50mm long. Cutting steel unvoidably generates heat so that will distort dimensions, probably more than your target following error.

I can also confirm 60 m/min is close to the upper realistic range of motion. Say on a plasma table without cutting forces, a 30mm dia pinion and a 5:1 gearbox reduction will  yield 60 mm/min at about 2600 rpm, close to the normal 3000 rpm max speed of a servo. Sure you can alter the gearing but that will be at the expense of torque that will likely preclude doing anything useful.

I have experimented with 60m/min and 0.8 G Accelleration (8 m/sec/sec) on a plasma table and can confirm what Don says that the inertia at this level of performance will shake your machine apart. People seem to gloss over that part of his discussion but it is very true.

There are more other stuff in the servo that we think.. current pid loop(which we should called torque) is running xtimes faster then velo or pos loops.. when we want to run comm faster then 1ms, here we are on limits of servo loops itself .. we can see that in default setup of many servodrivers is this velo loop in most cases longer then 1ms and from my expreriences current loop are shorter then 1ms... 
​​​These regulator are pain to set correctly.. when somebody want to have FE in the nm, atmosferic conditions have to be constant(p,t, etc..) .. guys from kern machine has tolerances around um and there top of the world..

But there we are facing of kinematics limits of serial kinematics machines..

When you want to have precision below um, you have to use paralel kinematics ..

I found an example of said inertia, where I cut a small V shaped notch when plasma cutting a hook for a curtain rod to act as a fold mark.

Here the notch was deep enough to get to cut speed of 2.2 m/min before immediately reversing. Accelleration was probably 5 m/sec/sec (0.5G)

And I thought I had a stiff gantry!
 

Donb9261 wrote:

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.

...

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.
 

Maybe my use case is a bit different as it is on a milling machine which is comparatively slow compared to the numbers being mentioned in this thread. But at the 0.0005 - .001ms offset you mention at a 10000mm/min milling speed (max rapids in my case) would only result in a position deviation of 80~166nm!

My plan until reading this thread was to use the existing linear encoders on my mill to try and compensate for the cheap ballscrews it came with, using linuxcnc to close the loop (without spending thousands on drives that support linear encoders). I don't understand why that wouldn't work with ethercat? My existing linuxcnc control loop with my old stepper motors is 1ms so nothing has changed there, so what would I gain using for example a Mesa card and step/dir commands? The cheap servo I bought for testing cost the same as the non-ethercat version as far as I can see, so would be nice to make use of it if I can...

Thanks for all the info you're providing here, it helps with design decisions!

That level of error leaves very little time for the loop to react to sudden disturbance. Even Fanuc typically has .002mm or more following error. The misconception is that a true motion control system should as close to real time as possible. This ignores the basic physics of motion control in the first place. P/T is a measure of velocity. V = P/T to be exact. The controller and the axis do not share the same time domain regardless of ones assertion otherwise. It is always a master slave relationship no matter how you drive the axis. The servo reacts to commands and does it's best to recreate the directives given form the controller. Therefore error is expect and even used in practice to place a sync tune across all axis in the coordinate system.

A servo has 1 job, to do what it is told. Some are tied direct to the controller in Closed Loop and others run Open Loop where the servo simply needs the count and speed to count leaving the servo to do all the leg work. The controller has no idea what the servo is going through. In closed loop control it can estimate the load the servo is trying to move around like a loyal dog but given the time domain shift the controller must wait until the servo sends enough warnings for it to react to error, over torque, etc. Modern servos move the function of TP(trajectory planning) and the tree loops position, velo, and torque internal to the drive.

There is little to gain in trying to chase nm of error by trying to over tune a poorly constructed load carrier. Even a modestly tuned servo will hit target within .001mm at speed if the load it carries is well designed to match the capacity of the servo. All servos have a base line inertia ratio. The lower the inertial ratio the more the servo costs. The lower the servo inertia and load inertia the more stable the driven axis will be during the phases of motion. ACC, CONTINUOUS, and DEC. Each phase has its' own concerns the designer must take into account. Almost every servo error issue is related to excess load characteristics caused by either under sized servos or mechanical failure from wear or moments created by poorly designed acc/dec profiles. Jerk tries to solve this but most off the shelf drives less than $1k only allow for trapezoidal velocity curves.

So, what does all that mean? It means that in order to meet the desired design demands the designer must spend a poop ton of cash on a properly engineered machine then try to adapt a control to that. Not the other way around. Even if your servo hits target at .0001mm, the axis mechanically will not be there. So, nm of error cannot help.

Consider this. DMG makes a machine called the DMF. It is a traveling column 5x vertical machine with a fixed table. It rapids at 1800IPM and has a max feed of 500IPM. The column weight is apporx. 12K lbs. Or around 6K kgs. The travel distance in X(column carrier axis(XYZB) is up 6m. The acc/dec profile is non linear or trapezoidal. It is Bell shaped with 2 tier jerk control. The acc of that 6K kg load is .2s and creates 1.3g force on all moments. The column rides on 4 75mm trucks on 75mm cross section linear rails with 24 M16 bolts holding it down. During the acc/dec the machine which has a Polymer Granite base weighing apprx 9K kg bends like a banana in the middle by .035mm during acceleration and deceleration. This machine is engineered to near perfection and still suffers over short time frames major failures of the linear rails every 2-3 years and must be replaced. It is known quantity the customer accepts in exchange for .002mm precision at that speed. The net cost for the 6m(DMF 600) version, 1.9 million.

Can LCNC achieve similar results? Sure. But the control is the slave to mechanics. Not the other way around. A machine made from Aluminum extrusion using rolled ball screws on standard c7 grade gothic linear rails will never improve because you put a Mercedes engine in it. The engine will simply beak the chassis into bits.

Thanks for the reply, sorry, I wasn't clear in my post - I'm not targeting nm error, it's not even possible on my machine, just that ~160nm would be the max possible error caused by the latency in EtherCat master at the worst case for my mill. This is such a small number in comparison to all of the mechanical induced error that surely it wouldn't stop me using linuxcnc in closed loop with linear encoders?

I currently have just under 20um of following error using steppers with linear encoders on my X and Y axis, and was hoping I could use the same setup on my Z axis but with an ethercat servo instead of a stepper.

That error is well within normal ranges even using a scale. It is never recommended to use a combination of stepper and servo though. It can be a challenge to match the FF gains due to the mismatched inertial loads of the motors. This will become apparent when you do an interpolation in 2 axis XZ or YZ or a 3 axis XYZ where blending will be an issue. Other than that, your experiment should yield some measure of success. The extent of which will be trial and error your part.

Are you using a Mesa for scale feedback? Typically, the scale will be connected to the TP connect device. In Ecat this is the drive. The A3 drive as far as I can tell accepts an external CL feedback device. But I think it is serial using SSI, or EnDat. I don't remember seeing an incremental scale interface for the A3 in the manual.

Like I said, as far the Ecat driver for LCNC, I do not see the support for closed loop control which makes sense given the pos mode only true support. But, I have been wrong before and have no experience trying to get LCNC closed loop over ECAT. Typically you want to close the loop as close as possible to the TP and PID controller. In POS mode, that will be the drive. In VEL or T mode the choice is yours.

Finally, in ECAT the DC(distib clock) is used to sync a specific bit to all devices so that for motion all drives will react simultaneously to commands within the same time domain. That is the SYNC bit. Once the Tx is returned with all devices ACK through the working counter they are ready to do work, the sync bit is set and the drives go to work. This happens every bus cycle. Using non-ECAT drives would preclude any ability for you to control the sync domain. It may not be too much of an issue unless doing any machining that require absolute sync during interpolation. The drives individually may no error of substance but the axis to axis or linking error will certainly be undeniable. How much error is a crap shoot on every interpolation start.

Good luck Sir.