[peteeng]

Hi All - The issue with cnc machine control is that there are three main domains to control. rapids ie no tool load, roughing and finishing. Each domain has a different inertial condition, so you can't use a simple one set up PID to cover all the bases. The h-infinity algorithms use an optimisation map to cover all the bases. Quadrature is a numerical calculation method that uses a few points to calculate the functions vs starting with the continuous function. It is faster to calculate and accurate enough for the CNC application vs creating the continuous curve then differentiating etc then looping back to the velocity. So starting to get a grip on how these guys are doing this... Peter

Engineering jerk for our purposes has no physical symptom or existential affect. Jerk is calculated to establish how smooth the acceleration is and to identify where acceleration peaks occur. Acceleration produces inertial forces on masses (F=ma) and "jerky" motion is created as a function of machine compliance, inertial loads and actual loads (called body loads). These systems smooth the velocity (S-curve) to smooth the accelerations but leave peaks in jerk. But these peaks are much lower then when using a trapezoidal velocity profile.

[peteeng]

system made copy

[mactec54]

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)

Using a G28 requires you to add a G90 to cancel it, either a G0 or a G53 does the same thing without having to cancel either

[mactec54]

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...

It's not as easy as that, first the drive has to digest the information and then that information gets sent from the drive to the control, if the control is closing the loop, Jim is doing what you are suggesting, this is not an ideal way to do this, as many have found out in the past. if this was the the way then all machine manufacturers would be doing it this way, years ago it was done like this, only because they had what is known as dumb servo drives, the old machines where slow and had terrible Jerk

Jerk in general is best controlled at the source not the G-Code, it can help if it has smoother execution like Volumill, the code is only the instruction of what the Motor has to do, machine inertia, and machine rigidity, it all begins with what the servo motor can do, then how the servo Drive can use that information the control is just the instruction and how well it can execute the instruction, at the Hobby level there are very few controls that can use / have a closed loop at the control level, and if they do the setup will take you forever, and after that it won't be any better than what you are currently using

Today Servo Drives are key with having dual feedback capability, many close the loop in the Servo Drive using Encoder and linear Scale feedback from the machine, the Servo Drives become the heart of the machine, from the Drive information if sent to the control, the Control is then checking that the instructed position has been meet.

At the hobby level using steppers and the dumb drives you are never going to achieve jerk free motion, even with adding an encoder like the closed loop systems do, it will still have the same Jerk.

Using a Servo system if the Encoder has a low PPR they will have the same Jerk problem

[shineworld]

Jerk Control must be applied at the interpolation engine level and works on acc/dec of multi-axis interpolation point.
Level of Jerk reduction must be modifialble on GCode, Es, G104 J
so it's possibile to adapt system
from raw and finiture parts: ( https://ibb.co/dmtQ5hh )



In left to middle part of axes velocities and tcp velocity plot, the G104 J100 means: leave all native interpolation Jerk.
In middle to right part of axes velocities and tcp velocity plot the G104 J0 means: reduce interpolation jerk totally.

Red line is TCP resulting velocity.
How you can see the execution time of no-jerked work is more long but accelerations are more smooth.

[mactec54]

Jerk Control must be applied at the interpolation engine level and works on acc/dec of multi-axis interpolation point.
Level of Jerk reduction must be modifialble on GCode, Es, G104 J
so it's possibile to adapt system
from raw and finiture parts: ( https://ibb.co/dmtQ5hh )



In left to middle part of axes velocities and tcp velocity plot, the G104 J100 means: leave all native interpolation Jerk.
In middle to right part of axes velocities and tcp velocity plot the G104 J0 means: reduce interpolation jerk totally.

Red line is TCP resulting velocity.
How you can see the execution time of no-jerked work is more long but accelerations are more smooth.

SoftServos control does this without any code required their patented1000 cycle three–dimensional dynamic look-ahead contour
control (3D-DLACC) with pre-interpolation acceleration for high-speed, high-precision milling. Feed rate with this control will leave most speechless

TCP is only a small part of what is required

[peteeng]

Hi Mactec- There is no "engineering jerk free" system. However engineering jerk minimisation is possible. "lay jerky" motion is rough accelerations not necessarily anything to do with engineering jerk. Just want to clarify lay "jerk ie rough motion" verses physics jerk or jolt.

There are two schools of thought it seems a) since the velocity/accel (hence eng jerk) can be calculated by the CAM system and velocity profile are generated by the CAM then the whole thing can be controlled in the code. This presumes the motors and machine can follow the required path and velocity profile independent of the inertial conditions eg volumill b) Since smooth response of the system depends on the inertial conditions then some sort of feedback loop needs to be used. ie place an encoder on the motor (and or linear scales on the axes) measure its actual position, velocity and accel compared to the programmed vel/accel and then use that feedback to correct the response eg DMM C) do both? Depends which side of the commercial border you are on the software side or the machine side. Peter

