Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On Fri, 20 Apr 2012 09:47:44 +0100, you wrote: >On 20 April 2012 06:42, Scott Hasse wrote: >> Rather than trying to solve this problem in a million places not under our >> control, doesn't it make sense to try and solve it properly in one place >> and look more closely at using more than one line for look ahead? > >As I said earlier, I don't think this is a "Lookahead" problem, it is >a "must be able to stop inside the next code block" problem. >And I am not convinced that being able to stop the machine within the >next code block is necessarily a sensible requirement. One line look ahead seems to cause a problem in LinuxCNC, the trajectory planner is not optimal. Mach seems to be able to feed hold without having to run out the whole look ahead buffer. The look ahead is user selectable, but I've never ran any code that in practice needed more than 10 lines. Some code is crap, no getting away from that but for the same code, same velocity and acceleration settings etc LinuxCNC is much more jerky, and slower than Mach on the same job using steppers via parallel port. It's particularly worse on arc to arc or arc to line transitions. Short straight line type 3D code is also poor. To get it to behave similar to Mach the following tolerance needs to be 10 times worse! This is how it's done with Mach. (Quote from Art Fenerty) Mach3 is a bang-bang accelerative trapezoidal velocity planner, and a very good one for almost all code types. Its CV is created by the simple rule of beginning the acceleration of the next motion when the acceleration of the current move goes negative. ( deceleration phase). This means you are literally adding one move to the next , allowing for the speed to increase. I'm sure many have read this before and can picture it in the context of two motions where the second is added to the first , thus making the deceleration phase virtually invisible ( thus constant velocity ), but what I , or Brian, rarely mention is that it operates in full look ahead, this means that in tiny segment code, the code of a line may be passed over by the time sequence of the planner as it progresses, but that motions speed must still be added in to the total of the motions distance. This means its an iterative process, where up to 100 lines or more may be actively added together in terms of their deceleration phases being added to the next motions acceleration phase. This can be hard to wrap the head around. Each Gcode line has to be considered fully in the iterative calculations involved. Imagine tiny segment code where the angle of the next motion is constantly shifting ( typical 3d work ), and the processor is trying to keep track of the real speed that's possible. Since the consistency of the speed is a function of the additive properties of each motions deceleration phase, it means the max speed an individual motion can do is important in the functions total speed accumulation. Steve Blackmore -- -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
total lookahead is a boundless problem, just as creating a 3d preview of the commanded toolpaths is a boundless problem (the backplot). the controller on some level can handle the ngc file in its entirety, so why not deal with machine acceleration limits on the same level, or machine limits in general - feed, movement bounds, spindle speeds, tool numbers, etc. so commanded feedrates in a file are upper bounds, and within those bounds, maximum feedrates are always possible. --- On Fri, 4/20/12, Jon Elson wrote: > From: Jon Elson > Subject: Re: [Emc-users] Trajectory planning and other topics from a > EMC(LinuxCNC) newbie (TheNewbie) > To: "Enhanced Machine Controller (EMC)" > Date: Friday, April 20, 2012, 9:54 AM > andy pugh wrote: > > As I said earlier, I don't think this is a "Lookahead" > problem, it is > > a "must be able to stop inside the next code block" > problem. > > And I am not convinced that being able to stop the > machine within the > > next code block is necessarily a sensible requirement. > > > Exactly! It is a safe scheme, but becomes a > limitation. Total > lookahead is a boundless > problem, so I can see that is not sensible. What I can > imagine is a > method of lookahead > where each vector is examined for acceleration, and it keeps > running > ahead until a large > acceleration would be required. Some kind of mark is > made for that > vector so the > traj planner knows a deceleration would be required coming > up on that > point. Perhaps > this accel scanning could put the mark back the required > number of > blocks so that when > the traj planner hits that mark it begins the decel > then. This all is > complicated by the > feedrate override that is implemented at the moment. > But, the scanning > could probably > just assume 100% speed (or whatever the max override > allows). > > 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 > -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 20.04.12 12:25, Jon Elson wrote: > Stuart Stevenson wrote: > > Doesn't even G02/G03 result in a series of very small linear moves sent to > > the servo motors? Wouldn't a NURB conversion do the same thing > > Yes, in a way. But, the G02/G03 is known to be a single move, so > there is no velocity change until the end of that move. NURBS doesn't > really solve this problem, it just condenses the description of the > surface, and allows a program to fairly simply determine the > accelerations that might be needed to traverse it. > > The problem with general G-code is each block tells you nothing about > any other block. So, you have to read arbitrarily far ahead to know > if there are any sudden changes in velocity coming up. Sort of arbitrary, but fully determined by the gcode, I think, because the look-ahead only needs to keep one stopping distance ahead of the executed motion, by subtracting the length of the currently executing motion, and adding enough look-ahead segment lengths to stay far enough ahead for the current feedrate. If there are no sharp bends or a stop in the headlights, keep truckin'. I don't imagine that we sprinkle so many feedrate changes into the segment list for a G1, that Mach's merging of the next feedrate would make a damn's worth of difference to this case. Our problem is getting LinuxCNC off its knees, to dare to obey the given feedrate on a long chain of micro-segments. (I.e. fit headlights, rather than have a man with a red flag walking in front.) Erik -- Re: Graphics: A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Viesturs Lācis wrote: > 2012/4/21 Jon Elson : > >> Stuart Stevenson wrote: >> >>> Would a read ahead of 1000 lines be more time consuming than the NURB >>> calculation? >>> >> A modest NURBS surface could be scanned pretty quickly to find the sharp >> edges, >> if any. 1000 block lookahead may not be necessary, even 100 block would >> probably >> suffice in most machines. >> > Not sure. I have seen arcs consisting of tiny G1 moves that are really > tiny - around 0,01 mm. 100 lines would be 1 mm. > OK, there are rational toolpaths with short segments, and then there are IRrational ones that have WAY too many short segments. LinuxCNC already has a filter mode (G64) to deal with this kind of insanity. But, I don't think it is LinuxCNC's responsibility to fix badly created G-code. You can always craft some kind of G-code that is highly pathological but yet conforms to the language spec. > I did little calcs - moving with 100 mm/s (6000 mm/min) and with > acceleration of 1000 mm/s^2 (0,1G) it will take 5 mm to fully stop. > The real problem I see is that RATIONAL G-code that was correctly written to perform a particular operation cannot be executed as fast as the machine and drives COULD allow it to go, due to the stop on next block requirement. 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
2012/4/21 Jon Elson : > > The real problem I see is that RATIONAL G-code that was correctly written to > perform a particular operation cannot be executed as fast as the machine and > drives COULD allow it to go, due to the stop on next block requirement. I agree. What I see the big issue for solving this in trajectory planner or whatever _inside_ LinuxCNC is that I do not see, how to determine by some hard facts, what is the best way to determine the lookup amount. Certain number of lines or a certain travel distance? Ok, when the method is chosen, how to determine, what is the optimum value? That is why I am in favor of adding a separate filter, which would take the code and rephrase it to what is really in there - either arcs or splines/nurbs. In this case the file would be processed, when loaded (I have not really understood, when it would be processed in the first variant - also on loading or on the fly, when it is executed), so it definitely would not affect realtime performance, because the file would not be executed at that time. I think that waiting 10-20 seconds for the PC to recalculate the path and find, what curves would fit the existing profile, defined by tiny G1s. Viesturs -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Gentlemen, Since we have discussed this so long I have remembered a project that would be similar and maybe be completed at the same time. I want to implement 5 axis cutter compensation. Currently, LinuxCNC's cutter compensation takes the cutter radius into consideration. This makes the implementation of 5 axis cutter diameter compensation a problematic scenario. thanks Stuart -- dos centavos -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
optimum value for planning ahead for a possible stop or maximum acceleration change: take current feed for current block and maximum possible accel of machine to get distance required for stop. then next N blocks that cover that distance, and apply appropriately modified feeds to them. think of a gcode file as a matrix, each row would correspond to a block, the first several columns are all the various gcodes, the next several are all the various x1..xn axes, then several columns covering offset vectors, feeds, spindle, various Ms, etc. then just tack on another column that is the achievable feed. when file is loaded to controller, it gets scanned to fill in the values in the actual feetrate column. maybe there is another similar column for actual spindle speed that gets filled in similarly, in case it's being used like a c axis to get coordinated revolution. at program execution, the calculated realistic values columns are used to generate motion. soft program stops during execution may run out a few blocks. estops are an emergency situation, so who knows.. single stepping is usual one line check based on stop at end of block. are there not already some 'hidden' columns x1'..xn' that result from cutter radius compensation? i guess i'm thinking of linear programs, so in the case of loops and subroutine calls, the end result is a much longer list of actually executed blocks. maybe it never ends (= bad gcode). probing would also not fit the scheme very well - maybe consider probing blocks to be bounded in the code by stops? or, what if there were choices between more flavors of operation: advanced lookahead flavor would not allow nuts in it like conditional loops or surprise probings; crazy probe scanner routine mode wouldnt have the texture advantage of nice feedrate smoothness. --- On Sat, 4/21/12, Viesturs Lācis wrote: > From: Viesturs Lācis > Subject: Re: [Emc-users] Trajectory planning and other topics from a > EMC(LinuxCNC) newbie (TheNewbie) > To: "Enhanced Machine Controller (EMC)" > Date: Saturday, April 21, 2012, 12:58 PM > 2012/4/21 Jon Elson : > > > > The real problem I see is that RATIONAL G-code that was > correctly written to > > perform a particular operation cannot be executed as > fast as the machine and > > drives COULD allow it to go, due to the stop on next > block requirement. > > I agree. > What I see the big issue for solving this in trajectory > planner or > whatever _inside_ LinuxCNC is that I do not see, how to > determine by > some hard facts, what is the best way to determine the > lookup amount. > Certain number of lines or a certain travel distance? Ok, > when the > method is chosen, how to determine, what is the optimum > value? > > That is why I am in favor of adding a separate filter, which > would > take the code and rephrase it to what is really in there - > either arcs > or splines/nurbs. In this case the file would be processed, > when > loaded (I have not really understood, when it would be > processed in > the first variant - also on loading or on the fly, when it > is > executed), so it definitely would not affect realtime > performance, > because the file would not be executed at that time. I think > that > waiting 10-20 seconds for the PC to recalculate the path and > find, > what curves would fit the existing profile, defined by tiny > G1s. > > Viesturs > > -- > 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Viesturs Lācis wrote: > What I see the big issue for solving this in trajectory planner or > whatever _inside_ LinuxCNC is that I do not see, how to determine by > some hard facts, what is the best way to determine the lookup amount. > The number of blocks you need to look ahead is variable. The way I imagine it, you'd look ahead until you found a move that violates the requested speed due to acceleration. Then, you have to work backwards from that point to find out what block you need to begin slowing down at. Some other methods, like a fixed number of blocks might be easier to implement, and would improve on the current situation. For instance, adding just ONE single block more lookahead might increase speeds by a factor of TWO in the worst case. Of course, if you can do it for 2 blocks, it should be relatively easy to extend that to 10 blocks. By adding this to the naive cam detector, that might be enough to make many users happy. A 10-block lookahead seems like it would not take excessive CPU or memory resources, while the scheme described in the previous paragraph just might. 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 21.04.12 23:23, Jon Elson wrote: > Viesturs Lācis wrote: > > What I see the big issue for solving this in trajectory planner or > > whatever _inside_ LinuxCNC is that I do not see, how to determine by > > some hard facts, what is the best way to determine the lookup amount. > > > The number of blocks you need to look ahead is variable. The way I > imagine it, you'd look ahead until you found a move that violates the > requested speed due to acceleration. Then, you have to work backwards > from that point to find out what block you need to begin slowing down > at. Jon, there's probably no need to do this backwards. Look-ahead only needs to be simple look-ahead, nothing more, AIUI. The current velocity (feedrate) is known, and the stopping distance for the machine at that velocity is fixed. So, by summing immediately upcoming gcode path segments to a length a little greater than the stopping distance, LinuxCNC can _safely_ continue at full feedrate in the currently executing path segment if there are no sharp bends or stops in the look-ahead "headlights" zone of scanned path segments. If there's a sharp manoeuvre showing in the headlights: drop feedrate below that gcoded for the executing segment, according to the deceleration needed for the impending path deviation. So the look-ahead is simple. If there's any complexity thus far, or need to do it backwards, then I'm having trouble seeing it, and would appreciate enlightenment. The memory required to queue even a thousand coordinate points of a long G1 path is so miniscule in relation to current RAM stick sizes, as to be completely negligible, I think. Erik -- Bumper sticker: Honk if you love peace and quiet. -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
gents, you are busily inventing path queueing mechanism number 3. The existing ones are: CRC offset curve aka queued_canon, and NCD aka chained_points. Other ideas have been floating around like a circular buffer in front of motion so motions can be stepped back. If this goes on like discussed here, next time we look at the repo we'll have a grand total of 5 (*five*) path queuing mechanism in linuxcnc. Not sure whether this dog will not hunt. ok, path history (as opposed to gcode line history) is needed, and it is so for several features. I would encourage to think about, and architect a single path history mechanism, which in principle can support all of the so-far-implemented and considered features. IMO this requires reconsidering where some features are implemented, and face the fact that they might have to be moved. For instance, offsets, rotation, CRC, and NCD not necessarily have to be in the canon layer. Observe that all of the existing, and the proposed mechanism have to do with delaying binding decisions. -- I could imagine the following approach, the basic idea being to collapse all path history processing into a single mechanism, while at the same time delaying some decisions so they can be more easily reconsidered, for instance during pause (see below). - the interpreter/canon generates motions without actually applying offsets, CRC etc, but passes on the information needed to apply them later. - between task and motion is not a single queue, but two: -- a 'unbound queue' (actually a circular buffer) -- a binding thread which works on the unbound queue, records and applies offsets, CRC, does lookahead/correction as needed for NCD etc, and feeds commands into -- a 'bound queue' (also a circular buffer) - this is where move coordinates have their final values. -- motion works off the bound queue. re undoing (aka 'backing up the interpreter') - this relates to 'manual/MDI/jog while paused': changing offsets while paused: this amounts to finding, for a given bound queue entry active while pause was executed: - have the binding thread find the corresponding 'unbound queue' entry - change offset - throw away the bound queue, and reexecute the unbound queue with new offsets. changing tool while paused, which could change tool radius and hence the CRC offset curve: same trick: - find the corresponding 'unbound queue' entry - change tool properties - throw away the bound queue, and reexecute the unbound queue to generate a new CRC offset curve. MDI-while-paused: this could be doable as follows: - on pause, snapshot bound and unbound queues. - switch to a new instance of task and interpreter, which is synced to the current position. - 'MDI around' - when done, switch back to original task/interpreter instance, restore queue snapshots, then reexecute the unbound queue if some world model state changed, else continue on bound queue. Jogging back moves during pause: - apply commands in bound queue in reverse. This is just a rough sketch of a possible approach; I did not think through details like the reentry moves. I would also think the effort is considerable, and would not necessarily recommend grafting this onto the current code. But then it's time to start collecting ideas for Linuxcnc3. - Michael Am 22.04.2012 um 10:21 schrieb Erik Christiansen: > On 21.04.12 23:23, Jon Elson wrote: >> Viesturs Lācis wrote: >>> What I see the big issue for solving this in trajectory planner or >>> whatever _inside_ LinuxCNC is that I do not see, how to determine by >>> some hard facts, what is the best way to determine the lookup amount. >>> >> The number of blocks you need to look ahead is variable. The way I >> imagine it, you'd look ahead until you found a move that violates the >> requested speed due to acceleration. Then, you have to work backwards >> from that point to find out what block you need to begin slowing down >> at. > > Jon, there's probably no need to do this backwards. Look-ahead only > needs to be simple look-ahead, nothing more, AIUI. The current velocity > (feedrate) is known, and the stopping distance for the machine at that > velocity is fixed. > > So, by summing immediately upcoming gcode path segments to a length a > little greater than the stopping distance, LinuxCNC can _safely_ > continue at full feedrate in the currently executing path segment if > there are no sharp bends or stops in the look-ahead "headlights" zone of > scanned path segments. If there's a sharp manoeuvre showing in the > headlights: drop feedrate below that gcoded for the executing segment, > according to the deceleration needed for the impending path deviation. > So the look-ahead is simple. > > If there's any complexity thus far, or need to do it backwards, then I'm > having trouble seeing it, and would appreciate enlightenment. > > The memory required to queue even a thousand coordinate points of a long > G1 path is so miniscule in relation to current RAM sti
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 4/22/2012 11:07 AM, Michael Haberler wrote: > gents, you are busily inventing path queueing mechanism number 3. The > existing ones are: CRC offset curve aka queued_canon, and NCD aka > chained_points. Michael: I'm trying to get up to speed on the issues discussed in this thread. Not being an aficionado of the LinuxCNC code base, I have to assume that here "NCD" means naive CAM detector. To me, "CRC" means cyclic redundancy check. I see comments in the code base that suggest a CRC computed in some manner is used to detect when a change occurs in "the queue" but I'm don't understand the cause or the consequence. If this mechanism is discussed in some foundational document I'd like to get a reference. In the User Concepts document, we discuss P61 "exact path mode", P64 "blend without tolerance mode", and P64 P- Q- "blend with tolerance mode". I always associated "NCD" with blend with tolerance. Does "CRC" refer to blend without tolerance? As for the rest of your discussion regarding a single path history mechanism, "lay on MacDuff!" I hope to see an ongoing conversation. To my ears, you make a compelling argument, but it sounds like a major disruption to the existing code base (e.g., rightfully something for LinuxCNC3) and I have no idea how hard it would be to pull off, e.g., to code and to test. Regards, Kent -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 22 April 2012 16:07, Michael Haberler wrote: > gents, you are busily inventing path queueing mechanism number 3. The > existing ones are: CRC offset curve aka queued_canon, and NCD aka > chained_points. I think CRC is "Cutter Radius Compensation" and NCD os "Naive CAM detection"? I suspect that very few people know enough about how LinuxCNC works now to realise that is what it being implied. However, my understanding was that we were talking about ways to "fix" the existing behaviour. > I would also think the effort is considerable, and would not necessarily > recommend grafting this onto the current code. But then it's time to start > collecting ideas for Linuxcnc3. I think this is the approach to take, and it probably ought to include (at the least) the changes in ja3 too. However, I don't think anyone has EMC3 as a trademark, we could change the name back :-) -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On Sun, 22 Apr 2012 20:48:56 +0100, you wrote: >On 22 April 2012 16:07, Michael Haberler wrote: >> gents, you are busily inventing path queueing mechanism number 3. The >> existing ones are: CRC offset curve aka queued_canon, and NCD aka >> chained_points. > >I think CRC is "Cutter Radius Compensation" and NCD os "Naive CAM detection"? >I suspect that very few people know enough about how LinuxCNC works >now to realise that is what it being implied. However, my >understanding was that we were talking about ways to "fix" the >existing behaviour. > >> I would also think the effort is considerable, and would not necessarily >> recommend grafting this onto the current code. But then it's time to start >> collecting ideas for Linuxcnc3. > >I think this is the approach to take, and it probably ought to include >(at the least) the changes in ja3 too. > >However, I don't think anyone has EMC3 as a trademark, we could change >the name back :-) What the f^^^ is ja3? Is it any wonder that Joe Public has such a poor opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to convince me it's not a closed shop speaking in a secret language. Sigh... Steve Blackmore -- -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 04/22/2012 08:31 PM, Steve Blackmore wrote: > On Sun, 22 Apr 2012 20:48:56 +0100, you wrote: > >> On 22 April 2012 16:07, Michael Haberler wrote: >>> gents, you are busily inventing path queueing mechanism number 3. The >>> existing ones are: CRC offset curve aka queued_canon, and NCD aka >>> chained_points. >> I think CRC is "Cutter Radius Compensation" and NCD os "Naive CAM detection"? >> I suspect that very few people know enough about how LinuxCNC works >> now to realise that is what it being implied. However, my >> understanding was that we were talking about ways to "fix" the >> existing behaviour. >> >>> I would also think the effort is considerable, and would not necessarily >>> recommend grafting this onto the current code. But then it's time to start >>> collecting ideas for Linuxcnc3. >> I think this is the approach to take, and it probably ought to include >> (at the least) the changes in ja3 too. >> >> However, I don't think anyone has EMC3 as a trademark, we could change >> the name back :-) > What the f^^^ is ja3? Is it any wonder that Joe Public has such a poor What does f^^^ mean? That's not the level of discourse we expect from our colleagues. I'd suggest that if you can't be civil, you should be gone. Please. Ken > opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to > convince me it's not a closed shop speaking in a secret language. > Sigh... > > > Steve Blackmore > -- > > -- > 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
John Q. Public has no idea what Emc2/LinuxCNC is. Their opinion is absolutely meaningless. The individuals searching for a control for a machine tool will have some understanding and ask some questions. The level of the question will reveal the level understanding of any certain area. The list answers are always relevant and appropriate. Recently, I was reminded of my first question on the list. I was received very graciously. I would hope the general tone would remain the same. Thanks Stuart -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 4/22/2012 3:48 PM, andy pugh wrote: > On 22 April 2012 16:07, Michael Haberler wrote: >> gents, you are busily inventing path queueing mechanism number 3. The >> existing ones are: CRC offset curve aka queued_canon, and NCD aka >> chained_points. > I think CRC is "Cutter Radius Compensation" and NCD os "Naive CAM detection"? > I suspect that very few people know enough about how LinuxCNC works > now to realise that is what it being implied. However, my > understanding was that we were talking about ways to "fix" the > existing behaviour. > > Thanks, Andy. I'm sure you're right. That's the trouble with 3-letter acronyms. Too many chances for a clash. Once my brain had latched onto the wrong interpretation, I was doomed. Regards, Kent -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Erik Christiansen wrote: > Jon, there's probably no need to do this backwards. Look-ahead only > needs to be simple look-ahead, nothing more, AIUI. The current velocity > (feedrate) is known, and the stopping distance for the machine at that > velocity is fixed. > > So, by summing immediately upcoming gcode path segments to a length a > little greater than the stopping distance, LinuxCNC can _safely_ > continue at full feedrate in the currently executing path segment if > there are no sharp bends or stops in the look-ahead "headlights" zone of > scanned path segments. If there's a sharp manoeuvre showing in the > headlights: drop feedrate below that gcoded for the executing segment, > according to the deceleration needed for the impending path deviation. > So the look-ahead is simple. > > If there's any complexity thus far, or need to do it backwards, then I'm > having trouble seeing it, and would appreciate enlightenment. > OK, the problem with looking "ahead" is that these blocks have not been interpreted yet. So, your description is a lot like mine, just standing at the other end of a buffer of some sort, and looking the opposite direction. But, when you are at some point in the G-code, you'd have to read and interpret the code going forward in the file by some distance, which is an arbitrary number of blocks. > The memory required to queue even a thousand coordinate points of a long > G1 path is so miniscule in relation to current RAM stick sizes, as to be > completely negligible, I think. > Yes. 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Michael Haberler wrote: > > I would also think the effort is considerable, and would not necessarily > recommend grafting this onto the current code. But then it's time to start > collecting ideas for Linuxcnc3. > Wow, a lot of details. Well, certainly this is not something to be patched-on in a hurry. And, if some redesign of the current methods ALSO make some other enhancements easier, than that is great. 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
2012/4/23 Steve Blackmore : > > What is ja3? Joints_axes3 branch in master git repository. > Is it any wonder that Joe Public has such a poor > opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to > convince me it's not a closed shop speaking in a secret language. Steve, no offence, I do not think that I am the one to start teaching or giving lessons to anybody, I just think that Your attitude harms the project too. If You are here for 4 years, then I would expect that You not only use this application, but also support it. If not with any input in code, then at least with some help in answering questions of new users and/or spreading positive information about the project thus improving the opinion of Joe Public. Unfortunately from Your posts in this mailing list and some of Your posts I have seen in web-forums I have not seen anything of that, so I have not yet understood, why are You here, because it seems to me that You are much more a fan of Mach. On the other hand, I do appreciate Your critics and the weak points of the LinuxCNC You have pointed out, like the jog-during-feedhold. The thing is that I (probably others as well, but I can speak only for myself here) appreciate it as long as it is constructive and has any argumentation. For me it helps to understand, where LinuxCNC stands, when compared with other CNC controllers (and I do have to provide these comparisons with argumentation to my customers, before I get a contract with a new customer). Viesturs -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
let's discuss terminology for a minute (paths vs gcode segments) we have: 1. linear G-code programs (no oword control structures) 2. G-code with arbitrary control structures 3. Some other yet-to-be-invented language for machine control. execution of any such program generates a path (sequence of moves), which is input to the trajectory planner. for 1), there's a fixed relation between program length and number of path elements, although it might not be 1:1 (eg because of cycles) for 2), this doesnt not hold in general because the execution flow cannot be determined without looking at variables driving the flow the same must be assumed for 3) as well. Cutter radius compensation (CRC), Naive CAM detection (NCD) and other 'lookeahead based features' must operate on the path, at least because of 2) and 3). So for these features the language really drops out of the picture (although it might supply parameters to drive operations on paths), which is why I used the term 'path history'. Any preprocessor-based solution to one of these problems also needs to generate the path, operate on it, and then regenerate matching G-code (which will be the fun part of any such venture). Hence 'lookahead' is a path-based, not a language-based concept. -- it might make sense in the context of the lookahead discussion to use a concept like 'path segment' to mean a sequence of moves which can be subject to some path-based operation; so a 'path segment of size 2' would imply 'possible lookahead 1'. For instance, the some operations are incompatible with CRC, which means the current path segment must end here. For example, a 'path segment end operation' is the FINISH() canon call in emccanon.cc, which ends a path segment of moves collapsed due to Naive CAM detection. Or 'dequeue_canones()' in interp_queue.cc which ends a path segment of moves which were subject to Cutter Radius Compensation (offset curve computation). - Michael Am 23.04.2012 um 06:12 schrieb Jon Elson: > Erik Christiansen wrote: >> Jon, there's probably no need to do this backwards. Look-ahead only >> needs to be simple look-ahead, nothing more, AIUI. The current velocity >> (feedrate) is known, and the stopping distance for the machine at that >> velocity is fixed. >> >> So, by summing immediately upcoming gcode path segments to a length a >> little greater than the stopping distance, LinuxCNC can _safely_ >> continue at full feedrate in the currently executing path segment if >> there are no sharp bends or stops in the look-ahead "headlights" zone of >> scanned path segments. If there's a sharp manoeuvre showing in the >> headlights: drop feedrate below that gcoded for the executing segment, >> according to the deceleration needed for the impending path deviation. >> So the look-ahead is simple. >> >> If there's any complexity thus far, or need to do it backwards, then I'm >> having trouble seeing it, and would appreciate enlightenment. >> > OK, the problem with looking "ahead" is that these blocks have not been > interpreted > yet. So, your description is a lot like mine, just standing at the > other end of > a buffer of some sort, and looking the opposite direction. But, when > you are > at some point in the G-code, you'd have to read and interpret the code going > forward in the file by some distance, which is an arbitrary number of > blocks. >> The memory required to queue even a thousand coordinate points of a long >> G1 path is so miniscule in relation to current RAM stick sizes, as to be >> completely negligible, I think. >> > Yes. > > 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 -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On Sun, 22 Apr 2012 20:43:05 -0400, you wrote: >What does f^^^ mean? That's not the level of discourse we expect from >our colleagues. I'd suggest that if you can't be civil, you should be gone. > >Please. Apologies - no offense meant, just an everyday expression from a plain speaking northerner. Steve Blackmore -- -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On Mon, 23 Apr 2012 09:05:17 +0300, you wrote: >2012/4/23 Steve Blackmore : >> >> What is ja3? > >Joints_axes3 branch in master git repository. > >> Is it any wonder that Joe Public has such a poor >> opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to >> convince me it's not a closed shop speaking in a secret language. > >Steve, no offence, I do not think that I am the one to start teaching >or giving lessons to anybody, I just think that Your attitude harms >the project too. If You are here for 4 years, then I would expect that None taken. >You not only use this application, but also support it. If not with >any input in code, then at least with some help in answering questions >of new users and/or spreading positive information about the project >thus improving the opinion of Joe Public. Unfortunately from Your >posts in this mailing list and some of Your posts I have seen in >web-forums I have not seen anything of that, so I have not yet >understood, why are You here, because it seems to me that You are much >more a fan of Mach. I do give credit where it's due. I've often praised EMC/LinuxCNC, and did so recently in the Mach forum regarding its threading and spindle behaviour but being selective without giving the whole picture is very misleading. I use LinuxCNC for anything where threading is involved, for everything else I use a 5 year old version of Mach as it behaves much more Fanuc like with CV, feed hold etc. The current Mach offerings are buggy as hell and unreliable. >On the other hand, I do appreciate Your critics and the weak points of >the LinuxCNC You have pointed out, like the jog-during-feedhold. The >thing is that I (probably others as well, but I can speak only for >myself here) appreciate it as long as it is constructive and has any >argumentation. For me it helps to understand, where LinuxCNC stands, >when compared with other CNC controllers (and I do have to provide >these comparisons with argumentation to my customers, before I get a >contract with a new customer). I do a lot of support, development and OEM testing - my nature to call a spade, a spade - it's what I get paid to do. I don't get upset by criticism, but sometimes others do and it's got me sacked a few times - but I've always been able to wear my "told you so" t-shirt proudly a ways down the line :) I'll try and keep my comments to myself and leave you guys to it. Steve Blackmore -- -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 23 April 2012 01:31, Steve Blackmore wrote: > What the f^^^ is ja3? It isn't really of much relevance to the general user at the moment, but it is a development branch in which there is no longer an explicit link between "axes" and "joints". There are places in the current software where there is an explicit assumption that Axis X is Motor 0 for example, which leads to some inelegancies with non-cartesian machines such as robots. It is possible to use JA3, and some people do, but it very much a work-in-progress. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 4/23/2012 2:24 AM, Michael Haberler wrote: > let's discuss terminology for a minute (paths vs gcode segments) > > we have: > 1. linear G-code programs (no oword control structures) > 2. G-code with arbitrary control structures > 3. Some other yet-to-be-invented language for machine control. > > execution of any such program generates a path (sequence of moves), which is > input to the trajectory planner. > > <...> > > So for these features the language really drops out of the picture (although > it might supply parameters to drive operations on paths), which is why I used > the term 'path history'. As an aside, the choice of language (and the nature of the program written in it) will still determine how much work the interpreter has to do before a warning sign can loom into view in the headlights (to borrow Eric's phraseology) of the trajectory planner. It may not be an issue in developing an architecture, but it may still be a performance consideration. > Any preprocessor-based solution to one of these problems also needs to > generate the path, operate on it, and then regenerate matching G-code (which > will be the fun part of any such venture). Not that my opinion as a bystander counts for much, but I'm acutely uncomfortable with a preprocessor-based solution as the only effort, in part because it annoys me to think of all the work some of us did in the 80s and 90s to make sure IGES and PDES/STEP could pass NURBS curves and surfaces into and out of CAD systems as required in real-world designs like cars, ships, airplanes, and most consumer products. First the CAD system creates them, then the CAM system destroys them, then a preprocessor tries to infer them. Sigh. At a suitable level of abstraction, the same problem exists in the CAD world where people keep trying to convert back and forth between CAD models consisting of BRep, CSG, or other geometric representations and visualization models consisting of tessellated surfaces such as triangular meshes. So-called surface-reconstruction software demands a premium price in today's market. On the other hand, those users who see the need can pursue a preprocessor-based solution now, not waiting for a better solution that may or may not appear at some date in the future. I've never believed in letting the perfect be the enemy of the good. If a better solution does show up in future, so much the better. One can never have too many tools:-) Regards, Kent PS - sorry for my brain spasm over "CRC" yesterday. A nudge from Andy, a new day, a cup of fresh coffee, concentration on subtractive instead of additive manufacturing and I'm back in the right ballpark. -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On Mon, 23 Apr 2012 17:01:30 +0100, you wrote: >On 23 April 2012 01:31, Steve Blackmore wrote: > >> What the f^^^ is ja3? > >It isn't really of much relevance to the general user at the moment, >but it is a development branch in which there is no longer an explicit >link between "axes" and "joints". There are places in the current >software where there is an explicit assumption that Axis X is Motor 0 >for example, which leads to some inelegancies with non-cartesian >machines such as robots. > >It is possible to use JA3, and some people do, but it very much a >work-in-progress. Thanks for the explanation Andy. Steve Blackmore -- -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
I was searching the web and came across this paper: about nurbs planning including s curve acceleration. www.cadanda.com/CAD_4_1-4__34.PDF Above my pay grade but interesting. I was also thinking it would be interesting to discuss the frame work of a linuxcnc3. Is it useful to start clean on everything? What would we drop and/or add to a must-have list. What would the goals be? What have we learned so far good and bad? Who would actually be interested in doing the work? And on the side of that who would/could document the innards of linuxcnc so some less skilled programmers could contribute. Just to start the discussion: I think HAL as a whole would be pretty much just used as is. I'm sure some technical things could be improved but the modularity, flexibility and relative simplicity of HAL sure makes it a winner. Personally I'd like to see the languages pared down to C,C++, and python. Which it seems we are mostly going that way anyways. I would think that it would be a long term goal much like JA3. Of course I'm thinking on the developers side, what do integrators wish for? I mean besides jog while paused :) Is S curve acceleration or look ahead really a wanted feature? Are people happy with the GUI/ screen options that are starting to open up? Chris M -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 24 April 2012 03:19, Chris Morley wrote: > And on the side of that who would/could document the > innards of linuxcnc so some less skilled programmers > could contribute. I think somebody is already looking at this. > I think HAL as a whole would be pretty much just used > as is. I'm sure some technical things could be improved Possibly more data types for pins. (maybe just "pointer"?) -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
An easily customizable GUI would be nice. You very often need to be able to add or remove GUI features depending on the machine. This and jog while paused are the main reasons why I still use Mach on my mill. Les > Of course I'm thinking on the developers side, what do integrators > wish for? I mean besides jog while paused :) > Is S curve acceleration or look ahead really a wanted feature? > Are people happy with the GUI/ screen options that are starting > to open up? > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 24 April 2012 11:30, Les Newell wrote: > An easily customizable GUI would be nice. Have a look at gscreen, which is a UI written by Chris Morley entirely in Glade http://www.linuxcnc.org/index.php/english/component/kunena/?func=view&catid=41&id=17806&limit=6&start=24#17895 I haven't tried it, but my impression is that you can change the UI simply by editing the gscreen.glade file in the Glade editor. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Hi, Time to give my point of view (really interesting threat). IMHO, stopping inside the next code block is absolutely not needed. What is needed, is that all processed lookahead line are stocked inside the real-time part (EMC) and not in Axis or any other application. (EMC will eat as many line as needed to ensure maximum speed, with some limitation on the max number of line) This way, if the machine as to stop for any reason, it know the motion to follow for the deceleration phase. This could be a nice upgrade to EMC, but in my mind, this as to come with some work on interpolation, in order to have the smoothest possible motion (well... kind of, as this is a like the Grall...) Claude Le 20.04.2012 10:47, andy pugh a écrit : > On 20 April 2012 06:42, Scott Hasse wrote: >> Rather than trying to solve this problem in a million places not under our >> control, doesn't it make sense to try and solve it properly in one place >> and look more closely at using more than one line for look ahead? > As I said earlier, I don't think this is a "Lookahead" problem, it is > a "must be able to stop inside the next code block" problem. > And I am not convinced that being able to stop the machine within the > next code block is necessarily a sensible requirement. > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
S curve accels are very important on fast machines and very desirable on high inertia machines at lower speeds. >>Are people happy with the GUI/ screen options that are starting to open up? Yes, Extremely happy! :-) GladeVCP, Gscreen, and Touchy are a huge steps forward. Dave On 4/23/2012 10:19 PM, Chris Morley wrote: > > I was searching the web and came across this paper: > about nurbs planning including s curve acceleration. > > www.cadanda.com/CAD_4_1-4__34.PDF > > Above my pay grade but interesting. > > I was also thinking it would be interesting to discuss > the frame work of a linuxcnc3. > > Is it useful to start clean on everything? > What would we drop and/or add to a must-have list. > What would the goals be? > What have we learned so far good and bad? > Who would actually be interested in doing the work? > And on the side of that who would/could document the > innards of linuxcnc so some less skilled programmers > could contribute. > > Just to start the discussion: > > I think HAL as a whole would be pretty much just used > as is. I'm sure some technical things could be improved > but the modularity, flexibility and relative simplicity of > HAL sure makes it a winner. > > Personally I'd like to see the languages pared down to > C,C++, and python. Which it seems we are mostly going > that way anyways. > > I would think that it would be a long term goal much like JA3. > > Of course I'm thinking on the developers side, what do integrators > wish for? I mean besides jog while paused :) > Is S curve acceleration or look ahead really a wanted feature? > Are people happy with the GUI/ screen options that are starting > to open up? > > Chris M > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Strictly from an outside observer.. I would thing that modularizing (is that even a word) linuxcnc so like hal (that can run by itself) each 'module' could be replaced with a different one. So - say someone writes a different g-code parser.. or a different TP.. or whatever. These could be hooked in easier. I like the hal architecture where each component has pins that can be virtually hooked together. Again - I am coming from a 'big picture' perspective. sam On 4/23/2012 9:19 PM, Chris Morley wrote: > > I was searching the web and came across this paper: > about nurbs planning including s curve acceleration. > > www.cadanda.com/CAD_4_1-4__34.PDF > > Above my pay grade but interesting. > > I was also thinking it would be interesting to discuss > the frame work of a linuxcnc3. > > Is it useful to start clean on everything? > What would we drop and/or add to a must-have list. > What would the goals be? > What have we learned so far good and bad? > Who would actually be interested in doing the work? > And on the side of that who would/could document the > innards of linuxcnc so some less skilled programmers > could contribute. > > Just to start the discussion: > > I think HAL as a whole would be pretty much just used > as is. I'm sure some technical things could be improved > but the modularity, flexibility and relative simplicity of > HAL sure makes it a winner. > > Personally I'd like to see the languages pared down to > C,C++, and python. Which it seems we are mostly going > that way anyways. > > I would think that it would be a long term goal much like JA3. > > Of course I'm thinking on the developers side, what do integrators > wish for? I mean besides jog while paused :) > Is S curve acceleration or look ahead really a wanted feature? > Are people happy with the GUI/ screen options that are starting > to open up? > > Chris M > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
eff carrot carrot carrot "mom! jonny went on the internet and typed a BAD word!" "now jenny.. dont be upset. you know the censors keep the internet perfectly bland." --- On Sun, 4/22/12, Steve Blackmore wrote: > From: Steve Blackmore > Subject: Re: [Emc-users] Trajectory planning and other topics from a > EMC(LinuxCNC) newbie (TheNewbie) > To: "EMC2-Users-List" > Date: Sunday, April 22, 2012, 11:51 PM > On Sun, 22 Apr 2012 20:43:05 -0400, > you wrote: > > > >What does f^^^ mean? That's not the level of discourse > we expect from > >our colleagues. I'd suggest that if you can't be civil, > you should be gone. > > > >Please. > > Apologies - no offense meant, just an everyday expression > from a plain > speaking northerner. > > Steve Blackmore > -- > > -- > 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 > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
exaggerated mechanism contraption 3? i am stoked for more lowgrade cable movie series. --- On Sun, 4/22/12, Steve Blackmore wrote: > From: Steve Blackmore > Subject: Re: [Emc-users] Trajectory planning and other topics from a > EMC(LinuxCNC) newbie (TheNewbie) > To: "Enhanced Machine Controller (EMC)" > Date: Sunday, April 22, 2012, 5:31 PM > On Sun, 22 Apr 2012 20:48:56 +0100, > you wrote: > > >On 22 April 2012 16:07, Michael Haberler > wrote: > >> gents, you are busily inventing path queueing > mechanism number 3. The existing ones are: CRC offset curve > aka queued_canon, and NCD aka chained_points. > > > >I think CRC is "Cutter Radius Compensation" and NCD os > "Naive CAM detection"? > >I suspect that very few people know enough about how > LinuxCNC works > >now to realise that is what it being implied. However, > my > >understanding was that we were talking about ways to > "fix" the > >existing behaviour. > > > >> I would also think the effort is considerable, and > would not necessarily recommend grafting this onto the > current code. But then it's time to start collecting ideas > for Linuxcnc3. > > > >I think this is the approach to take, and it probably > ought to include > >(at the least) the changes in ja3 too. > > > >However, I don't think anyone has EMC3 as a trademark, > we could change > >the name back :-) > > What the f^^^ is ja3? Is it any wonder that Joe Public has > such a poor > opinion of EMC/LinuxCNC!! - I've been here 4 years and > you've yet to > convince me it's not a closed shop speaking in a secret > language. > Sigh... > > > Steve Blackmore > -- > > -- > 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 > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
http://hal.archives-ouvertes.fr/docs/00/67/91/18/PDF/2012_beudaert_lavernhe_tournier_Feedrate_interpolation_with_axis_jerk_constraints_on_5_axis_NURBS_and_G1_tool_path.pdf Joachim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
"High speed interpolation for micro-line trajectory and adaptive real-time look-ahead scheme in CNC machining" http://www.mmrc.iss.ac.cn/~xgao/papernc/2011-scichina-1.pdf Joachim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
