[ftkalcevic]

With EMC, you have a control that flat knows where the Axes are. If something is lagging, EMC knows not to move any other axis until it is where it should be before the move. Mach can't do this by the very nature of how it makes controls work.

And it is all so nicely integrated in one package. HalScope provides a real time software oscilloscope that allows you to monitor and tune any device.

[BobWarfield]

Lets say the Y axis is holding steady while the X axis is plowing along and starts lagging the pulse stream. It won't be much of a lag or it will fault out, yet there is a lag up to several thousandths. While the X is lagging, Y is ordered to move. Suddenly you are not making parts to print.

So in the case where you were only moving one axis to start with and your tolerance to fault out is outside your print's specs and you had sufficient following error to be outside spec, EMC might do a better job. Also assuming you don't have a piece of hardware like a KFLOP or other motion controller that can do exactly what EMC does there.

I'm not sure how often that case would even come up on most of these machines. Even so, if you're in the middle of coordinated motion, for example, interpolating a circle or even just moving diagonally, this algorithm adds no value. Or, if I have high enough resolution encoders, or if I have set my fault tolerance low enough (in terms of encoder counts), the case described won't happen.

In fact, it would be interesting to calculate exactly how much error you can save here and what sort of print tolerances would be violated given the limitations you have on how fast you can accelerate and decelerate these machines anyway. It mostly cares about making an immediate corner where the acceleration problems are most severe anyway. Can you even accelerate the cutter at right angles fast enough to generate much of an error that falls through these cracks?

Maybe. Sometimes. But a decent CAM program should be generating toolpaths that have arcs in those corners anyway.

It's interesting and useful, but not sure it even starts to be compelling.

Cheers,

BW

[doug6949]

In fact, it would be interesting to calculate exactly how much error you can save here and what sort of print tolerances would be violated given the limitations you have on how fast you can accelerate and decelerate these machines anyway. It mostly cares about making an immediate corner where the acceleration problems are most severe anyway. Can you even accelerate the cutter at right angles fast enough to generate much of an error that falls through these cracks?

All modern industrial controls use look-ahead to account for (v**2)/r and adjust velocities to stay within some preset limit of path deviation. The algorithms consider machine kinematics taken from actual testing. Bridgeport had this as far back as the BOSS-5, a stepper machine.

Some controls take this a step further by using adaptive look-ahead algorithms. Basically, if you know there's a turn coming up you can start your feed-forward before you get to the turn. Thus it is possible to reduce following error to near zero.

A step/dir control such as Mach simply spits out a profile and leaves it up to the drives to follow along. Some do a good job, some don't. At the low end of the cash spectrum I suspect steppers do a better job than servos.

LinuxCNC has velocity feed-forward. I do not know if it has the capacity to adjust velocity from (v**2)/r analysis. It does at least have the HALscope so a builder can readily determine system limitations.

Doug

[chester88]

Linuxcnc has a 100 block lookahead. from the manual:

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

I don't know many details beyond that.

I am curious how Mach sends out commands to say the smooth stepper. Does it just send the Gcode or does it send pulses or something else?
I don't see how one can get functions such as threading or ridged tapping to work if Mach sends pulse commands to the smoothstepper (because of latency).
I assume the smoothstepper (or some other black box) allows threading.
So that would mean that the smooth stepper does the trajectory planning and Mach sends Gcode or some similar high level code to the smoothstepper control box.
Or does it really buffer the pulses and modify them on the fly for realtime changes ( seems unlikely ).
Anybody know?

[TomKerekes]

Linuxcnc has a 100 block lookahead. from the manual:

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

Is this really "trajectory planning look ahead"? This is describing look ahead to find blocks that can be reasonably combined into a single straight line. If the CAD/CAM system that generated the GCode did a good job of creating the necessary GCode blocks in the first place there will be no benefit. If the Cad/CAM was naive and generated unnecessarily small GCode blocks then there will be a benefit. But in either case the line segments will have a limited length depending on the desired accuracy and curvature of the path. My understanding of the current LinuxCNC Trajectory Planner is that it will never allow a speed higher than what will allow a full stop in the very next line segment.

