Jerk Control in machines

[ihavenofish]

>>>> on the fly acceleration : citizen, okuma

Interesting ! How is it implemented ? Do they have defined G/M codes for it and who's Cam program is involved to allow it to happen without direct code hand editing ?

The okuma seems to be a blanket override. Can't find much on it.

[mountaindew]

So your machine will be shaking in motion reversal due to lack of jerk control.
BUT you can take care of a lot of the harsh motion with better paths. I do not know what sprutcam's features are, but in Fusion 360 you would use adaptive clearing paths, and filleting of sharp corners. This will take care of 80% of the harsh motion. The rest you kinda have to live with, but it hopefully wont be very bad.

Sprutcam has a number of ways to perform high speed machining. They can be use on router format projects. Most strategies involve path loops as you describe above. Those often work great on mills and smooth out the operation path changes.
The problem with routers is your often using sheet goods with parts nested Close together with little or no room for fileted or looping direction changes. I could have used the looping or adaptive abilities to smooth out this particular project because it was made from sized stock with plenty of room on all sides. The pockets could also have been smoothed out using same. It does add a lot more tool paths and air cutting during direction changes. As I mentioned above I was kind of wanting the ability to just slow down by % before a direction change. Just a more simple to use with simple tool paths and not all the crazy looping tool paths. I have seen routers cutting at 200 ipm down a 8ft long sheet then slow down and change directions and then ramp back up for the next long cut. Not clear if it was the machine or cam in control of this. I assumed it was the cam. But reading peteeng and mactecs many posts on this forum has made me wonder what it takes

Hi MDew - All the systems you use are good quality commercial systems and should work well. My first impression is to check the machine mechanics. Second is to send a sample code to strutcam and let them comment. Does the glitch show up in a toolpath simulation?

Ironcad - solid commercial CAD. I assume you use a step file to transfer to sprutcam. This should be a high quality transfer of geometry. I have had issues with the export displacing objects but this is immediately apparent.
Sprutcam - I've spoken to the local agent today about the robot OLP. The 3 axis mill program is high quality so should behave properly. I suspect its a machine looseness. But check with Sprut about the glitch
Pathpilot - again solid commercial MC so unless set up totally wrong should be fine
Tormach router - solid commercial machine - check mechanicals

thanks for contributing - Peter

It is a good combo of software for cad cam and control. The very reason I use it. I have a mill, router and lathe that all use the same cam and control software. They all share a similar work flow. I cant say it is super easy to do what I show above. It is for me but I have used the same software for many years. It helps big time.
I read and look at what you and others are up to and always find something to learn and apply. This topic being one of the things I see and never really figured out very good consistent methods to control it. In fact its very new to me because until I started using a CNC router I never run programs at 180ipm. My mill has rapids at half that speed and cuts at 40 ipm max most the time. So machine jerking around has never been a problem I had to deal with.
Anyway I must thank everyone on these forums. I learn so much from the people on this site. As mostly a machine user I find it still helps to read and understand what the builders are doing and how they attack their machine designs.

[ihavenofish]

Sprutcam has a number of ways to perform high speed machining. They can be use on router format projects. Most strategies involve path loops as you describe above. Those often work great on mills and smooth out the operation path changes.
The problem with routers is your often using sheet goods with parts nested Close together with little or no room for fileted or looping direction changes. I could have used the looping or adaptive abilities to smooth out this particular project because it was made from sized stock with plenty of room on all sides. The pockets could also have been smoothed out using same. It does add a lot more tool paths and air cutting during direction changes. As I mentioned above I was kind of wanting the ability to just slow down by % before a direction change. Just a more simple to use with simple tool paths and not all the crazy looping tool paths.
.

Fusion 360 has a function to slow down in sharp corners. This will help a little, but the problem with the "bang" in the corner is actually acceleration, not speed. This is why we want/need jerk control on a machine that accelerates fast.

[datac]

>>>> My DDSC v3.1 allows different acceleration for jogging, but nothing more than that.

Same/Similar here on my old V4 Flashcut. Rapid Moves and Jogging are connected, Feedrate has its own settings.

>>>> They are making progress on the linuxcnc forum for jerk control.

Interesting. I can't wait to retire and play with some of where they (LinuxCNC) are currently. I have played with it a few times on spare machines I've had around here, but always jumped back to familiar things simply because of available time to get the job done. I really had no complaints other than familiarity. I did get involved in their forum once, where I was shocked that they did not include input line "Debounce" options right their in GUI setup windows. Too, I uncovered some sort of rounding error/setting they had with arcs.... again, no GUI adjustment for "arc Radius Tolerance" , to which they had fixed and released lickity split!

