Coordinated Motion involving rotary axis

More
25 Sep 2015 18:14 #62970 by Rick G
Andy,

With G61 each move appears to accelerates then deaccelerate however maybe not to a complete stop, like you stated exact path.

From linuxcnc.org/docs/html/common/User_Concepts.html

1.3. Programming the Planner

The trajectory control commands are as follows:

G61 - (Exact Path Mode) visits the programmed point exactly, even though that means it might temporarily come to a complete stop in order to change direction to the next programmed point.

G61.1 - (Exact Stop Mode) tells the planner to come to an exact stop at every segment’s end.

G64 - (Blend Without Tolerance Mode) G64 is the default setting when you start LinuxCNC. G64 is just blending and the naive cam detector is not enabled. G64 and G64 P0 tell the planner to sacrifice path following accuracy in order to keep the feed rate up. This is necessary for some types of material or tooling where exact stops are harmful, and can work great as long as the programmer is careful to keep in mind that the tool’s path will be somewhat more curvy than the program specifies. When using G0 (rapid) moves with G64 use caution on clearance moves and allow enough distance to clear obstacles based on the acceleration capabilities of your machine.

G64 P- Q- - (Blend With Tolerance Mode) This enables the naive cam detector and enables blending with a tolerance. If you program G64 P0.05, you tell the planner that you want continuous feed, but at programmed corners you want it to slow down enough so that the tool path can stay within 0.05 user units of the programmed path. The exact amount of slowdown depends on the geometry of the programmed corner and the machine constraints, but the only thing the programmer needs to worry about is the tolerance. This gives the programmer complete control over the path following compromise. The blend tolerance can be changed throughout the program as necessary. Beware that a specification of G64 P0 has the same effect as G64 alone (above), which is necessary for backward compatibility for old G Code programs. See the G64 section of the G code chapter.

Blending without tolerance - The controlled point will touch each specified movement at at least one point. The machine will never move at such a speed that it cannot come to an exact stop at the end of the current movement (or next movement, if you pause when blending has already started). The distance from the end point of the move is as large as it needs to be to keep up the best contouring feed.

Naive Cam Detector - Successive G1 moves that involve only the XYZ axes that deviate less than Q- from a straight line are merged into a single straight line. This merged movement replaces the individual G1 movements for the purposes of blending with tolerance. Between successive movements, the controlled point will pass no more than P- from the actual endpoints of the movements. The controlled point will touch at least one point on each movement. The machine will never move at such a speed that it cannot come to an exact stop at the end of the current movement (or next movement, if you pause when blending has already started) On G2/3 moves in the G17 (XY) plane when the maximum deviation of an arc from a straight line is less than the G64 Q- tolerance the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end). those lines are then subject to the naive cam algorithm for lines. Thus, line-arc, arc-arc, and arc-line cases as well as line-line benefit from the naive cam detector. This improves contouring performance by simplifying the path.


Todd,

That is interesting, So any move beyond a xyz reverts to parabolic blending (1 segment look ahead.)?
As Andy stated any rotary axis move the tolerances of P and Q with G64 would not work properly.
But that still leaves uvw.


Same as setting the
linuxcnc.org/docs/html/config/ini_config.html#sub:TRAJ-section

2.10. [TRAJ] Section
Warning
The new Trajectory Planner (TP) is on by default.
If you have no TP settings in your [TRAJ] section - LinuxCNC defaults to:
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 0
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 100

The [TRAJ] section contains general parameters for the trajectory planning module in motion.

ARC_BLEND_ENABLE = 1 - Turn on new TP. If set to 0 TP uses parabolic blending (1 segment look ahead.) Default value 1.


I wonder if the "old" trajectory planner also did not work with u,v,w

Rick G

Please Log in or Create an account to join the conversation.

More
25 Sep 2015 20:31 #62976 by Todd Zuercher
I don't think the naive cam detection worked with ABCUVW in the old planner either, and the halscope plots for each of the 3 path modes look pretty much the same in 2.61 as it does running 2.7.

For this test file G61 moves without stopping with only XYZ moves, but with any movement in ABCUVW the movement is the same as G61.1 (stopping at each point).
I didn't post pictures of the G61 and G61.1 halscope plots.

Please Log in or Create an account to join the conversation.

More
25 Sep 2015 20:53 #62982 by Todd Zuercher
I believe that with the old trajectory planner the naive cam detection is the difference between G64 moves in only XYZ and moves with ABCUVW. If I turn of the naive cam detector (Q0) then the XYZ plot looks the same as moves with ABCUVW.

Please Log in or Create an account to join the conversation.

More
25 Sep 2015 21:01 - 25 Sep 2015 21:23 #62986 by Todd Zuercher
I think there is a small bug in the new trajectory planner when the naive cam detection is turned off (Q0). Notice how at the end of the move there is a strange blip in the velocity. That blip is not found in the plots I made using 2.6. I also think I've seen it on some plots on other threads where people where having problems with G33 and G33.1.
I'm not familiar with the processes for reporting bugs, are there instructions somewhere?
Last edit: 25 Sep 2015 21:23 by Todd Zuercher.

Please Log in or Create an account to join the conversation.

More
26 Sep 2015 06:26 - 26 Sep 2015 06:34 #63012 by dgarrett
A good way to make a report and not have it lost in
transient conversations is to open a ticket on
sourceforge (you probably need to create a sourceforge
login).

sourceforge.net/p/emc/bugs/?source=navbar

The more information you include, the more likely a
report will be investigated.

For instance, include:
1. system and linuxcnc version info
You can use the output of the command linuxcnc_info
$ linuxcnc_info ;# outfile is /tmp/linuxcnc.info
2. sim configuration (a complete tar file if necessary)
2. example gcode file to demonstrate the issue
3. halscope configuration (use halscope File/Save Configuration
to create a halscope config file)
4. detailed instructions to demonstrate behavior
Last edit: 26 Sep 2015 06:34 by dgarrett. Reason: add url

Please Log in or Create an account to join the conversation.

Time to create page: 0.178 seconds
Powered by Kunena Forum