other school is like movensys - They take the g code stream and look ahead in the code. They calculate the vel/accel/jerk and correct the velocity/acceleration profiles, then change the gcode stream to suit. This can be vel/accel profiles and path smoothing.... I'd put them in the motor camp....

Mactec - by "Jerk" do you mean rough motion or "engineering jerk"?

[PCW_MESA]

Hi Mactec- There is no "engineering jerk free" system. However engineering jerk minimisation is possible. "lay jerky" motion is rough accelerations not necessarily anything to do with engineering jerk. Just want to clarify lay "jerk ie rough motion" verses physics jerk.

There are two schools of thought it seems a) since the velocity/accel (hence eng jerk) can be calculated by the CAM system and velocity profile are generated by the CAM then the whole thing can be controlled in the code. This presumes the motors and machine can follow the required path and velocity profile independent of the inertial conditions eg volumill b) Since smooth response of the system depends on the inertial conditions then some sort of feedback loop needs to be used. ie place an encoder on the motor measure its actual velocity and accel compared to the programmed vel/accel and then use that feedback to correct the response eg DMM C) do both? Depends which side of the commercial border you are on the software side or the machine side. Peter

I think its valuable to divide jerk control into tangential jerk and centripetal jerk:

Tangential jerk (along the tool path) is full controllable by the machine.

Centripetal jerk is totally controlled by CAM if you are doing constant tool speed machining (which is usually desirable for accuracy).

[peteeng]

Hi PCW - Thks for chipping in. Jerk control is probably said wrong. We are not "controlling" jerk as eng jerk is the result or symptom of rough accelerations. We want to smooth eng jerk via the path (smoothness & radius) or by smoothing accelerations via velocity profile smoothing. We minimise eng jerk for the following:
1) rapids - we want very fast AtoB motion without overshooting or exciting the machine ie minimise settling time
2) Roughing - don't need accuracy but do need to maximise MRR. Heavy MRR will lead to vibration so smoothing jerk minimises delta Accel which minimises inertial forces which means better cutting (generally speaking)
3) finishing - we need position accuracy but at max speed so path accuracy and smooth paths require smooth accels. Constant velocity machining means we will have pathway accels due to inflections in path eg lines to rads

These 3 domains have different inertial conditions so optimisation of motion damping etc is not an easy process. Can be done in toolpathing CAM, can be done via motion feedback and combos of these. Its a big maths mashup... Peter

Rosetta cnc looks interesting https://www.rosettacnc.com/en/

[ihavenofish]

It is jerk "control" though. You cant's just keep changing established terminology, you'll never understand anything and even if you do, no one will understand you. As I've said numerous time now, jerk is just 3rd order motion, nothing more, nothing less.

Position control, controls the position.
Velocity control, controls velocity.
Acceleration control, controls acceleration.
And yes, Jerk control controls jerk.

HOW you control those things varies of course. Most jerk control is just a constant from what I can see (for the the tangential type as PCW says). Some do claim 4th and 5th order (which would make jerk itself an S curve).

Centripetal jerk is the domain of constant velocity control modes done in the control, which as stated is now aided by clever CAM. I Consider a separate topic entirely myself.

[peteeng]

Hi IHNF - Show me a system that controls jerk directly. I have not changed the meaning of any words you seem to be the only one that's debating the terminology. I'm interested in how systems are creating smooth motion. If its just like acceleration and velocity with a capped figure input this is a poor strategy as capping eng jerk will cap accels and velocities rather then smooth them. If Shineworld is an algoritm developer he maybe able to explain better as the Rosetta software does a good job of smoothing eng jerk from his recent post. Peter

[ihavenofish]