[ger21]

I am curious how Mach sends out commands to say the smooth stepper. Does it just send the Gcode or does it send pulses or something else?
I don't see how one can get functions such as threading or ridged tapping to work if Mach sends pulse commands to the smoothstepper (because of latency).
I assume the smoothstepper (or some other black box) allows threading.
So that would mean that the smooth stepper does the trajectory planning and Mach sends Gcode or some similar high level code to the smoothstepper control box.
Or does it really buffer the pulses and modify them on the fly for realtime changes ( seems unlikely ).
Anybody know?

I believe that mach3 does the trajectory planning, and sends some type of special commands to the SS, neither g-code nor pulses.
And I think that threading is a special case, where the SS syncs the feedrate to the index signal.

[chester88]

well it is definitely trajectory planning. It makes these decisions as it adds commands to the trajectory planner list.

No with this setting it will not plan on exact stop. again from the manual:

G61 Exact Path Mode

G61.1 Exact Stop Mode

G64 Best Possible Speed

G64 P- (motion blending tolerance) Q- (naive cam tolerance)

G61 visits the programmed point exactly, even though that means temporarily coming to a complete stop.

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.

I should have posted it all. but of course if your interested - read the manual.
If your really interested join the developer maillist or IRC.

[chester88]

I believe that mach3 does the trajectory planning, and sends some type of special commands to the SS, neither g-code nor pulses.
And I think that threading is a special case, where the SS syncs the feedrate to the index signal.

I'm certainly no expert but I can't see how Mach can do trajectory planning while syncing a thread start pulse that it never sees. This implies that the smooth stepper does at least some of the trajectory planning.

Sounds like Mach converts the gcode to an intermediate code (programmers might call it byte code) that describes the basic motion then lets the black box do the trajectory planning.

I have looked at a couple high level motion cards (few years ago) and that was exactly how they worked. Which make sense.

The disadvantages I see is if the planning is done on the card:
-motion features are strongly tied to the Card.
-need more expensive card for fancy features (not a big deal I guess - I don't know what they cost)
-stuck with the driver the manufacturer supplies (unless they give the source - maybe they do)
-if the card breaks and become unavailable your features may change (probably not a problem for hobby machines)
-one relies on the card manufacturer for motion control upgrades or bug fixes, which may make it harder for the high level software (eg Mach) to fix it's bugs.

But it does allow one to use USB

Chris M

[chester88]

I should explain:

When I said a pulse Mach never sees I again assume that smoothstepper doesn't read the pulse send it to the pc then wait for the synced motion commands to come back again.
I can't see how using USB to send commands can expect the pulse and motion to be consistently synced .

But of course I could be assuming completely wrong.

[cyclestart]

-motion features are strongly tied to the Card.
-one relies on the card manufacturer for motion control upgrades or bug fixes, which may

On the surface it looks like a builder of linuxcnc compatible hardware has an easier road.
A feature added to linuxcnc, like some new gcode routine, would usually be accommodated without modifying external hardware because the PC remains in control ? From lurking other threads it looks like smoothstepper owners have waited (still waiting ?) for some of Mach's features to be incorporated.

No doubt I'm oversimplifying the situation

edit/ modifying these products is a matter of updating firmware probably, Waaay out of my depth here lol

[ger21]

I'm certainly no expert but I can't see how Mach can do trajectory planning while syncing a thread start pulse that it never sees. This implies that the smooth stepper does at least some of the trajectory planning.

Sounds like Mach converts the gcode to an intermediate code (programmers might call it byte code) that describes the basic motion then lets the black box do the trajectory planning.

From what I've read, mach3 does the planning. There are several mach3 devices capable of S-Curve accel/decel, but are locked into Mach3's trapezoidal accel/decel. which points to Mach3 doing the planning.

As I said, threading is a special case, and the device must do some of the planning.

But I don't know much at all about how it works.

[doug6949]

On the surface it looks like a builder of linuxcnc compatible hardware has an easier road.
A feature added to linuxcnc, like some new gcode routine, would usually be accommodated without modifying external hardware because the PC remains in control ?

No doubt I'm oversimplifying the situation

No, you got it right.

In the early days of parallel port cnc - even before Mach - there were many drawn out discussions about smart boxes with dumb PC's (SBDPC's), versus dumb boxes with smart PC's (DBSPC'S).

