Position vs Velocity mode

More
2 years 3 months ago #304502 by rodw
Replied by rodw on topic Position vs Velocity mode
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.
More
2 years 3 months ago #304514 by endian
Replied by endian on topic Position vs Velocity mode
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 ..
The following user(s) said Thank You: rodw
More
2 years 3 months ago #304520 by Aciera
Replied by Aciera on topic Position vs Velocity mode

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.

Hence the need for jolt limited tool paths.
Which shows, for high performance CNC machining, one needs to fine tune every component of the system. Toolpath, software, electronics, mechanics and ambient atmospheric conditions. The effort required climbs exponentially.     
The following user(s) said Thank You: rodw
More
2 years 3 months ago - 2 years 3 months ago #304523 by rodw
Replied by rodw on topic Position vs Velocity mode
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!
 
Last edit: 2 years 3 months ago by rodw.
The following user(s) said Thank You: Aciera, Unlogic
More
2 years 3 months ago #304530 by Robbbbbb
Replied by Robbbbbb on topic 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.

...

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!
More
2 years 3 months ago #304543 by Donb9261
Replied by Donb9261 on topic Position vs Velocity mode
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.
The following user(s) said Thank You: rodw, endian, zmrdko
Time to create page: 2.442 seconds
Powered by Kunena Forum