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
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.
>>>> 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.
Chris L
Mactec54
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
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)
Chris L
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.
Jim Dawson
Sandy, Oregon, USA
[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.
Well that was about 60 years ago.
I need to do some studying.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
Sandy, Oregon, USA
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
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.
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.
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.
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
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
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...
hy guys nice discusion, i read with oau feeling, and from time to time i will share what i think
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
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 " )and who's Cam program is involved to allow it to happen without direct code hand editing ?
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
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 ?
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 shiftWorking internally using floating point math but outputting integer (encoder) values that the controller can understand was a bit of a challenge.
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
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
yes pete, feedback dataIts 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
you nailed it
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
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg