I prefer top posting myself unless I am commenting to specific points. I would say that motion is either #1 or #2 priority. I am not sure how the priority is related to good timing (depends on the hardware software). I would put it at #2 -- because it depends on good timing.
The short segment problem that I am aware of has to deal with stopping at the end of each. If you have enough look ahead, then you can slow down, but not stop, near the end. If there are many short segments at the end of a path, then you might need to start deceleration well in advance, and take care of the motion control on a meta-segment basis. Is that the segment problem you are alluding to, or something else. The ways I know of handling this (and higher order continuity such as jerk) would require replacing the underlying motion spline representation. Personally, I like NURBS, as they give you an exact geometric representation of all conics (including circles), and can give a helix with a simple transformation of the control points -- this gives you threading for free. So, how about defining the design/implementation priorities as: #1: high-res real-time timers and tools #2: motion -- dealing with moving the end effort in a smooth and predictable way #3: tool compensation -- which modifies the geometry of the tool path of #2 #4 wear offsets -- which modify the tool compensation above from there we start having meaningful stuff coming in/out of our GUI's -- whose design should be independent of underlying implementation details -- asuming we can find a reasonable API. Anyway, hope this was not to much a distraction. EBo -- On May 18 2013 5:14 PM, dave wrote: > With apologies to the "Bard" > > Sorry guys, I'll top post so you don't have to hunt for it. > > To wit: the discussion is good but very narrow in application. Just a > WAG but I suspect that I could count on one hand or maybe both the > number of users that have machines and applications good enough to > worry > about wear on an insert. Oh, I know a lot of us would like precision > and > repeatability in .001" range but I don't hear any users crowing about > it. To be truthful probably only 10% of us or less even have tool > changers outside of the 'armstrong' type. > > On the other hand I do hear users complaining about motion and > especially about the handling of short segments. If this issue were > easy > it would have been fixed long ago. Limiting jerk would be nice but it > won't fix the real problem. Fixing motion would open the door for > actual > high-speed machining. > > There are many other emc issues but maybe one at a time will help. > > I openly admit I don't have the talent to even think about working on > this so I'll shut up. > > 'in for a penny in for a pound' ;-: > > Dave > > > > On Sat, 2013-05-18 at 23:10 +0200, Michael Haberler wrote: >> Am 18.05.2013 um 22:27 schrieb andy pugh <bodge...@gmail.com>: >> >> > On 18 May 2013 20:38, Michael Haberler <mai...@mah.priv.at> wrote: >> > >> >> probably the table above needs a column 'active' which starts out >> as true and can be set to false to disable a tool - either through >> breaking or if wear becomes too high; that would be an update run when >> wear offsets are updated >> > >> > This could be achieved by moving it out of the active magazine. >> But >> > there probably isn't any real advantage in that level of >> > key-parsimony. >> >> I think the magazine table needs to reflect the physical occupation, >> not the usable tools; you might be able to disable a tool for wear or >> breakage, but you might not be able to physically remove the tool >> midflight without endangering some limb ;) ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
