On Fri, 20 Apr 2012 12:12:54 -0500 Jon Elson <el...@pico-systems.com> wrote:
> Erik Christiansen wrote: > > Curve fitting to an arbitrary bunch of points is an approximate art, ( no pun intended, of course! ) > > 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 Looking at this in a naive manner, it would seem that the cam (external) must be able to fit the nurbs (points) to the required accuracy and the algorithm used must match the linuxcnc internals (here I'm thinking traj calculation as in G2/G3, which by the way, are straight line segments somewhat below the resolution of the machine unless one is really screaming along. Do the calcs at even a 1 KHz servo rate and 15 ipm. Since one can halt/pause linuxcnc in the middle of a G1/G2/G3 block then the same should follow for nurbs or any other internally calculated move. Am I missing something? Dave > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
