Erik Christiansen wrote: > Curve fitting to an arbitrary bunch of points is an approximate art, > AIUI, with tolerance calculation at all points probably taking a bit of > time. Admittedly, I don't know whether nurbs make that faster/slower or > easier/harder to achieve algorithmically. But it does look "non-trivial". > NURBS reduces a complex, arbitrary surface to a very small number of control points. You then have the freedom to interpolate on the surface with any grid you want, and you also can extract acceleration requirements pretty easily from the NURBS data.
Turning a massive point cloud back into a NURBS surface is no better than any other attempt to fit curves to the points. > But isn't the LinuxCNC dictum "Must be able to come to a dead stop > within the current line segment" unnecessary and unhelpful when > following a piecewise linear approximation of a smooth curve? Yup, that's EXACTLY the problem. G-code doesn't have any way to express "the following thousand points follow a smooth curve." The ONLY way to know there are no surprises several blocks ahead are to read and calculate the accelerations required in those blocks. In the worst case, it is conceivable that a right-angle turn could be a thousand blocks ahead of where you are looking right now, and you need to begin the decel now! That's the rub. > > If it is impossible to increase LinuxCNC's look-ahead, to allow it to > see that it need not radically decelerate, then why not put the > look-ahead in the gcode? Gcode allows Feedrate setting amongst the > "axes" terms in a G1. Would it not be possible to add a Gwhiz gcode to > turn off the stopping-within-a-segment hesitancy, and set a nice fast > initial Feedrate along with the G1. A lower Feedrate setting would then > be inserted prior to any sharp corner or the end of the curve. > This is clearly the easy way out. It is moving this difficult problem to the CAM system, which DOES have more information on the whole machining task, as well as the luxury of not having to do it in real time. The downside is that if this is done wrong, it will lead to a following error or some other type of violent halt, when LinuxCNC discovers it is running at 600 IPM right into a right-angle turn. Of course, if some outboard program could be written to do this, it could also be put into the interpreter. I have no idea how much computation this would take, but it doesn't sound computationally difficult. It does sound heavily iterative, so could be slow. Start at block one, calculate acceleration. Check acceleration on next block, repeat. Keep going until you find a block where there is a high acceleration. Now, work backwards to figure out when you need to slow down so that high accel block does not require excessive acceleration. Now, rewrite the F words on these blocks so that the decel is commanded smoothly towards the high accel block. I would think such a program could be written as a filter and tested with a sim version of LinuxCNC where insane acceleration is permitted. When it seems to be working right, then maybe a special hack to the traj planner could be tried to remove the look-ahead limiting and see how it works. If all this works OK, then integration of the feature into LinuxCNC could be contemplated. But, it may well be that this is just too slow to try to do in almost-real time, and may always need to be a separate program. Jon ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