The EMC guys quietly ignored us.

After fourteen years I think the DBSPC is a clear winner. LinuxCNC is proof of the concept. Sure, the OS scares people, but the same thing could have been done in XP.

All the I/O cards to build a true industrial control cost less than $500. Those same cards work for a laser, waterjet, plasma, lathe, HMC, VMC, 5-axis, etc. All that changes is the software setup.

Try that with a $500 proprietary black box.

It is worth noting that many high end commercial controls use the DBSPC approach now. They just add enough proprietary stuff to the hardware to keep us from "borrowing" the software. That, by the way, was one impetus behind Mach4.

Doug

[datac]

My understanding of the current LinuxCNC Trajectory Planner is that it will never allow a speed higher than what will allow a full stop in the very next line segment.

Hey Tom,

Unless I am missing something, I don't see how that last statement could be possible..... I do stuff with thousands and thousands of incredibly short line segments because there really is no alternative. In my mind, what you said on my files would barely get moving.

I am finally committed to loading LinuxCNC on a PC but seems all my older PC's are not getting along with the install of it (yet). I'll get there because I do intend to broaden my experience with more of the controllers that are available.

That said, I have been VERY interested in your KFlop development. The video you have where the step motor sounds like it is about to destroy itslef from high rpm is impressive. I sure hope to be able to squeak out some spare cash to buy it sometime this spring in order to review it. I have no interest in running it via Machx though... I want to experience it with your GUI. So far, I have only heard people say that some things are better in mach, others in yours.

Sadly I have not been able to find much for discussion by people who have used OTHER systems so at least they are able to make direct observations. I suppose I should start a topic in the KFlop forum and see what becomes of it.

[TomKerekes]

Hi Chris,

I could be wrong, but I have read the manuals and follow the developer’s list and from what I can understand there is not any lookahead in the trajectory planner. (There is lookahead in the form of a GCode filter to reduce the number of GCode blocks, but this happens before any trajectory planning). I don’t understand it well enough to figure out if it is considering 1, 2, 2.5, possibly even 3 line segments but it clearly isn’t N segments. This also is what makes on-the-fly federate changes so easy for LinuxCNC.

I was a bit surprised myself so I did some math to try to understand why nobody is screaming. It turns out a fairly high performance machine is needed to require a lot of lookahead. The machine needs to require high speed and high accuracy at the same time. If you are ok with larger path tolerance at high speed (for roughing), and go slow when accuracy is needed (finish pass), then not much lookahead is required. If there is some curved path to follow and very high accuracy is required then the line segments must be very short to accurately describe the path, so without lookahead the speed is quite limited. If high accuracy is not required then the line segments can be longer which allows a higher speed.

I did an Excel spreadsheet to check some numbers. It would be great if someone could independently verify. One interesting thing I discovered was that the issue is independent of the machine’s max acceleration. A machine with high acceleration capability can go through curves faster but then it can stop faster as well so the same lookahead is required.

I also discovered that more lookahead is needed on more gentle curves (large radius). I guess that makes sense if you think about driving a car.

So here is an example:

Assume a curve (circle) with a radius of 1 inch

Assume an accuracy requirement of 0.2 mils

To achieve this accuracy requires line segments no longer than 57mils (222 sided polygon)

Assume a machine’s max acceleration is 40in/sec2 (~0.1G)

The max possible velocity to be able to stop in 57mils (no lookahead) is 127ipm

However it is possible to go 379ipm around a 1 inch circle and not exceed the acceleration limit

In this case a TP with lookahead could go ~3X faster