If its just like acceleration and velocity with a capped figure input this is a poor strategy as capping jerk will cap accels and velocities rather then smooth them. Peter

It Isn't capped, its a a constant, the same way acceleration is a constant in a 2nd order motion system like linuxcnc / mach. It is a constant that defines the rate acceleration changes. The units are M/s/s/s.

If my machine is set to 9.81m/s/s acceleration, a jerk constant will dictate how fast it "jerks" to 9.81m/s/s from 0. This constant might for example be 1m/s/s/s which means it can increase acceleration at a rate of 1m/s/s every second, taking 9.81 seconds to reach full acceleration (obviously comically slow in this example).

If it makes it easier you can think acceleration as net force applied. 2nd order acceleration is placing a 10kg sack of flour on a scale. 3rd order is gently easing the sack of flour onto the scale.

Show me a system that controls jerk directly

Someone just showed you one above including graphs of how it behaves.
Virtually EVERY industrial control for the last 40 years controls "tangential" jerk. Siemens, fanuc, brother, heidenhain, delta, lnc, szgh, beckhoff, yasnac. All of them.

Here is a screen cap of yaskawas sigma software modelling 3rd order jerk to calculate servo torque. Note the jerk time constant in the lower left. in this case, they describe it as a duration, instead of a rate, but the resulting jerk profile shows the rate.

Attachment 478782

.

[ihavenofish]

Here is a brief description of siemens jerk control on all of their controls. They call it jerk limiting. Same thing, it is controlling jerk. It is enabled with the "soft" command, and disabled with "brisk" per program. It is one that also works in conjunction with g64 constant velocity paths.

https://support.industry.siemens.com...20715&lc=en-KR

[deadlykitten]

since the velocity/accel (hence eng jerk) can be calculated by the CAM system and velocity profile are generated by the CAM then the whole thing can be controlled in the code. This presumes the motors and machine can follow the required path and velocity profile independent of the inertial conditions eg volumill

hy peteeng my sugestion is to focus 1st on mcs, and leave cam system where it is

even if a cam takes as input some speed, acc, in order to do whatever with it ( like smoothing and cycle estimation ), most results are bull***t

cam is extensions, is not critical; is not like take this toolpath, it will work; no, is like it should work if you don't push the machine too much

my dear petteng, your thinking is ok, thus like tring to smooth things out as much as possible before creating the g-code, but truth is that actual stage of things is not like that, otherwise there wouldn't be so much complains about shaking/screaming machines

smoothnes is required to push machines, but achieving that top smoothness is not because of cam software

then some sort of feedback loop needs to be used

the feedback loop... this is it

C) do both?

yes, but let's leave this a bit for latter, to smooth out waters at actual discusion, otherwise it won't fit in

please, i sugest this, because it requires a perspective shift with 180 degrees : you see, most cam are extensions, simply doing something and what you see is what you get, but there are things really tailored to an mcs

Hi All - The issue with cnc machine control is that there are three main domains to control. rapids ie no tool load, roughing and finishing.

1) rapids - we want very fast AtoB motion without overshooting or exciting the machine ie minimise settling time
2) Roughing - don't need accuracy but do need to maximise MRR. Heavy MRR will lead to vibration so smoothing jerk minimises delta Accel which minimises inertial forces which means better cutting (generally speaking)
3) finishing - we need position accuracy but at max speed so path accuracy and smooth paths require smooth accels. Constant velocity machining means we will have pathway accels due to inflections in path eg lines to rads

close, but no cigar ... machine has not clue if it sees finish, roughing, inertia or a crash

yes, those are different scenarios, but also different scenarios are these :
... trapez vs S motions
... read ahead of 4 lines or 50 lines
... diff 0 or diff 1
this enumaration above has things in common with your enumaration ( rapid rough finish )

again, here we are, discussing the mcs / kindly

[deadlykitten]

measure its actual position, velocity and accel compared to the programmed vel/accel and then use that feedback to correct the response

me again

as you allready know i supose, terms for comparison is not direct g-code data, but planed toolpath, thus estimation/proposed data based on g-code

it is correcting the response only if there is still available resource to do so

thus, if i may reformulate, it tryes to correct while still cutting, and maybe will succed ... who knows ?

