Jerky adaptive re-positioning moves

[chris]

Hello All,

I've tried a ton of recommended settings for tolerance and smoothing but none seem to fix this issue i've been having with my adaptive strategy re-positioning moves.  the actual cutting moves are great and very smooth, but the re-position moves seem to always have small straight line segments that cause the machine to be jerky.

I am using linuxcnc with G64 path blending set also with the tolerance in fusion, i've tried the machine tolerance value at many settings and non seem to fix this and was hoping someone could tell me if there is a setting to have the re-position moves turned into tangent arcs rather than line segments.  I don't see any reason why these below could not be made into straight lines with tangent arcs in the tool path planner?  but i also don't see any settings to address it.  any help is greatly appreciated!  currently for best results i'm using tolerance at 0.0005 and smoothing at 0.001. i am attaching a video that should start at the correct position to show the stuttering in these moves that actually make the machine shake. and a points image showing the offending moves.

Thanks in advance for any thoughts on how to address!

Chris

video should start at 3:10 mark listen and watch the doors on the re-positioning adaptive moves...

https://youtu.be/LDMKMx2aO5E?t=190

[chris]

No bod else experiencing this or have an idea for a solution?

[DarthBane55]

I did experience similar with one of our machines, and what helps a long way is to turn off smoothing completely.  Some controllers have a hard time dealing with the constant change between G1-G2-G3 with very small moves.  If you remove smoothing, it will always be G1 and the machine reacts much better.  We have 5-axis high end machines that have no problem with smoothing, but our older 4 axis machine can't hack it at all (smoothing).  Try this and see it if helps for your machine.

[seth.madore]

As far as I know, Smoothing isn't applied to transitional moves. You are using the Linux post, is that due to your control; what is your control by the way?

Can you share a file that is doing this? I'd like to compare code output between a few different posts to see if output is different enough to investigate further.

All that said, this sounds a LOT like servo tuning at the machine side of things. There are gain, lag, dampening, velocity curves  and other settings that change how the servos will move from one block of code to the next. When you hear of Haas users talk of G187, or Fanuc users talk of G05.1 Q1/3, these are machine settings that modify all the settings mentioned above into a "preset" that will make certain code processing go easier on machines.

But yeah, I'd be terrified to run code with how your machine is reacting.

Well, at least, Adaptive code...

[chris]

Seth,

the machine moves beautifully when in the actual adaptive path, it is only at the outside corner repositioning moves it seems to get unhappy.  i think it is a combination of a high non engagement feed rate and a bunch of line segments.  I am sure i could turn down the non engagement feedrate anbd it would be fine, but then you lose efficiency everywhere else.. so its kind of an issue there as well fixing one thing creates another.

i attached the offending file above in the first post. .f3d, please let me know if you need anything else.

i have also recently started using the upgraded post that send linuxcnc a G64 P(tolerance value) that comes from the tolerance line edit of fusion 360.  but it does it with both the original and this one.  

should be noted that while there are no small line segments the machine moves flawlessly and handles accel decel arcs, and straight lines perfectly... just when the re-positioning moves throw it tiny line segments, it stutters.  the control i'm using "linuxcnc and the pc tested spectacularly well for latency and it is certainly not a block processing road block.  I am also running Mesa hardware that is an external motion controller.  just seems that a high speed tool path wouldn't limit the high speed tangent arcs to the engagement portion but would have them also in the re-positioning code to keep things super smooth.   most of those moves look like it would actually be shorter code to have two line segments connected by tangent arc verse several linear moves.  but I am of course no kinematics guru so.. i'm no authority on the subject..lol

offending file posted below!

thank you very much for your help on this!

Chris

[chris]

Probe Basic is a user interface i designed and made for linuxcnc to help usher in a new era for the platform.  it was built with the help of hazzy and turboss and on the qtpyvcp ui editor.  very cool project, and getting cooler every week or so with new features.  we really want to add some stuff that links fusion to it a little better and easier for tool table data transfer etc.. but that is another topic..lol for now i just hope to find what i'm doing wrong with this stuttering... as you said it is quite terrifying when it happens and im sure it is not kind to linear motion components.

thanks,

Chris

[seth.madore]

I don't have an immediate software based solution for you, but I will offer up my own personal advice;

1) Your non-engagement feet rate is very high. If your machine doesn't have a built in "filter" to smooth out these motions, it's just not going to end well. Try cutting the feedrate in half.  I find that on my Kitty and Mori, anything over 300 ipm WITHOUT control based smoothing turned on results in some serious sheet metal shaking.

2) Reduce your Max Stay Down settings. 50% is usually where I run, but you may find that rapids take less time than feeding over

[chris]

yup thats what i have already done to try and alleviate the issue currently.

when you say a filter, can you expand on that?  do you mean such as G64 path blending? which in linuxcnc allows the machine to move an amount off the planned trajectory, im guessing this is like the tolerance or smoothing setting inside fusion.   below is the definition of it, i am not surently using a Q value but perhaps i chould be?

http://linuxcnc.org/docs/devel/html/user/user-concepts.html#_programming_the_planner

• P - motion blending tolerance

• Q - naive cam tolerance

• G64 - best possible speed.

• G64 P- <Q- > blending with tolerance.

• G64 - without P means to keep the best speed possible, no matter how far away from the programmed point you end up.

• G64 P- Q- - is a way to fine tune your system for best compromise between speed and accuracy. The P- tolerance means that the actual path will be no more than P- away from the programmed endpoint. The velocity will be reduced if needed to maintain the path. In addition, when you activate G64 P- Q- it turns on the naive cam detector; when there are a series of linear XYZ feed moves at the same feed rate that are less than Q- away from being collinear, they are collapsed into a single linear move. On G2/G3 moves in the G17 (XY) plane when the maximum deviation of an arc from a straight line is less than the G64 P- 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. It is OK to program for the mode that is already active. See also the Trajectory Control Section for more information on these modes. If Q is not specified then it will have the same behavior as before and use the value of P-.

[Laurens-3DTechDraw]

From what I know what you see is due to the way stay down linking is calculated. This means lines and arcs don't necessarily have to be tangential and usually that causes controls to stutter. Okuma's control on our Multus U3000 for example hates an arc that's not tangential to the move it did before.  So while different tolerancing helps to me the biggest advantage has come from increasing the distance to stay clear of the part/stock. I've increased that massively and it usually means moves are bigger which is easier for a control to do, but also they are smoother due to the way you are tricking the algorithm a bit.

[chris]

@seth.madore this is the original thread and I've still not found a good resolution,  I know there has to be one as the machine is silky smooth in every other situation except the adaptive repositioning and only in certain locations. 

[Anonymous]

@Laurens-3DTechDraw What setting did you change to make the distance bigger?