To stop from 379ipm requires 500mils of distance (~9 line segments lookahead)

Of course if the machine can’t cut at more than 127ipm then all this is a mute matter.

I ran a test with KMotionCNC+KFLOP and captured the output trajectory and it is indeed 376ipm. Using the Mach3 Trajectory Planner+KFLOP I see 210ipm. (Mach3 Ver3.042.038 Lookahead=200 CV Dist tol=180 Stop on CV angle > 90).

Maybe someone could run the test with LinuxCNC? Configured with Accel=40in/sec2 and the collinear tolerance and max deviation from path set at 0.2mils. Here is the GCode I used to generate a 222 sided 1inch radius polygon.

Yeah, Yeah, Yeah I know I can do it myself and for free :}

Regards

[BobWarfield]

It would be great to take a case like Tom has provided, and on the same machine tool, measure performance of different configurations:

- Mach3 w/ Parallel Port

- EMC w/ Parallel Port

- Mach3 w/ Smoothstepper

etc.

Real performance is so much more satisfying than debating what might be the case based on various theoretical possibilities.

Cheers,

BW

[chester88]

Tom

I don't know much beyond what I have said. It is certainly possible I misunderstood.
Your asking things on the out side edge of my understanding.
I am repeating what I have heard from the developer that would know.
So I better stop before I tell lies

To get the answers your wanting from the persons that would know the best (Chris R or Jeff E) you must message the developers mail list and/or the IRC.

Chris M

[samco]

Hi Tom. This is how I understand it also. I think you hit is spot on. The lookahead in the form of a 'gcode filter' combines the short segments into longer segments within the tolerance. Linuxcnc still blends the next segment in line (but with the filter may be longer if it combines the segments together..) (and as you say still has to be able to stop at the segment endpoint.)

Yes - that does make FO and such work much better and instantaneous. But there is a trade off. I have used linuxcnc for very little high speed contouring.. I cannot comment on that. Others have said it works quite well. Only one or two have complained about the performance that I know of. I am sure if mach has a larger look ahead it performs better - but threads like this

Whose Fault Is ThIs?

or

http://www.cnczone.com/forums/mach_s..._stalling.html

or

Brand new Tromach 1100 continues to fail - YouTube

make me want to stick with 'slow and steady' (if that is what linuxcnc is) My machine has 8 ton of cutting force - if it did something like the video above randomly - I would be a hurting unit.

Tom: I am not saying your hardware has ^ these issues. Your Stuff looks pretty darn neat.

sam

(Only a linuxcnc user that reads a lot)

Hi Chris,

I could be wrong, but I have read the manuals and follow the developer’s list and from what I can understand there is not any lookahead in the trajectory planner. (There is lookahead in the form of a GCode filter to reduce the number of GCode blocks, but this happens before any trajectory planning). I don’t understand it well enough to figure out if it is considering 1, 2, 2.5, possibly even 3 line segments but it clearly isn’t N segments. This also is what makes on-the-fly federate changes so easy for LinuxCNC.

Regards

[Leblondmakino]

Excuse me if this has already been mentioned but the main advantage for me with EMC is rigid tap, lathe threading and constant surface speed for turning.

A Galil card with Mach3 will do it but no one has written the code yet!

The vital systems 4 axis or 8 axis PCI motenc cards by-pass the printer port and have plenty of i/o terminals with the added breakout boards. Well fast enough for most applications and if you need more i/o they also do an ethernet SMART3G programmable controller which can act as master or slave...not sure if this work with EMC though?

It's all much cheaper than the Galil stuff as well.

Did I mention the tool centre point management for 5 axis machines :-)
John.

[TomKerekes]

BTW we have rigid tapping with Mach3+KFLOP.

[ame=http://www.youtube.com/watch?v=ZaKN-DocVe0]tapmach_kflop.wmv - YouTube[/ame]

Regards

[Leblondmakino]

Looks great Tom. My reason for leaning towards emc was the lathe side of things as I can get css and threading like my old Fanuc controller.

John