ps : sorry, i did not mean to say "perspective shift with 180 degrees", but only a bit; please excuse me i did not intend that, and it may sound different when you read it

[peteeng]

Hi DK - All input is appreciated. Some needs more digestion time than others. I see no reason to neglect the CAM system as the path is very important. Volumill as an example produces very smooth toolpaths with maximum curvature and curvature continuity for roughing. Being software people they try to get the best from the CAM side. Hardware people build feedback loops and this is good as well. In the end we need all of it. I have to digest IHNF's stuff before I can comment on that.

IHNF - Your learning to play, that's good. Contributions are better then calling me a silly billy all the time . The comment about someone showing me a controller that controls eng jerk is probably incorrect. The controller is calculating/predicting jerk based on the toolpath/vel/accel not the other way round. The algorithm limits accel which limits jerk. Back calculation from jerk would rarely be done as its too difficult. It may use a forward adaptive or iterative algoritm to achieve the smoother curve. Either way I know there are many systems that do this, trying to understand how/why they do it... Do seimens provide a logic diagram like softservo did? Peter

[deadlykitten]

software people they try to get the best from the CAM side

hey pete yes, of course, they try ... foundation is there from 90s, everything else new is small , integrated in what allready is there

In the end we need all of it

i understand your point of the need of a cam to generate smooth entrance, but, if i may, an okuma machine can behave smooth from whatever rough you put in it

machines got more complex, while cam users simply got less skiled, so someone has to balance ... for example, not all think as you, or others, that wish for silky-smooth, so some cnc can behave almost identical on a g-code generated by a newbie, as on one generated by an expert

digestion time

i don't rush; at work now, having parts with cycle time >1hour, i ll go make a coffe

i really can not provide as much info on some topics as others can / kindly

[dazp1976]

This is the best software that is available, and can be used with some cam systems, some cam systems have this already imbedded with their software https://volumill.com/products/volumill

When something says 'request a quote' it really means 'bend over please mate'.
Even having different licence levels, can't give a set price for a basic user.
Usually a red flag to overpaying for a service.
Get the negotiating head on.

[mactec54]

When something says 'request a quote' it really means 'bend over please mate'.
Even having different licence levels, can't give a set price for a basic user.
Usually a red flag to overpaying for a service.
Get the negotiating head on.

It is already integrated in my Cam software and there is no extra cost, if you have a cam system check with your manufacture if they have an option to have it integrated, I use Gibbs Cam, one of the higher end Cam software packages

[mactec54]

Hi Mactec- There is no "engineering jerk free" system. However engineering jerk minimisation is possible. "lay jerky" motion is rough accelerations not necessarily anything to do with engineering jerk. Just want to clarify lay "jerk ie rough motion" verses physics jerk or jolt.

There are two schools of thought it seems a) since the velocity/accel (hence eng jerk) can be calculated by the CAM system and velocity profile are generated by the CAM then the whole thing can be controlled in the code. This presumes the motors and machine can follow the required path and velocity profile independent of the inertial conditions eg volumill b) Since smooth response of the system depends on the inertial conditions then some sort of feedback loop needs to be used. ie place an encoder on the motor (and or linear scales on the axes) measure its actual position, velocity and accel compared to the programmed vel/accel and then use that feedback to correct the response eg DMM C) do both? Depends which side of the commercial border you are on the software side or the machine side. Peter

other school is like movensys - They take the g code stream and look ahead in the code. They calculate the vel/accel/jerk and correct the velocity/acceleration profiles, then change the gcode stream to suit. This can be vel/accel profiles and path smoothing.... I'd put them in the motor camp....

Mactec - by "Jerk" do you mean rough motion or "engineering jerk"?

It can be a combination of both, what you can see most of is rough machine motion.

Rough machine motion affects the machined part, trying to cut the part faster than what the machine can handle,(but the machine can go faster it says that in the specs) is most of the problems you see, so it does not matter what you do in the software side, if the machine can't handle the programed cut speed and feed, it goes back to the machine, # 1 machine rigidity #2 Motor / Encoder #3 Drives #4 Control #5 Cam in this order.

At the Hobby level of machine building, you see everything from vibrating aluminum frames to concreate, the most successful you see are the solid built machines that run at moderate Speeds and Feeds, you mostly find that the Hobby machines that are built of a solid construction are also using a quality modern servo system.