If I recall, it was really the inexpensive world of Arduino and GRBL that were first to pull off enhanced Jerk methods in I guess what we would refer to as "hobby based" controls.

[mactec54]

>>>adaptive clearing paths, and filleting of sharp corners. This will take care of 80% of the harsh motion.

While I have not yet found time or developed enough interest in using adaptive paths, it is very clear they make a difference. It's beyond onvious just watching videos of those running them. To me, there is still a feature missing.

While I have seen many discussions like this, what I have never seen is discussion regarding a potential need for both the CAM and Control side to allow for "Acceleration Changes on the fly" defined in the G-Code itself. I've often struggled with controlling breakage of very small tooling, where just inserting (manually) a lower feed rate where the tool will approach such a particular spot, leaves much to be desired.

Now, I know that my old Flashcut control (V4... cant afford the new stuff) does allow me to manually do a feed hold, change any axis' acceleration ramp and restart the tool path with those new changes. Not sure how many other controls allow that. What I always felt I needed access to, was to be able during the cad/cam stage, insert locations where we desire an axis acceleration change not much unlike the way we insert an automatically generated "lead-In" or "bridge". Obviously it would require an addition to the traditional world of G&M code, but hey, that never bothered anyone during the development years of hobby CNC controls.

Yes, there would be a lot of different ways to do this, but both Cam and Control have to be on the same page. The simplest would be to cut ALL acceleration/ramping by a user setting percentage. The next level might be similar to how we might indicate "G28 Z0" to only send the Z axis to zero, perhaps a acceleration option for a single axis would be addressed like Gxx Z(percentage).

If I was not so busy these days, I'd be calling Flashcut about this. They have always allowed a list of variables and operators in the G-Code to provide other functions during code execution, but I never recalled any such regarding changes to Accelerations or Ramping. Even if they did, it would be something you would have to manually insert because no ones Cam would have a clue it exists.

So, this is where it might require it begin even in Cad, but certainly in Cam, and finally a CNC control that understands it. I do know Flashcut did create their own complete from scratch Cad > Cam > Control environment when they took a heavy aim at the Plasma/Laser world. That type of environment might be the ONLY way to actually get this type of option, and for all I know currently, maybe they already have it ?

Fun discussion !

Eding CNC is a Hobby / commercial Control you can setup a percentage for direction change like arc's, right on the main Auto screen
It reduces feed for arcs. This is a parameter that influences the Look
Ahead Feed (LAF).

A G28 is not a good move for a Z0 move

[ihavenofish]

. Too, I uncovered some sort of rounding error/setting they had with arcs.... again, no GUI adjustment for "arc Radius Tolerance" , to which they had fixed and released lickity split!

G64 has a P setting for deviation. It is in the manual, but definitely not very clear to many users though. Before V2.5 it was pretty terrible though full stop. After 2.5 it is vastly improved, but still only looks ahead 1 line. The next iteration it seems will hopefully elevate it to "industrial" level of motion. I just hope that's in "months" and not decades :P

[datac]

Eding CNC is a Hobby / commercial Control you can setup a percentage for direction change like arc's, right on the main Auto screen
It reduces feed for arcs. This is a parameter that influences the Look
Ahead Feed (LAF).

A G28 is not a good move for a Z0 move

Eding's development has always intrigued me. I wish we could read more about it though as because it is more rare in the states, seems we have little discussion about it.

The settings you mention we've had pretty much since the beginning of Flashcut.

Not sure why G28 Z0 is "not a good move"...... G28 just tells all axis (defined in settings) to move to machine zero. Adding the "Z" just isolates the axis. Oh... maybe your saying the "0" is not necessary.. which I agree (I don't use G28 Z in particular.. was only attempting to show how an accel option might be applied inside a G-code file)

[Jim Dawson]

Hi DK - I don't know that's one of the secrets on CNC. See image attached I did a quick search.. Someone out there may know how an arc is discretised? Its a parameter in the line, number of segments must have a default value as well. See digging helps the learning........

As some of you may know I wrote (have been writing) my own CNC operating software, starting about 10 years ago. Early on I recognized that a corner slow down was needed. The first iterations were crude at best and then it evolved over time. I had never heard the term ''jerk'' until the last couple of years or so. But I have actually been implementing this for a long time. I now use a horribly complex algorithm that takes into account arc radius, assigned velocity, and the machine. I have a parameter in my setup that is a single value that sets the base adjustment, this is machine specific and is derived from physical testing. In addition to this I have a slider control on my screen for ''Corner Slowdown'' , this is adjustable on the fly while running a job. The algorithm is only applied on G2 and G3 moves. Generated arc segment lengths can be as small as 1 micron (the limit of my machine resolution), and in some cases 0 for a given axis. Each arc segment has a start and end vector velocity as well as variable vector acceleration.

One of the biggest problems was correcting rounding errors while generating the arc segments. Working internally using floating point math but outputting integer (encoder) values that the controller can understand was a bit of a challenge. You need to create the ideal tool path and then correct any deviation from that, on the fly, while generating the output motion commands. This is especially crazy when generating a 3D spiral tool path. It is assumed that the machine will follow the commanded path so I'm not making any adjustments when actually running, I have found that this works well for my equipment. Maybe if I were doing work for NASA I would need to look closer at what the machine is actually doing and use that feedback to make finer adjustments on the fly.

I use Fusion 360 and it has Feed Optimization parameters that are very helpful in some instances. I'm sure that other CAM software has this feature also.

[ihavenofish]

[QUOTE=Jim Dawson;2504798] I had never heard the term ''jerk'' until the last couple of years or so. {/quote}

Someone skipped their grade 7 math class... :P
Yeah, the actual word jerk I never remember in math class although it has apparently been called that all along. There's probably names for 4th and 5th order motion that I have never heard.

But you are conflating as many others here are Jerk and path smoothing.

It is important to keep the concepts separate or people will not understand them, and how they relate, and how they DON'T relate. We basically have a thread here on jerk control and almost every post is about path smoothing.

[Jim Dawson]

Someone skipped their grade 7 math class... :P
Yeah, the actual word jerk I never remember in math class although it has apparently been called that all along. There's probably names for 4th and 5th order motion that I have never heard.

Well that was about 60 years ago.

But you are conflating as many others here are Jerk and path smoothing.

It is important to keep the concepts separate or people will not understand them, and how they relate, and how they DON'T relate. We basically have a thread here on jerk control and almost every post is about path smoothing.

I need to do some studying.

[peteeng]

Thanks Mactec - I read the FAQ and it seems volumill runs at 3x the toolmakers recommended chip thickness. Thats deep. They describe it as constant tangential cutting and smooth paths. This means the code is splines and it calculates the correct path offset/step over from last pass and accounts for the path curvature to maintain a constant chip thickness engagement. Conventional step overs don't account for this they just step a constant distance which means the chip thickness varies around corners & curves. This variability in tool load can induce vibration with HSM. So we now have an extra piece of software in the chain... Peter

CAD / rough CAM (HSM or UHSM) / finish CAM / machine controller / motors

[ihavenofish]

Thanks Mactec - I read the FAQ and it seems volumill runs at 3x the toolmakers recommended chip thickness. Thats deep. They describe it as constant tangential cutting and smooth paths. This means the code is splines and it calculates the correct path offset/step over from last pass and accounts for the path curvature to maintain a constant chip thickness engagement. Conventional step overs don't account for this they just step a constant distance which means the chip thickness varies around corners & curves. This variability in tool load can induce vibration with HSM. So we now have an extra piece of software in the chain... Peter

Did you also look up the pricing?

Fusion (HSMworks) is free and or cheap. It is also one of the best cam systems. Great combination: cheap and good.

The pricing structure of most other CAM is comedy. A few may be better than fusion at some things, like volumill, but If you can't find the price of their product listed anywhere online.. probably not affordable for hobby users.

[peteeng]

OK position, velocity, acceleration, jerk (or jolt) snap, crackle and pop.... and not interested in price just how its done... Now Jim mentions path smoothing, and this brings me back to thinking about jerk and acceleration. As the Gcode is a string of point to point moves and its not an equation anymore acceleration and jerk can only be calculated via looking ahead and picking some time delta to calculate the V,A and J deltas to get them (ie a numerical calc not the derivative) OR the system interpolates the code into a new polynomial and calculates all the bits from that then smooths, then segments it back to gcode (Mactec mentioned this before) . This also means the acceleration and jerk calculated is just the along the path acceleration not the full acceleration including centripedal acceleration as the code does not know the curvature of the path. The curvature accel could be much greater then the path accel so that could be one reason these things don't work well on tight corners. Anyone know about this? Peter

for the readers
centripedal acceleration is the accel created when things go around corners. Commonly called centrifugal force. Its vel squared/ radius. This has to be vector added to the path acceleration to get the total acceleration. If the path is straight then there is no centripetal accel. In roughing the aim is to use the biggest radius possible to minimise accels. Jerk is a function of the smoothness of the path and the total acceleration at the position considered.

[ihavenofish]

G0 X10 Y5 Z1

End program.

THAT move is one of the most critical to need jerk control. There are no curves, corners, no arcs, no look ahead involved. Just some simple math.

Path smoothing is handled entirely separately by the control.

[mactec54]

G0 X10 Y5 Z1

End program.

THAT move is one of the most critical to need jerk control. There are no curves, corners, no arcs, no look ahead involved. Just some simple math.

Path smoothing is handled entirely separately by the control.

That novice program example is as crude as it gets.

Does not have to be the control at all, it can be done in the servo drive

[mactec54]

OK position, velocity, acceleration, jerk (or jolt) snap, crackle and pop.... and not interested in price just how its done... Now Jim mentions path smoothing, and this brings me back to thinking about jerk and acceleration. As the Gcode is a string of point to point moves and its not an equation anymore acceleration and jerk can only be calculated via looking ahead and picking some time delta to calculate the V,A and J deltas to get them (ie a numerical calc not the derivative) OR the system interpolates the code into a new polynomial and calculates all the bits from that then smooths, then segments it back to gcode (Mactec mentioned this before) . This also means the acceleration and jerk calculated is just the along the path acceleration not the full acceleration including centripedal acceleration as the code does not know the curvature of the path. The curvature accel could be much greater then the path accel so that could be one reason these things don't work well on tight corners. Anyone know about this? Peter

for the readers
centripedal acceleration is the accel created when things go around corners. Commonly called centrifugal force. Its vel squared/ radius. This has to be vector added to the path acceleration to get the total acceleration. If the path is straight then there is no centripetal accel. In roughing the aim is to use the biggest radius possible to minimise accels. Jerk is a function of the smoothness of the path and the total acceleration at the position considered.

This is how it can be done also with the DMM Servo Drives, this comes standard with all their Servo Drives, this takes care of most Jerk motion problems, so anything in software is a Plus

Adaptive Control
To simplify tuning while still allowing highest versatility and control over servo behavior, we have developed Adaptive Tuning technology, meaning relative to the inertia load, the servo adapts a wide margin of permissible parameters that will ensure stable control. This allows to easily select the settings for smoothest motion, and fastest response.

The margin of stability being adaptive is critical for many applications. For example, in machine tool, the dynamic load inertia can drastically change. The load inertia ratio is different at acceleration/deceleration, constant traverse and workpiece processing. The same is true for robotic applications. By maintaining a wide region of stability, the DMM adaptive tuning provides seamless performance transition between these events. Even with the same parameter settings, as the load inertia ratio change, the servo is still well within the stable region.

Second generation tuning algorithm further improves smoothing with wider frequency range leading to wider domain of inertia load capability.

2. Features
Optimal servo control topology based on the Encoder Feedback and Position Command. Ensures the closed-loop servo has maximum stability margin
Smallest number of adjustable servo parameters. Very easy to tune servo for different load inertia and required servo stiffness
The closed-loop servo has more performance capability over larger inertia load variance

[mactec54]

Did you also look up the pricing?

Fusion (HSMworks) is free and or cheap. It is also one of the best cam systems. Great combination: cheap and good.

The pricing structure of most other CAM is comedy. A few may be better than fusion at some things, like volumill, but If you can't find the price of their product listed anywhere online.. probably not affordable for hobby users.

Its free for 12months and most good Cam programs have it integrated, so for those users that have it integrated there is no extra cost, it just becomes another tool you can choose it you want to use it.

[peteeng]

Hi Mactec - yes a lot of good words but what is adaptive control doing? Is it numerically calculating accel and jerk in look ahead then adapting? ie it is numercially analysing the gcode stream and calculating these things ahead then tuning speed and or accel to suit? or is it interpolating gcode to a curve then analysing that and then re segmenting to new gcode? Its clearly picking up vel and accel; from the encoder. The cam program is only involved in geometry as it does not know what the inertial conditions are. So its only in real time with feedback from the encoder can a system calculate the actual vel and accels and jerk or inferred jerk. If done in real time it has to be a fast system....Peter

[peteeng]

Hi All- I looked at the DMM site and they publish this. Needs a bit of digesting. Then theres the H infinity method. Peter

https://en.wikipedia.org/wiki/H-infi...control_theory

https://www.dmm-tech.com/technology/...ptivetune.html

https://en.wikipedia.org/wiki/Pseudo...ptimal_control

edit- Hi all - is there a way to actively control feed speed in UCCNC or other controllers? My thought is to put an encoder onto a stepper or other motor and use a PID to control accel via speed back to the controller? That sounds doable? That's a simple version of what DMM do...

[deadlykitten]

hy guys nice discusion, i read with oau feeling, and from time to time i will share what i think

Interesting ! How is it implemented ? Do they have defined G/M codes for it

hy datac M code for each axis, or parameters targeting values or sets; off course, is not as much freedom as implementing whatever function you wish, but what can be done is pretty relevant :
... change :
...... duration for actual function ( thus shorter or faster time, or, if you wish, scaling horizontally )
...... final speed for rapids ( if you wish, scaling vertically )
... parameters for shape, acceleration, or modes intensity to balance between productivity and quality ( from maxed acceleration to low vibration ); in max mode, machine may move, anchoring and better foundation is recomanded, etc

and who's Cam program is involved to allow it to happen without direct code hand editing ?

okuma is ahead : after decades some okuma functions start to pop up also on other brands, mass reaction is wow, what a new thing, and some cam softwares will catch on to some extent ( something like there is a function inside the cnc, and the cam is like " try this, hope is it ok " )

most cams won't cover special functions : even if a cam would put that special code inside the program, adjusting near the machine may still be required, especialy for some expectations

how same control is on different machines types ( lathes to heavy centers ), and there are differencies even on similar machines ( for example turret setup or mass distribution across a mill table ), and even more there is different mrr on similar machines with identical setups, simply is too much time consuming to make a way to initialize machine particular motion dinamics from a chair in an office

this does not mean that is not possible, because there are cam softwares that take inputs such as max speeds and acceleration, then use them to calculate the toolpath, or make cycle time estimations

if i may say, there is more behind the curtain

Generated arc segment lengths can be as small as 1 micron (the limit of my machine resolution)

hy jim i wondered when will you pop up ? here you are ...

if it maters, okuma has option for 0.1um

segments length increases at higher feeds, but reasonably for most machining aplications, thus a normal usage of the machine won't produce squares

this is machine specific and is derived from physical testing

please, will you develop a bit on this ?

Working internally using floating point math but outputting integer (encoder) values that the controller can understand was a bit of a challenge.

kind of using a grid with holes, like that kids game, when you need to push a square in the square hole; if the grid moves, also hand/math has to shift

if i may, a similar thing apears when you display a circle on the screen: in order to avoid trigering too many pixels, you have to compute a single one, 'that' single one, not 'any' one

the code does not know the curvature of the path. The curvature accel could be much greater then the path accel so that could be one reason these things don't work well on tight corners

hy pete yes, the local g-code, those few code neighbour blocks, can not tell much on the overall picture, that's why most machines are caught unprepared at corners

if i may, the example with rough plunging that i shared a few posts ago, was not about replacing hsm roughing with plunging, but about inserting a plunge section inside a hsm toolpath, right before things get nasty into corners, then continue the hsm it is a mix in the mix

Its clearly picking up vel and accel; from the encoder. The cam program is only involved in geometry as it does not know what the inertial conditions are. So its only in real time with feedback from the encoder can a system calculate the actual vel and accels and jerk or inferred jerk. If done in real time it has to be a fast system

yes pete, feedback data

This is how it can be done also with the DMM Servo Drives ... The closed-loop servo has more performance capability over larger inertia load variance

you nailed it

I have seen routers cutting at 200 ipm down a 8ft long sheet then slow down and change directions and then ramp back up for the next long cut. Not clear if it was the machine or cam in control of this. I assumed it was the cam. But reading peteeng and mactecs many posts on this forum has made me wonder what it takes

hey dew if you can analyze feedback data from your cnc, then you can reach a conclusion faster, otherwise real trials are needed; is better to be calm rested, and have less background noise, thus is harder to target smoothness if you are tired, in a noisy shop

also, is easier to analyze repetitive tasks, and those conclusions should be somehow used for newer scenarios

as macted said at post16, a friend of his did such a thing, and is not hard ... but is needed that map, that breaking function, so to change the program in respect to it, or you could simply generate different breaking methods, then analyze them, and keep the ones you like / kindly