Planning moves. Lookahead over short vectors and blending vectors.
- User_paulvdh_42
- Offline
- New Member
-
- Posts: 4
- Thank you received: 0
1.4. Planning MovesMake sure moves are long enough to suit your machine/material. Principally because of the rule that the machine will never move at such a speed that it cannot come to a complete stop at the end of the current movement, there is a minimum movement length that will allow the machine to keep up a requested feed rate with a given acceleration setting.The acceleration and deceleration phase each use half the INI file MAX_ACCELERATION. In a blend that is an exact reversal, this causes the total axis acceleration to equal the INI file MAX_ACCELERATION. In other cases, the actual machine acceleration is somewhat less than the INI file acceleration.To keep up the feed rate, the move must be longer than the distance it takes to accelerate from 0 to the desired feed rate and then stop again. Using A as 1/2 the INI file MAX_ACCELERATION and F as the feed rate in units per second, the acceleration time is ta = F/A and the acceleration distance is da = F*ta/2. The deceleration time and distance are the same, making the critical distance d = da + dd = 2 * da = F2/A.For example, for a feed rate of 1 inch per second and an acceleration of 10 inches/sec2, the critical distance is 12/10 = 1/10 = 0.1 inches.
For a feed rate of 0.5 inch per second, the critical distance is 52/100 = 25/100 = 0.025 inches.
I interpret this as:
Suppose I have some CAM software that outputs arcs or (bezier) curves as a whole bunch of short linear moves, then LinuxCNC would not be able to keep up it's feedrate because it is not able to look ahead in the buffer, does not not know the vectors are nearly colinear and therefore it does not go faster then it would be able to stop at each coordinate point in the curve.
Chapter 2.10. [TRAJ] Section seems to suggest otherwise. I references to blending corners and an example of looking 50 vectors ahead to deterimine speed and when to decelerate.
This chapter 1.4 also contradicts with chapter 1.3 and G64 with the "Blending modes" just above it. Is 1.4 still relevant, or is it some old part of the manual that did not get revised properly?
Please Log in or Create an account to join the conversation.
For coordinated moves in X,Y and/or Z there is advanced lookahead but for a coordinated move that includes any other axis letter ie (A,B,C,U,V and/or W) the trajectory planner falls back to one line look ahead where short segments can be problematic.
Please Log in or Create an account to join the conversation.
- User_paulvdh_42
- Offline
- New Member
-
- Posts: 4
- Thank you received: 0
For my first machine it would not be very important. It probably becomes a bigger issue if you want to do text or image engraving with a 4th axis.
I also have vague plans to build a 6 axis articulated robot arm later and was hoping I could use LinuxCNC as the control system. Using the same system for both CNC and robot control would be a mayor advantage for me. This would not be a big limitation for big moves (such as pick and place with blending curves) but it would be a problem for accurate path following. I once worked for a company that designed car factories, and one of the applications for robots is curve following with a defined speed. For example for applying expanding foam to form a seal around the perimeter of car doors.
I also suspect this limitation becomes a mayor issue if you want to do 5 axis simultaneous machining. I currently have no ambitions in that direction though.
Please Log in or Create an account to join the conversation.
Less so than you might think. LinuxCNC had only the 1-move-lookahead TP for decades and few people noticed a problem.I also suspect this limitation becomes a mayor issue if you want to do 5 axis simultaneous machining. I currently have no ambitions in that direction though.
It started to be an issue mainly on very fast routers and plasma cutters, and when CAM started to be more readily available (and, to an extent, when it started being used by novice CNC-ers who assume that the smallest possible path length mush be highest resolution and therefore the best.
If you work out what the minimum segment length is to fulfil the requirement, it is gnerally pretty short, though this depends in the feed rate and machine acceleration limits.
Under-specifying the acceleration limit in the INI is a common cause of trouble in this regard.
If you remember school physics: v^2 = u^2 - 2as.
Or, the minimum segment length, s is in the order of: s = v^2/2a.
My (slow, old) mill with a 1000rpm spindle runs typically at around 100mm/min and the INI has:
MAX_VELOCITY = 45
MAX_ACCELERATION = 200
These are units of mm and seconds.
So, if I am running at 100mm/_min_ that is 1.7 mm/sec.
So the minimum segment length is 7 _microns_ (or 0.3 thousandths of an inch)
Most commercial metal-working machines will have servos sized to give similar dynamic properties.
But many home-build routers are geared for high speed and low acceleration, and it is there that problems can arise. Especially as woodworking is a lot more sensitive to reductions in feedrate, as it can lead to burning of the wood. It's not ideal on metal, either, but the results are increased cutter wear and not generally visible on the workpiece.
Please Log in or Create an account to join the conversation.
It started to be an issue mainly on very fast routers and plasma cutters, and when CAM started to be more readily available (and, to an extent, when it started being used by novice CNC-ers who assume that the smallest possible path length mush be highest resolution and therefore the best.
Exactly.
Here is a good example of how simply changing the CAM settings may fix slow Gcode execution despite the one line lookahead:
forum.linuxcnc.org/38-general-linuxcnc-q...ving-too-slow#306462
Please Log in or Create an account to join the conversation.