Re: [Emc-users] Trajectory planning
> From: Peter Wallace [mailto:p...@mesanet.com] > On Thu, 23 Nov 2023, John Dammeyer wrote: > > > Quick question here. The HAL file has two time intervals I believe in > nanoseconds? > > BASE_PERIOD = 24000 > > SERVO_PERIOD = 100 > > > > So BASE_PERIOD is about 41.67kHz and SERVO_PERIOD is 1kHz? > > Yes > > > > I'm guessing the encoder edges are counted between BASE_PERIOD Ticks > to determine spindle velocity? Is that correct? > Yes > > > > That the trajectory planner calculates a new velocity relative to the > > spindle every SERVO_PERIOD? In other words the step rate to say the Z > axis > > for threading is changed (or left the same) every 1mS. > Yes > > > > Have I got that right? Just looking for an overall simple description. > > > > Yep > > Peter Wallace > Mesa Electronics Thanks Peter. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Trajectory planning
On Thu, 23 Nov 2023, John Dammeyer wrote: Date: Thu, 23 Nov 2023 17:07:57 -0800 From: John Dammeyer Reply-To: "Enhanced Machine Controller (EMC)" To: "'Enhanced Machine Controller (EMC)'" Subject: [Emc-users] Trajectory planning Quick question here. The HAL file has two time intervals I believe in nanoseconds? BASE_PERIOD = 24000 SERVO_PERIOD = 100 So BASE_PERIOD is about 41.67kHz and SERVO_PERIOD is 1kHz? Yes I'm guessing the encoder edges are counted between BASE_PERIOD Ticks to determine spindle velocity? Is that correct? Yes That the trajectory planner calculates a new velocity relative to the spindle every SERVO_PERIOD? In other words the step rate to say the Z axis for threading is changed (or left the same) every 1mS. Yes Have I got that right? Just looking for an overall simple description. Yep Thanks John ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users Peter Wallace Mesa Electronics ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Trajectory planning
Quick question here. The HAL file has two time intervals I believe in nanoseconds? BASE_PERIOD = 24000 SERVO_PERIOD = 100 So BASE_PERIOD is about 41.67kHz and SERVO_PERIOD is 1kHz? I'm guessing the encoder edges are counted between BASE_PERIOD Ticks to determine spindle velocity? Is that correct? That the trajectory planner calculates a new velocity relative to the spindle every SERVO_PERIOD? In other words the step rate to say the Z axis for threading is changed (or left the same) every 1mS. Have I got that right? Just looking for an overall simple description. Thanks John ___ 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
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 st...@pilotltd.net wrote: From: Steve Blackmore st...@pilotltd.net Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: EMC2-Users-List emc-users@lists.sourceforge.net 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)
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)
On 24 April 2012 03:19, Chris Morley chrisinnana...@hotmail.com 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 les.new...@fastmail.co.uk 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=viewcatid=41id=17806limit=6start=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 Hassescott.ha...@gmail.com 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
Exactly, Sam! In fact, I would like to see it modular in such a way as allowing more than one interpreter and motion generator going at the same time (addf motion-controller.0, addf motion-controller.1 etc). This would make it possible to run multispindle/multiturret lathes, and pick place machines with more than one pick place head. -- Ralph Date: Tue, 24 Apr 2012 12:44:35 -0500 From: sam sokolik sa...@empirescreen.com Subject: 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 -- 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
2012/4/24 Ralph Stirling ralph.stirl...@wallawalla.edu: Exactly, Sam! In fact, I would like to see it modular in such a way as allowing more than one interpreter and motion generator going at the same time (addf motion-controller.0, addf motion-controller.1 etc). This would make it possible to run multispindle/multiturret lathes, and pick place machines with more than one pick place head. That would be awesome! I just would like to remind that original EMC was supposed to be used in similar way, as a part of RCS, where multiple EMC instances would get synchronized: http://www.isd.mel.nist.gov/projects/rcslib/ Viesturs -- 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)
2012/4/23 Steve Blackmore st...@pilotltd.net: 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 st...@pilotltd.net: 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 st...@pilotltd.net 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)
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 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 stick sizes, as to be completely negligible, I
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 mai...@mah.priv.at 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 mai...@mah.priv.at 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 Haberlermai...@mah.priv.at 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, Newbie pops in again...
On Sat, 21 Apr 2012 12:26:58 +0200, you wrote: Noticed the lists persistent discussion of the LinucCNC trajectory planning functionality. As a system designer I'm curious about the mentioned rule ability to stop at end of next block and wonder what the rationale for such a rule consist of. As a programmer I would also find it convenient to create functionality who gives the user the possibility to stop at an arbitrary number of future blocks, it may consist of 1,2 ,3 or more. Some FANUC systems seem to have three blocks lookahead I was recently told. That gives the user problems if those blocks consists of comments with no moves I have also been taught... Hi Roger - The ability to stop at the next block is not a show stopper IMO. BUT - Define STOP ;) Do you want to stop gracefully, so you can resume, or do you just want to stop? If you just want to stop and loose position - press the estop button. Should work every time. There is also a stop in axis - I don't know how it behaves though. It may decelerate, or it may just stop? If you want to feed hold, jog away to clear swarf or replace a broken or worn tool or replace an insert, then resume - forget LinuxCNC for now. There is a token feed hold, doesn't allow you to do anything though other than abandon your program. You're OK with Fanuc on this though with the proviso that it doesn't work mid cycle or during subroutines. On the Fanuc systems I've used a feed hold press is registered and operates immediately after a cycle is completed. Dunno about subs - no commercial shop I've had dealings with used them since tape fed systems became obsolete ;) 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 4/22/2012 3:48 PM, andy pugh wrote: On 22 April 2012 16:07, Michael Haberlermai...@mah.priv.at 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/21 Jon Elson el...@pico-systems.com: 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. 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. 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)
On 4/20/2012 6:29 PM, Scott Hasse wrote: Unfortunately, this approach doesn't work well for things like plastic extrusion where it can be difficult to control the extrusion rate precisely. Repraps, etc are able to succeed in part because they take a very naive approach to trajectory planning and can get away with it because of the low moving mass. They basically try to fly around at a consistent speed regardless, and extrude at a constant rate. Yes they have to maintain speed, because any speed change would create over/underdeposition because of the nozzle time constant/overpressure. But also it should be remarked, that Marlin uses up to 32 lines lookahead for which it processes acceleration curves in advance. There is a velocity magnitude, any change of the speed vector less than this velocity will be done without acceleration. Any breaking and accelerating is done so that one reaches this jerk velocity change is reached at corners. From what I understand, EMC would be much slower following a typical 3d-printing gcode than marlin, due to the 1-line lookahead. What however would be nice is blending, and arc step generation, to run through with even more constant velocity. greetings, Bernhard Kubicek -- 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
[Emc-users] Trajectory planning, Newbie pops in again...
Noticed the lists persistent discussion of the LinucCNC trajectory planning functionality. As a system designer I'm curious about the mentioned rule ability to stop at end of next block and wonder what the rationale for such a rule consist of. As a programmer I would also find it convenient to create functionality who gives the user the possibility to stop at an arbitrary number of future blocks, it may consist of 1,2 ,3 or more. Some FANUC systems seem to have three blocks lookahead I was recently told. That gives the user problems if those blocks consists of comments with no moves I have also been taught... / Roger -- 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 el...@pico-systems.com wrote: From: Jon Elson el...@pico-systems.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net 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 el...@pico-systems.com: 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 el...@pico-systems.com: 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 viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Saturday, April 21, 2012, 12:58 PM 2012/4/21 Jon Elson el...@pico-systems.com: 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)
2012/4/20 Scott Hasse scott.ha...@gmail.com: It seems to me that the likelihood of fixing all of the methods of gcode generation such that they don't generate short line segments is approximately zero. Also, it seems that even if a proprietary LinuxCNC gcode extension allowed arbitrary plane arcs, splines, etc. that the likelihood of CAM packages being able to make proper use of that is also approximately zero. Unfortunately it seems to be true :( I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? I do not know, how many people have seen this: http://158.110.28.100/amst08/papers/art837759.pdf This paper shows the difference of the machining velocity, which substantially increases as better code is presented to the cnc controller. It seems that the version in the paper is 2D Nurbs, but Yishin says that they have 3D Nurbs in Araisrobo branch. The only thing I do not get, is how to do the reverse math - describe a line, if (a lot of) points on it are provided. It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. 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)
a useful thing is a specialized editor for gcode that can operate on selected sections of code. one of the editor's operations is to take a gcode selection, and within a tolerance from the original code, produce a more compact chunk of code. the millions of lines of 3d g1 moves are turned into about an order of magnitude shorter chunk consisting of linear and helical interpolations in all three planes. other handy editing features are scaling, rotating, and creating arrays from selected chunks of gcode into new gcode chunks. ..offsetting tool paths, sweeping a selected path along another (think of moulding trim, or extrusions).. --- On Thu, 4/19/12, Viesturs Lācis viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Thursday, April 19, 2012, 11:53 PM 2012/4/20 Scott Hasse scott.ha...@gmail.com: It seems to me that the likelihood of fixing all of the methods of gcode generation such that they don't generate short line segments is approximately zero. Also, it seems that even if a proprietary LinuxCNC gcode extension allowed arbitrary plane arcs, splines, etc. that the likelihood of CAM packages being able to make proper use of that is also approximately zero. Unfortunately it seems to be true :( I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? I do not know, how many people have seen this: http://158.110.28.100/amst08/papers/art837759.pdf This paper shows the difference of the machining velocity, which substantially increases as better code is presented to the cnc controller. It seems that the version in the paper is 2D Nurbs, but Yishin says that they have 3D Nurbs in Araisrobo branch. The only thing I do not get, is how to do the reverse math - describe a line, if (a lot of) points on it are provided. It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. 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)
On 20 April 2012 07:53, Viesturs Lācis viesturs.la...@gmail.com wrote: The only thing I do not get, is how to do the reverse math - describe a line, if (a lot of) points on it are provided. It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. It is relatively straightforward to convert a series of points to a 3D polynomial (a least-squares curve fit will do it) However, that returns a polynomial, which isn't an arc or a line. Then there is the question of what subset of all the points should be fitted at any one time. -- 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 20 April 2012 06:42, Scott Hasse scott.ha...@gmail.com 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. -- 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 20.04.12 09:53, Viesturs Lācis wrote: I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? ... It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. 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. 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? If a curve of ten thousand linear segments were instead one continuous nurb (or whatever), then LinuxCNC would not be expected to stop in a thousandth of an inch at any irrelevant point along the single-segment curve, IIUC. (That's in fact where the much-desired speed improvement would come from.) 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. Manual insertion of Feedrate tweaks is immediately available¹. Holding one's breath waiting for this facility in CAM software is probably inadvisable. But it is not a difficult task for a gcode filter to do nothing but look for a G1 with a Gwhiz, then calculate the deceleration needed to negotiate corners or stop at the end, and bang in a Feedrate adjustment. (For the end, just add up micro-segment lengths until there's enough decelerating distance, then insert the lower feedrate. The gcode filter can look ahead to the end of the longest G1 list of points, if system RAM permits, but a few hundred segments might do.) This is engineering, and we're here to make swarf, with reasonable accuracy, and optimal speed. I don't think that there's any extra merit in a complex mathematical solution. So would something akin to the above let us scoot faster over irregularly curvaceous workpieces? Erik ¹ OK, inserting far enough before the corner to allow deceleration distance would entail totting up roughly the length of the trailing path segments, or allowing plenty. A gcode filter would be a boon. -- In all affairs it's a healthy thing now and then to hang a question mark on the things you have long taken for granted. - Bertrand Russell -- 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 April 2012 09:52, Erik Christiansen dva...@internode.on.net wrote: 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? Actually, I am unclear if this refers to the ability to stop if the user presses a Stop button, or is how the controller makes sure that it can handle a right-angle turn. The former seems unnecessary, but the latter really is a lookahead problem. -- 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)
if speed is an issue, consider the solution of being a doctor: have patience. --- On Thu, 4/19/12, Stephen Dubovsky smdubov...@gmail.com wrote: From: Stephen Dubovsky smdubov...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Thursday, April 19, 2012, 6:04 AM I don't think that would work well. Think about the situation where you have several (mostly straight) short line segments, the last being the shortest, and then a 90deg turn. I think many would find it unacceptable to overshoot the last segment 10thou if you were doing something like inside corners. I only have two machines running linuxcnc so far (both commercial gantry routers, both steppers) as a hobby so have limited experience but I don't think the look ahead is that big of an issue *IF* the machine has decent acceleration capability is properly tuned to use it. I can process complex 3d profiling in wood on the big one right about the limit of my spindle hp (~100ipm w/ a 1/2 ballmill). Yes, it probably does limit me slightly when doing a final finishing pass w/ a smaller bit. When Im doing aluminum sheet at ~30ipm its a total non-issue though. I have a factory CNC 3hp Wells Index knee mill w/ DC servos that Im retrofitting (slowly.) If LinuxCNC can keep up on the gantrys it will be no problem FOR ME on the knee mill. But I see how it might be a limiting factor for a modern Hass class speed machine w/ massive spindle hp and feed rates possible when profiling. But those would typ have very high acceleration levels to match. Machines w/ very low acceleration levels will suffer the most as they won't be allowed to get up to speed if you can't slow them down very fast. Its like what they say about driving at night: Dont outdrive your headlights :) More segments of look ahead would no doubt be an improvement. But how much? (seriously, I think we'd all like to know.) Can people give examples of machines and jobs where cutting speed is a problem due to limited look ahead? I don't have enough experience to even be able to guess the magnitude of the issue. Best, Stephen I think that if this is actually the case it would make more sense to set a lower limit on this distance (INI file setting?) so that the motion system would guarantee stopping in the next program line or (for example) 0.01 -- 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)
feedrate is still a gotcha for short arc segments on some machine controls. g17 g2 arclength around .005, z change 2 faults the servo system at f20. turns out the feed is also interpolated in one of the three usable control interpolation planes, leaving a coordindated helix out of bounds for the servo system in some cases. i'm wondering how linuxcnc handles helical feedrates. have not done any experiments, except for a couple of xa feeds that didnt go intuitively. --- On Fri, 4/20/12, Erik Christiansen dva...@internode.on.net wrote: From: Erik Christiansen dva...@internode.on.net Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 1:52 AM On 20.04.12 09:53, Viesturs Lācis wrote: I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? ... It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. 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. 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? If a curve of ten thousand linear segments were instead one continuous nurb (or whatever), then LinuxCNC would not be expected to stop in a thousandth of an inch at any irrelevant point along the single-segment curve, IIUC. (That's in fact where the much-desired speed improvement would come from.) 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. Manual insertion of Feedrate tweaks is immediately available¹. Holding one's breath waiting for this facility in CAM software is probably inadvisable. But it is not a difficult task for a gcode filter to do nothing but look for a G1 with a Gwhiz, then calculate the deceleration needed to negotiate corners or stop at the end, and bang in a Feedrate adjustment. (For the end, just add up micro-segment lengths until there's enough decelerating distance, then insert the lower feedrate. The gcode filter can look ahead to the end of the longest G1 list of points, if system RAM permits, but a few hundred segments might do.) This is engineering, and we're here to make swarf, with reasonable accuracy, and optimal speed. I don't think that there's any extra merit in a complex mathematical solution. So would something akin to the above let us scoot faster over irregularly curvaceous workpieces? Erik ¹ OK, inserting far enough before the corner to allow deceleration distance would entail totting up roughly the length of the trailing path segments, or allowing plenty. A gcode filter would be a boon. -- In all affairs it's a healthy thing now and then to hang a question mark on the things you have long taken for granted. - Bertrand Russell -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
that makes the problem four dimensional: for each considered point, there is also an axis of relevance to the consideration. --- On Fri, 4/20/12, andy pugh bodge...@gmail.com wrote: From: andy pugh bodge...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 1:44 AM On 20 April 2012 07:53, Viesturs Lācis viesturs.la...@gmail.com wrote: The only thing I do not get, is how to do the reverse math - describe a line, if (a lot of) points on it are provided. It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. It is relatively straightforward to convert a series of points to a 3D polynomial (a least-squares curve fit will do it) However, that returns a polynomial, which isn't an arc or a line. Then there is the question of what subset of all the points should be fitted at any one time. -- 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 -- 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/20 Erik Christiansen dva...@internode.on.net: 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. As discussed previously, converting small lines to arcs is not a solution, because of different issues, associated with arcs, that are not in xy, xz or yz planes, see Chris Radek's messages in nonplanar arcs thread. Nurbs do not have all those negative aspects. They even provide additional benefit - they can describe splines and other nasty geometry, that is difficult to express even with arcs. And it seems that LinuxCNC already is 3D Nurbs capable, so it is not xy, xz or yz plane dependable. The only trick is the math to convert from series of points to Nurbs. 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? If a curve of ten thousand linear segments were instead one continuous nurb (or whatever), then LinuxCNC would not be expected to stop in a thousandth of an inch at any irrelevant point along the single-segment curve, IIUC. (That's in fact where the much-desired speed improvement would come from.) Well, if there are many small lines that create a smooth arc, then the Must be able to come to a dead stop within the current line segment approach sucks. But what to do, if the radius of smooth arc suddenly decreases or even ends with a sharp corner? Like the butterfly shape in that paper I posted link to. Simply removing Must be able to come to a dead stop within the current line segment will be disastrous, so some changes are needed anyway. I have no idea, what does it take to expand the lookahead distance to several lines or even more. 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 means that some preprocessor would need to be created. And as You mentioned, the filter would need to know, how fast machine can decelerate, so that it knows, where exactly to put the new feedrate value. 2012/4/20 andy pugh bodge...@gmail.com: It is relatively straightforward to convert a series of points to a 3D polynomial (a least-squares curve fit will do it) However, that returns a polynomial, which isn't an arc or a line. Based on the looks of those Nurbs splines, I _think_ that it is some kind of polynomial that describes it... I downloaded the Rhino 4.0 demo version. It has a function to convert a mesh of points into a Nurbs surface. I guess that this means - they can be converted, but I just have no idea how, because I do not really understand that Nurbs math. I tried to draw some splines in Rhino, but it did not really help me understand them better. 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 me point out that the underlying issue is the current line-by-line G-code interpretation model (aka 'limited lookahead') any view or optimization beyond that scope necessarily involves some path history which has been addressed by introducing 'queues' at considerable extra complexity; for instance naive cam detection (the chained points queue) or offset curve computation (queued canon). 'queue' is a bit of a misnomer - these are basically ad-hoc polylines extending beyond a single gcode line to retain history, on which some operation (NCD, CRC) eventually is applied. to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. I can imagine a different approach: drop the line-by-line interpretation model, and switch to a mode where the interpreter would run either to completion or the next queue buster (tool change, probe, hal pin read) autonomously, and generate a path model internally. This means basically 'lookahead to the end of program or the next queue buster', which results in one or several polylines. Transformations like the ones discussed here, but also NCD and CRC could be done on a single path data structure instead of various ad-hoc structures, before generating any canon commands. I would think that moving these operations into the interpreter would also benefit regression testing - since several key operations like NCD, CRC and offsetting is currently wrapped into emcanon.cc their results cannot fully be subjected to regression tests with rs274 whose canon layer doesnt have these features. Downsides I can think of: More memory is needed to retain the path. The interpreter state model in task needs to be reviewed to cope with this approach. Also, I use the term polylines a bit sloppy, it's not just lines and arcs but also about probe and tapping. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. - Michael Am 20.04.2012 um 08:53 schrieb Viesturs Lācis: 2012/4/20 Scott Hasse scott.ha...@gmail.com: It seems to me that the likelihood of fixing all of the methods of gcode generation such that they don't generate short line segments is approximately zero. Also, it seems that even if a proprietary LinuxCNC gcode extension allowed arbitrary plane arcs, splines, etc. that the likelihood of CAM packages being able to make proper use of that is also approximately zero. Unfortunately it seems to be true :( I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? I do not know, how many people have seen this: http://158.110.28.100/amst08/papers/art837759.pdf This paper shows the difference of the machining velocity, which substantially increases as better code is presented to the cnc controller. It seems that the version in the paper is 2D Nurbs, but Yishin says that they have 3D Nurbs in Araisrobo branch. The only thing I do not get, is how to do the reverse math - describe a line, if (a lot of) points on it are provided. It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. 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)
wikipedia puts a somewhat different spin on nurbs. see the use section of the article, first paragraph. --- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 3:37 AM 2012/4/20 Erik Christiansen dva...@internode.on.net: 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. As discussed previously, converting small lines to arcs is not a solution, because of different issues, associated with arcs, that are not in xy, xz or yz planes, see Chris Radek's messages in nonplanar arcs thread. Nurbs do not have all those negative aspects. They even provide additional benefit - they can describe splines and other nasty geometry, that is difficult to express even with arcs. And it seems that LinuxCNC already is 3D Nurbs capable, so it is not xy, xz or yz plane dependable. The only trick is the math to convert from series of points to Nurbs. 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? If a curve of ten thousand linear segments were instead one continuous nurb (or whatever), then LinuxCNC would not be expected to stop in a thousandth of an inch at any irrelevant point along the single-segment curve, IIUC. (That's in fact where the much-desired speed improvement would come from.) Well, if there are many small lines that create a smooth arc, then the Must be able to come to a dead stop within the current line segment approach sucks. But what to do, if the radius of smooth arc suddenly decreases or even ends with a sharp corner? Like the butterfly shape in that paper I posted link to. Simply removing Must be able to come to a dead stop within the current line segment will be disastrous, so some changes are needed anyway. I have no idea, what does it take to expand the lookahead distance to several lines or even more. 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 means that some preprocessor would need to be created. And as You mentioned, the filter would need to know, how fast machine can decelerate, so that it knows, where exactly to put the new feedrate value. 2012/4/20 andy pugh bodge...@gmail.com: It is relatively straightforward to convert a series of points to a 3D polynomial (a least-squares curve fit will do it) However, that returns a polynomial, which isn't an arc or a line. Based on the looks of those Nurbs splines, I _think_ that it is some kind of polynomial that describes it... I downloaded the Rhino 4.0 demo version. It has a function to convert a mesh of points into a Nurbs surface. I guess that this means - they can be converted, but I just have no idea how, because I do not really understand that Nurbs math. I tried to draw some splines in Rhino, but it did not really help me understand them better. 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)
On 20 April 2012 11:51, Michael Haberler mai...@mah.priv.at wrote: 'queue' is a bit of a misnomer - these are basically ad-hoc polylines extending beyond a single gcode line to retain history, It seems I might have been misunderstanding how LinuxCNC works. I thought that the G-code was interpreted into a queue of moves, and that in some situations the entire program might be in the queue (this was something mentioned in the why touch off while paused is hard document). Looking through the code I have seen sections that appear to convert all moves into a queue of time-step by time-step position requests in the real-time layer. Perhaps I have been making unwarranted assumptions about the upstream code. Would it be possible to give a precis of how LinuxCNC works, perhaps pointing out which code module each section of processing occurs in, and distinguishing which parts are realtime and which are userland? I have tried to follow it, but got caught in a maze of classes all alike... -- 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)
2012/4/20 Michael Haberler mai...@mah.priv.at: to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. It seems like I did not express it in a proper way: My idea was to adjust Ken's suggestion with Nurbs. Basically it would be a filter, which would take g-code file with all the tiny G1 moves and return the same path, expressed with Nurbs. User then can save the output and reuse later. Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). 2012/4/20 charles green xxzzb...@yahoo.com: wikipedia puts a somewhat different spin on nurbs. see the use section of the article, first paragraph. Yes, I looked also at the Construction of the basis functions section and did not get much out of it. Well, I did get nothing out of it :)) 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)
Am 20.04.2012 um 13:40 schrieb Viesturs Lācis: Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). For a single purpose-tool: probably yes, but then this fixes exactly your current problem and nothing else. I hinted at a fundamental architectural issue, which either can be kludged around as we go, or addressed. The suggestion I made wrt to the interpretation model addresses much more than the current topic. Some are: - unifying the line-oriented handling in task with the de-facto block structured rs274ngc language, leading to: - eradicating the convoluted MDI handling in task and interpreter, with its assorted stream of bugs. - substantially simplifying the remapping code, which is unnecessarily complicated due to this mismatch. - providing a common base for any 'global optimization on path segments', weeding out various ad-hoc structures here and there. - providing for a cleaner functional separation of the interpreter and canon layers than we currently have, which is a precondition IMV to any attempts about adding a new language front end if one were to do so. I'm not saying it's easy or it will fix your problem right away - I'm saying there are upsides to it long term. - Michael -- 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)
another operation of the specialized gcode text editor: convert the selected chunk of gcode/nurbs to a chunk of nurbs/gcode. i dont have a good idea of what a nurbs nc file might be like, but whatever it is, it still has to result in more or less programmed machine tool positions. the advantage in such case seems to be more in ease of user manipulating the control code. at the machine level, the actuators are going to move stepwise unless the whole spiel is somehow analog. so the question then is how to parse enormous sequences of linear steps into code friendly sections. g1 is straitforward enough, but too slow because the physical impementation involves inertia. g2/3 improves by implying the g1 to g1 transitions within itself. would there be any advantage to making each physical machine axis into a couple of circular movements, one going along R from 0 to 360 degrees while the other rotates around 2R to make the motion linear? ..a rotary differential movement instead of a linear movement. ..the arbitrary interpolation schemes seem to be limited by the compliance character of the machine movement. maybe the solution is a more fluid machine movement somewhere beyond three orthogonal screws? --- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 4:40 AM 2012/4/20 Michael Haberler mai...@mah.priv.at: to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. It seems like I did not express it in a proper way: My idea was to adjust Ken's suggestion with Nurbs. Basically it would be a filter, which would take g-code file with all the tiny G1 moves and return the same path, expressed with Nurbs. User then can save the output and reuse later. Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). 2012/4/20 charles green xxzzb...@yahoo.com: wikipedia puts a somewhat different spin on nurbs. see the use section of the article, first paragraph. Yes, I looked also at the Construction of the basis functions section and did not get much out of it. Well, I did get nothing out of it :)) 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)
2012/4/20 charles green xxzzb...@yahoo.com: i dont have a good idea of what a nurbs nc file might be like, http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NURBS See the pdf (there is a link at the bottom) for the velocity difference, when the same toolpath is machined either by small G1 moves or by Nurbs splines. 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)
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? On Apr 20, 2012 8:00 AM, charles green xxzzb...@yahoo.com wrote: another operation of the specialized gcode text editor: convert the selected chunk of gcode/nurbs to a chunk of nurbs/gcode. i dont have a good idea of what a nurbs nc file might be like, but whatever it is, it still has to result in more or less programmed machine tool positions. the advantage in such case seems to be more in ease of user manipulating the control code. at the machine level, the actuators are going to move stepwise unless the whole spiel is somehow analog. so the question then is how to parse enormous sequences of linear steps into code friendly sections. g1 is straitforward enough, but too slow because the physical impementation involves inertia. g2/3 improves by implying the g1 to g1 transitions within itself. would there be any advantage to making each physical machine axis into a couple of circular movements, one going along R from 0 to 360 degrees while the other rotates around 2R to make the motion linear? ..a rotary differential movement instead of a linear movement. ..the arbitrary interpolation schemes seem to be limited by the compliance character of the machine movement. maybe the solution is a more fluid machine movement somewhere beyond three orthogonal screws? --- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 4:40 AM 2012/4/20 Michael Haberler mai...@mah.priv.at: to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. It seems like I did not express it in a proper way: My idea was to adjust Ken's suggestion with Nurbs. Basically it would be a filter, which would take g-code file with all the tiny G1 moves and return the same path, expressed with Nurbs. User then can save the output and reuse later. Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). 2012/4/20 charles green xxzzb...@yahoo.com: wikipedia puts a somewhat different spin on nurbs. see the use section of the article, first paragraph. Yes, I looked also at the Construction of the basis functions section and did not get much out of it. Well, I did get nothing out of it :)) 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 -- 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/20/2012 4:52 AM, Erik Christiansen wrote: On 20.04.12 09:53, Viesturs Lācis wrote: I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lermankenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? ... It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. 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. 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? If a curve of ten thousand linear segments were instead one continuous nurb (or whatever), then LinuxCNC would not be expected to stop in a thousandth of an inch at any irrelevant point along the single-segment curve, IIUC. (That's in fact where the much-desired speed improvement would come from.) The job of the system is to follow a path *exactly* or within specified limits. In the usual case, the limits are zero. That means if there are two non-colinear line segments, a machine with finite acceleration machine *must* stop at the end of the first. This causes two types of problems: 1 -- The system is slower than it could be 2 -- Uneven speed causes undesirable artifacts Let's consider the alternatives: 1 -- Change the CAM system so that it generates better code. Since there are multiple CAM systems over which we have little control, this us not feasible. 2 -- Modify LinuxCNC so that it can follow a gcode path within a specified tolerance at a higher, more consistent rate. 3 -- Provide a filter (whether integrated with LinuxCNC or completely separate) that convert bad paths to good paths using a specified tolerance. Given a standalone LinuxCNC compatible parser, I suggest that #3, would provide a basis for experimentation and development that could later be more closely integrated into Linux CNC. Regards, Ken 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. Manual insertion of Feedrate tweaks is immediately available¹. Holding one's breath waiting for this facility in CAM software is probably inadvisable. But it is not a difficult task for a gcode filter to do nothing but look for a G1 with a Gwhiz, then calculate the deceleration needed to negotiate corners or stop at the end, and bang in a Feedrate adjustment. (For the end, just add up micro-segment lengths until there's enough decelerating distance, then insert the lower feedrate. The gcode filter can look ahead to the end of the longest G1 list of points, if system RAM permits, but a few hundred segments might do.) This is engineering, and we're here to make swarf, with reasonable accuracy, and optimal speed. I don't think that there's any extra merit in a complex mathematical solution. So would something akin to the above let us scoot faster over irregularly curvaceous workpieces? Erik ¹ OK, inserting far enough before the corner to allow deceleration distance would entail totting up roughly the length of the trailing path segments, or allowing plenty. A gcode filter would be a boon. -- 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)
why not abandon rs274ngc almost entirely? keep it as a supported file type like ascii or html, but the machine control transforms it into nurbs or whatever for functional purposes? --- On Fri, 4/20/12, Michael Haberler mai...@mah.priv.at wrote: From: Michael Haberler mai...@mah.priv.at Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 5:25 AM Am 20.04.2012 um 13:40 schrieb Viesturs Lācis: Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). For a single purpose-tool: probably yes, but then this fixes exactly your current problem and nothing else. I hinted at a fundamental architectural issue, which either can be kludged around as we go, or addressed. The suggestion I made wrt to the interpretation model addresses much more than the current topic. Some are: - unifying the line-oriented handling in task with the de-facto block structured rs274ngc language, leading to: - eradicating the convoluted MDI handling in task and interpreter, with its assorted stream of bugs. - substantially simplifying the remapping code, which is unnecessarily complicated due to this mismatch. - providing a common base for any 'global optimization on path segments', weeding out various ad-hoc structures here and there. - providing for a cleaner functional separation of the interpreter and canon layers than we currently have, which is a precondition IMV to any attempts about adding a new language front end if one were to do so. I'm not saying it's easy or it will fix your problem right away - I'm saying there are upsides to it long term. - Michael -- 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)
..the weakness the borg find irresistably delicious. also, the, what was the author thinking question, if you've ever studied soft literature. also, the shyness of REMarks in the harder literature. --- On Fri, 4/20/12, andy pugh bodge...@gmail.com wrote: From: andy pugh bodge...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 4:07 AM On 20 April 2012 11:51, Michael Haberler mai...@mah.priv.at wrote: 'queue' is a bit of a misnomer - these are basically ad-hoc polylines extending beyond a single gcode line to retain history, It seems I might have been misunderstanding how LinuxCNC works. I thought that the G-code was interpreted into a queue of moves, and that in some situations the entire program might be in the queue (this was something mentioned in the why touch off while paused is hard document). Looking through the code I have seen sections that appear to convert all moves into a queue of time-step by time-step position requests in the real-time layer. Perhaps I have been making unwarranted assumptions about the upstream code. Would it be possible to give a precis of how LinuxCNC works, perhaps pointing out which code module each section of processing occurs in, and distinguishing which parts are realtime and which are userland? I have tried to follow it, but got caught in a maze of classes all alike... -- 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 -- 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)
#3 - facebook style like --- On Fri, 4/20/12, Kenneth Lerman kenneth.ler...@se-ltd.com wrote: From: Kenneth Lerman kenneth.ler...@se-ltd.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 6:06 AM On 4/20/2012 4:52 AM, Erik Christiansen wrote: On 20.04.12 09:53, Viesturs Lācis wrote: I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lermankenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? ... It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. 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. 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? If a curve of ten thousand linear segments were instead one continuous nurb (or whatever), then LinuxCNC would not be expected to stop in a thousandth of an inch at any irrelevant point along the single-segment curve, IIUC. (That's in fact where the much-desired speed improvement would come from.) The job of the system is to follow a path *exactly* or within specified limits. In the usual case, the limits are zero. That means if there are two non-colinear line segments, a machine with finite acceleration machine *must* stop at the end of the first. This causes two types of problems: 1 -- The system is slower than it could be 2 -- Uneven speed causes undesirable artifacts Let's consider the alternatives: 1 -- Change the CAM system so that it generates better code. Since there are multiple CAM systems over which we have little control, this us not feasible. 2 -- Modify LinuxCNC so that it can follow a gcode path within a specified tolerance at a higher, more consistent rate. 3 -- Provide a filter (whether integrated with LinuxCNC or completely separate) that convert bad paths to good paths using a specified tolerance. Given a standalone LinuxCNC compatible parser, I suggest that #3, would provide a basis for experimentation and development that could later be more closely integrated into Linux CNC. Regards, Ken 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. Manual insertion of Feedrate tweaks is immediately available¹. Holding one's breath waiting for this facility in CAM software is probably inadvisable. But it is not a difficult task for a gcode filter to do nothing but look for a G1 with a Gwhiz, then calculate the deceleration needed to negotiate corners or stop at the end, and bang in a Feedrate adjustment. (For the end, just add up micro-segment lengths until there's enough decelerating distance, then insert the lower feedrate. The gcode filter can look ahead to the end of the longest G1 list of points, if system RAM permits, but a few hundred segments might do.) This is engineering, and we're here to make swarf, with reasonable accuracy, and optimal speed. I don't think that there's any extra merit in a complex mathematical solution. So would something akin to the above let us scoot faster over irregularly curvaceous workpieces? Erik ¹ OK, inserting far enough before the corner to allow deceleration distance would entail totting up roughly the length of the trailing path segments, or allowing plenty. A gcode filter would be a boon. -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
2012/4/20 Kenneth Lerman kenneth.ler...@se-ltd.com: Let's consider the alternatives: 1 -- Change the CAM system so that it generates better code. Since there are multiple CAM systems over which we have little control, this us not feasible. Yupp, unless somebody has might and resources to develop one... 2 -- Modify LinuxCNC so that it can follow a gcode path within a specified tolerance at a higher, more consistent rate. Already in place with G64 Px command 3 -- Provide a filter (whether integrated with LinuxCNC or completely separate) that convert bad paths to good paths using a specified tolerance. Given a standalone LinuxCNC compatible parser, I suggest that #3, would provide a basis for experimentation and development that could later be more closely integrated into Linux CNC. I also agree that separate filter would be better. Because the problem is solely in the g-code, so the filter to sort out the code is needed. With proper code the existing LinuxCNC can completely handle the job. 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)
aye, lad. read on a couple more lines. --- On Fri, 4/20/12, Stuart Stevenson stus...@gmail.com wrote: From: Stuart Stevenson stus...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 6:05 AM 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? On Apr 20, 2012 8:00 AM, charles green xxzzb...@yahoo.com wrote: another operation of the specialized gcode text editor: convert the selected chunk of gcode/nurbs to a chunk of nurbs/gcode. i dont have a good idea of what a nurbs nc file might be like, but whatever it is, it still has to result in more or less programmed machine tool positions. the advantage in such case seems to be more in ease of user manipulating the control code. at the machine level, the actuators are going to move stepwise unless the whole spiel is somehow analog. so the question then is how to parse enormous sequences of linear steps into code friendly sections. g1 is straitforward enough, but too slow because the physical impementation involves inertia. g2/3 improves by implying the g1 to g1 transitions within itself. would there be any advantage to making each physical machine axis into a couple of circular movements, one going along R from 0 to 360 degrees while the other rotates around 2R to make the motion linear? ..a rotary differential movement instead of a linear movement. ..the arbitrary interpolation schemes seem to be limited by the compliance character of the machine movement. maybe the solution is a more fluid machine movement somewhere beyond three orthogonal screws? --- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 4:40 AM 2012/4/20 Michael Haberler mai...@mah.priv.at: to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. It seems like I did not express it in a proper way: My idea was to adjust Ken's suggestion with Nurbs. Basically it would be a filter, which would take g-code file with all the tiny G1 moves and return the same path, expressed with Nurbs. User then can save the output and reuse later. Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). 2012/4/20 charles green xxzzb...@yahoo.com: wikipedia puts a somewhat different spin on nurbs. see the use section of the article, first paragraph. Yes, I looked also at the Construction of the basis functions section and did not get much out of it. Well, I did get nothing out of it :)) 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 -- 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Well, then, if G02/G03 and NURBS use an approximation based on a set of many short straight lines - why is this not implemented in a control to handle the gcode file as is? On Apr 20, 2012 8:40 AM, charles green xxzzb...@yahoo.com wrote: aye, lad. read on a couple more lines. --- On Fri, 4/20/12, Stuart Stevenson stus...@gmail.com wrote: From: Stuart Stevenson stus...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 6:05 AM 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? On Apr 20, 2012 8:00 AM, charles green xxzzb...@yahoo.com wrote: another operation of the specialized gcode text editor: convert the selected chunk of gcode/nurbs to a chunk of nurbs/gcode. i dont have a good idea of what a nurbs nc file might be like, but whatever it is, it still has to result in more or less programmed machine tool positions. the advantage in such case seems to be more in ease of user manipulating the control code. at the machine level, the actuators are going to move stepwise unless the whole spiel is somehow analog. so the question then is how to parse enormous sequences of linear steps into code friendly sections. g1 is straitforward enough, but too slow because the physical impementation involves inertia. g2/3 improves by implying the g1 to g1 transitions within itself. would there be any advantage to making each physical machine axis into a couple of circular movements, one going along R from 0 to 360 degrees while the other rotates around 2R to make the motion linear? ..a rotary differential movement instead of a linear movement. ..the arbitrary interpolation schemes seem to be limited by the compliance character of the machine movement. maybe the solution is a more fluid machine movement somewhere beyond three orthogonal screws? --- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 4:40 AM 2012/4/20 Michael Haberler mai...@mah.priv.at: to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. It seems like I did not express it in a proper way: My idea was to adjust Ken's suggestion with Nurbs. Basically it would be a filter, which would take g-code file with all the tiny G1 moves and return the same path, expressed with Nurbs. User then can save the output and reuse later. Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). 2012/4/20 charles green xxzzb...@yahoo.com: wikipedia puts a somewhat different spin on nurbs. see the use section of the article, first paragraph. Yes, I looked also at the Construction of the basis functions section and did not get much out of it. Well, I did get nothing out of it :)) 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 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Why cannot the control handle the code without the need to filter the short lines into a more usable form? On Apr 20, 2012 8:55 AM, Stuart Stevenson stus...@gmail.com wrote: Well, then, if G02/G03 and NURBS use an approximation based on a set of many short straight lines - why is this not implemented in a control to handle the gcode file as is? On Apr 20, 2012 8:40 AM, charles green xxzzb...@yahoo.com wrote: aye, lad. read on a couple more lines. --- On Fri, 4/20/12, Stuart Stevenson stus...@gmail.com wrote: From: Stuart Stevenson stus...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 6:05 AM 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? On Apr 20, 2012 8:00 AM, charles green xxzzb...@yahoo.com wrote: another operation of the specialized gcode text editor: convert the selected chunk of gcode/nurbs to a chunk of nurbs/gcode. i dont have a good idea of what a nurbs nc file might be like, but whatever it is, it still has to result in more or less programmed machine tool positions. the advantage in such case seems to be more in ease of user manipulating the control code. at the machine level, the actuators are going to move stepwise unless the whole spiel is somehow analog. so the question then is how to parse enormous sequences of linear steps into code friendly sections. g1 is straitforward enough, but too slow because the physical impementation involves inertia. g2/3 improves by implying the g1 to g1 transitions within itself. would there be any advantage to making each physical machine axis into a couple of circular movements, one going along R from 0 to 360 degrees while the other rotates around 2R to make the motion linear? ..a rotary differential movement instead of a linear movement. ..the arbitrary interpolation schemes seem to be limited by the compliance character of the machine movement. maybe the solution is a more fluid machine movement somewhere beyond three orthogonal screws? --- On Fri, 4/20/12, Viesturs Lācis viesturs.la...@gmail.com wrote: From: Viesturs Lācis viesturs.la...@gmail.com Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Date: Friday, April 20, 2012, 4:40 AM 2012/4/20 Michael Haberler mai...@mah.priv.at: to stay within that model, for instance the polyline-to-NURBS conversion would require yet another ad-hoce path 'queue'. The other option is to go the preprocessor route as Ken proposed. some problems cannot be addressed with a deeper interpretation-time path model like blending, which must be done at runtime due to external inputs like feed override which can impact on the actual path. It seems like I did not express it in a proper way: My idea was to adjust Ken's suggestion with Nurbs. Basically it would be a filter, which would take g-code file with all the tiny G1 moves and return the same path, expressed with Nurbs. User then can save the output and reuse later. Michael, all the things You listed to be changed makes me think that filter is much easier to do (except the math part). 2012/4/20 charles green xxzzb...@yahoo.com: wikipedia puts a somewhat different spin on nurbs. see the use section of the article, first paragraph. Yes, I looked also at the Construction of the basis functions section and did not get much out of it. Well, I did get nothing out of it :)) 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)
No, I was actually working with an OEM who sold a sign software package that generated Gcode (very expensive). The problem was that their software generated way too many short segments for no good reason which caused problems on the machine controls (it wasn't LinuxCNC or Mach3). They simply refused to alter their code saying that the machine control should be able to handle as many short segments as they want to throw at it and still run at high speeds. If this is OEM stuff with reasonable quantities involved, the software supplier was being very short sighted by refusing to change. Arc matching and other optimizations are not that difficult. The machine control choked badly (no surprise) and was running 10 or 15% of the desired speed. In the end, I don't think that anything was ever fixed. And the machines still run slowly. Perhaps I should show them SheetCam ;-) Artists and some of the people associated with artists tend to live in different realm, reality, or dimension. ;-) Logic is oftentimes discarded! Some artistic work can be really nasty. I spent quite a lot of time on SheetCam's optimization to try to handle some of the really messy decorative work that was being fed into it. The absolute worst is stuff that has been through raster-vector conversion. Some of that is just ridiculous. Les -- 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 April 2012 14:57, Stuart Stevenson stus...@gmail.com wrote: Why cannot the control handle the code without the need to filter the short lines into a more usable form? Because _those_ straight lines are a list of moment-by-moment axis positions, incorporating acceleration and velocity limits and tool offsets. -- 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)
S/buy/but On Apr 20, 2012 10:18 AM, Stuart Stevenson stus...@gmail.com wrote: I was making a comparison between the short lines generated by G02/G03 being processed rapidly and a program generating the exact same geometry buy with short linear moves. Cam packages can output the code either way. On Apr 20, 2012 10:08 AM, andy pugh bodge...@gmail.com wrote: On 20 April 2012 14:57, Stuart Stevenson stus...@gmail.com wrote: Why cannot the control handle the code without the need to filter the short lines into a more usable form? Because _those_ straight lines are a list of moment-by-moment axis positions, incorporating acceleration and velocity limits and tool offsets. -- 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 -- 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 making a comparison between the short lines generated by G02/G03 being processed rapidly and a program generating the exact same geometry buy with short linear moves. Cam packages can output the code either way. On Apr 20, 2012 10:08 AM, andy pugh bodge...@gmail.com wrote: On 20 April 2012 14:57, Stuart Stevenson stus...@gmail.com wrote: Why cannot the control handle the code without the need to filter the short lines into a more usable form? Because _those_ straight lines are a list of moment-by-moment axis positions, incorporating acceleration and velocity limits and tool offsets. -- 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 -- 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 Fri, Apr 20, 2012 at 9:55 AM, Stuart Stevenson stus...@gmail.com wrote: Well, then, if G02/G03 and NURBS use an approximation based on a set of many short straight lines - why is this not implemented in a control to handle the gcode file as is? Doesn't this conflict with the often expressed desire to start/restart in the middle of a gcode program? That's the issue I see. Solutions requiring special programs likely would be a waste of effort unless someone wrote a cam program to use them. Don't see this happening. For those that want something different, linuxCNC is an ideal platform for experimentation due to its modular nature. Eric -- 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/20 Stuart Stevenson stus...@gmail.com: I was making a comparison between the short lines generated by G02/G03 being processed rapidly and a program generating the exact same geometry buy with short linear moves. Cam packages can output the code either way. Yes, but the difference is that motion controller takes the arc, defined by G2/G3 and splitts it in small linears and it knows, where exactly that arc will end and can prepare the motion accordingly. But it does not know, what kind of shape do those tiny g-code lines describe. IMHO it needs not only to look up hundreds of lines, but also some additional logics to make a decision, what is that a shape and how should it be treated. 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)
++On Fri, 20 Apr 2012 09:53:05 +0300 Viesturs Lācis viesturs.la...@gmail.com wrote: 2012/4/20 Scott Hasse scott.ha...@gmail.com: It seems to me that the likelihood of fixing all of the methods of gcode generation such that they don't generate short line segments is approximately zero. Also, it seems that even if a proprietary LinuxCNC gcode extension allowed arbitrary plane arcs, splines, etc. that the likelihood of CAM packages being able to make proper use of that is also approximately zero. Unfortunately it seems to be true :( I was thinking about Kenneth's idea: 2012/4/19 Kenneth Lerman kenneth.ler...@se-ltd.com: Is anyone here interested in writing a filter that takes as input a tolerance (error band) and a sequence of motions (arcs and line segments) and generates a new sequence of motions that duplicates the original within the error band? It sounds like that would be one way to address the problem. Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? I do not know, how many people have seen this: http://158.110.28.100/amst08/papers/art837759.pdf This paper shows the difference of the machining velocity, which substantially increases as better code is presented to the cnc controller. It seems that the version in the paper is 2D Nurbs, but Yishin says that they have 3D Nurbs in Araisrobo branch. The only thing I do not get, is how to do the reverse math - describe a line, if (a lot of) points on it are provided. It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. Viesturs Just thinking out loud; usually gets me in trouble. ;-) However: Long before I knew anything about g-code it seemed obvious that any capable machine would be able to use at least a 2nd order polynomial. Some years ago I tried fitting curved sections of a lockplate (think flintlock or percussion). They would fit over distances of one or two inches with a tolerance of +- 0.001 which I think is reasonable since few of us can cut to better than a thou anyway. ;-) Now to extend the above: as long as we constrain ourselves to work external to the machine we are stuck with short segments. (no proof included). However, adding internal functionality to emc in a manner much like G2/G3 I think has merit. a. add nurbs, apparently already done the ara... branch. b. extend G2/G2 to the general case ... ellipse which collapses to a circle when the axes are colinear(?). c. add a polynomial of nth-order. Maybe nurbs actually takes care of the other cases but I'm not at all certain of that. Since those would be calculated by traj the movement for a block of code would be longer and hopefully much smoother; much like the present G2/G3. Unfortunately, I can conceptualize things that I don't have the brain power to program. Darned! Just my tuppence. 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
2012/4/20 dave dengv...@charter.net: c. add a polynomial of nth-order. How would You tell the trajectory planner, which exactly section of the plynomial's graph to use between 2 given points? 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)
Unfortunately, this approach doesn't work well for things like plastic extrusion where it can be difficult to control the extrusion rate precisely. Repraps, etc are able to succeed in part because they take a very naive approach to trajectory planning and can get away with it because of the low moving mass. They basically try to fly around at a consistent speed regardless, and extrude at a constant rate. The output of the skeinforge tool chain is also totally line segments. As far as I understand it, this makes LinuxCNC somewhat unsuitable for this very fast-growing and cool DIY CNC market segment. Two cents, Scott On Apr 20, 2012, at 4:33 AM, charles green xxzzb...@yahoo.com wrote: if speed is an issue, consider the solution of being a doctor: have patience. -- 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: Is there a way to create a filter that would convert those small, tiny G1s into a 3D Nurbs lines? snip The only thing I do not get, is how to do the reverse math - describe a line, if (a lot of) points on it are provided. It does not seem to be problem finding formulas on the web to calculate a coordinates of a point on a described line. But reversing that seems difficult. Well, this doesn't really destroy information, but it spreads it out, and you have to take all those points and turn them back into a curve. So, you have to identify a range of points and do a curve fit. If it is a very messy fit, you have to narrow the range and fit it again. If it is a clean fit, then you can extend the range and see if the fit holds over a wider range of points. So, I think it becomes an iterative process, and that means slow. Of course, a modern CPU is a million times faster than a machine tool, so maybe this can actually work in reasonable time, given some good starting heuristics on how to parse the segments. 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)
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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
When we first used our Haas machines we discovered they would cut a program of short linear moves very rapidly. A long shallow arc (imagine an 80 inch arc length of a 300 inch radius) roughed to leave .150 to finish was undercut past the finished dimension. We quickly learned to handle the limitations and have used the machines for a long time. Not very accurate but usable without much problem. On Apr 20, 2012 11:56 AM, Jon Elson el...@pico-systems.com wrote: 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)
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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
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. 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)
Viesturs Lācis wrote: I also agree that separate filter would be better. Because the problem is solely in the g-code, so the filter to sort out the code is needed. With proper code the existing LinuxCNC can completely handle the job. Not completely. Some very correct G-code cannot be fixed completely outside LinuxCNC. You have a case where smooth curves cover a surface, but then at the end of a curve it has to turn around and go back the other way. The machine can handle the smooth curve at high speed because it is smooth. But, LinuxCNC requires it never exceed a velocity where it can stop on the next block. If you fix all the velocities so the motion hardware would never be maxed out, LinuxCNC will still limit the velocity. So, there needs to be an option where this limiting could be turned off. Then you are at the mercy of assuring that the filter never asks for more accel than the motion hardware can deliver. 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)
Would a read ahead of 1000 lines be more time consuming than the NURB calculation? My post has the ability to restrict output if a move is less than a certain distance. A .001 minimum and a 1000 block look ahead would yield a 1 inch minimum distance to slow down as necessary. On Apr 20, 2012 12:28 PM, Jon Elson el...@pico-systems.com 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. 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)
Jon On Fri, Apr 20, 2012 at 12:33 PM, Jon Elson el...@pico-systems.com wrote: Viesturs Lācis wrote: I also agree that separate filter would be better. Because the problem is solely in the g-code, so the filter to sort out the code is needed. With proper code the existing LinuxCNC can completely handle the job. Not completely. Some very correct G-code cannot be fixed completely outside LinuxCNC. You have a case where smooth curves cover a surface, but then at the end of a curve it has to turn around and go back the other way. The machine can handle the smooth curve at high speed because it is smooth. But, LinuxCNC requires it never exceed a velocity where it can stop on the next block. If you fix all the velocities so the motion hardware would never be maxed out, LinuxCNC will still limit the velocity. So, there needs to be an option where this limiting could be turned off. Then you are at the mercy of assuring that the filter never asks for more accel than the motion hardware can deliver. Jon here's how one group worked with the fast turn around at edge of work the machine tool was like the emc2-bipod and the software built huge arcs into the endmotions to keep velocity up and dampen the bipod swing the effort was http://hektor.ch and the added arcs that kept the velocity up are seen on http://hektor.ch/About/Interface.gif/ the red lines are the programmed paths the blue lines are the addition motion added to allow a constant velocity. kinda fun a cam solution to the machine's capabilties (not a control solution) regards tomp -- 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)
Here is something that just popped into my head. Could we: 1. Tag each segment with the maximum velocity at the end of the segment. The current scheme always sets it to zero. For the first segment, this will still be zero. For subsequent segments it will be the maximum velocity at the beginning of the previous segment. 2. Based on the maximum end velocity for the segment, compute the maximum velocity at the beginning of the segment. The velocities will be computed so as to allow for possible overshoot in the desired position consistent with the target accuracy. 3. Output the segment to the trajectory queue. 4. Feed override must be limited to the smaller of the beginning and ending velocities. (Actually, we could be smarter than that. It could be limited to the maximum velocity that will allow deceleration to the velocity at the end of the segment.) 5. Queue busters start the process over again. This algorithm: * Runs in constant time. * Is no worse than the current scheme. It seems too simple. What am I missing? Regards, Ken -- 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 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
Thomas Powderly wrote: here's how one group worked with the fast turn around at edge of work the machine tool was like the emc2-bipod and the software built huge arcs into the endmotions to keep velocity up and dampen the bipod swing Certainly fixing this in the CAM is the best approach, then the machine never needs to slow down at all, keeping good speeds right to the end of contact with the work. The problem, of course, is LinuxCNC won't give you the fastest speed possible because it still demands being able to stop at the end of the next block. 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)
Kenneth Lerman wrote: It seems too simple. What am I missing? It needs to look ahead an arbitrary number of blocks to see if a big slowdown is required some time ahead. When this stuff is interpreted, and that big slowdown is spotted, you have to go backwards through the blocks some amount to begin the slowing down. It doesn't look horribly difficult, but is a relatively unbounded problem, requiring a length of queue big enough to have a long enough horizon to watch over. I don't know the program structure well enough, but it might even be possible to splice in a filter between the interpreter and the TP that holds back a ring buffer of moves to perform this processing. 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 19 March 2012 02:17, Steve Blackmore st...@pilotltd.net wrote: Effectively LinuxCNC only looks ahead one line. This rather depends on what you mean by Look Ahead. One decision that I think might adversely affect LinuxCNC is that as far as I know LinuxCNC will always move in such a way as to be able to stop before the end of the next program line. For programs made of very small linear moves this means that the traverse speed can end up being very much reduced. I think that if this is actually the case it would make more sense to set a lower limit on this distance (INI file setting?) so that the motion system would guarantee stopping in the next program line or (for example) 0.01 Of course, I haven't checked the code, and I might be barking up entirely the wrong tree here. -- 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)
I don't think that would work well. Think about the situation where you have several (mostly straight) short line segments, the last being the shortest, and then a 90deg turn. I think many would find it unacceptable to overshoot the last segment 10thou if you were doing something like inside corners. I only have two machines running linuxcnc so far (both commercial gantry routers, both steppers) as a hobby so have limited experience but I don't think the look ahead is that big of an issue *IF* the machine has decent acceleration capability is properly tuned to use it. I can process complex 3d profiling in wood on the big one right about the limit of my spindle hp (~100ipm w/ a 1/2 ballmill). Yes, it probably does limit me slightly when doing a final finishing pass w/ a smaller bit. When Im doing aluminum sheet at ~30ipm its a total non-issue though. I have a factory CNC 3hp Wells Index knee mill w/ DC servos that Im retrofitting (slowly.) If LinuxCNC can keep up on the gantrys it will be no problem FOR ME on the knee mill. But I see how it might be a limiting factor for a modern Hass class speed machine w/ massive spindle hp and feed rates possible when profiling. But those would typ have very high acceleration levels to match. Machines w/ very low acceleration levels will suffer the most as they won't be allowed to get up to speed if you can't slow them down very fast. Its like what they say about driving at night: Dont outdrive your headlights :) More segments of look ahead would no doubt be an improvement. But how much? (seriously, I think we'd all like to know.) Can people give examples of machines and jobs where cutting speed is a problem due to limited look ahead? I don't have enough experience to even be able to guess the magnitude of the issue. Best, Stephen I think that if this is actually the case it would make more sense to set a lower limit on this distance (INI file setting?) so that the motion system would guarantee stopping in the next program line or (for example) 0.01 -- 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 19 April 2012 14:04, Stephen Dubovsky smdubov...@gmail.com wrote: But I see how it might be a limiting factor for a modern Hass class speed machine w/ massive spindle hp and feed rates possible when profiling. It shouldn't be a limit on any machine with decent G-code. I am describing a problem with poor-quality G-code which is made up of thousands of very short line segments. There is a constraint to at least touch every segment (I think) so your concern about the 90 degree bend is covered. -- 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)
2012/4/19 andy pugh bodge...@gmail.com: On 19 April 2012 14:04, Stephen Dubovsky smdubov...@gmail.com wrote: But I see how it might be a limiting factor for a modern Hass class speed machine w/ massive spindle hp and feed rates possible when profiling. It shouldn't be a limit on any machine with decent G-code. I am describing a problem with poor-quality G-code which is made up of thousands of very short line segments. There is a constraint to at least touch every segment (I think) so your concern about the 90 degree bend is covered. I think that this issue is fighting the consequence instead of fixing the real cause. People want to change the look ahead behavior, but I am completely sure that fixing the cause - getting normal g-code is much easier. At least for those things that my machines are doing. My personal opinion is that instead of trying to tweak LinuxCNC for this, users with the g-code consists of very small linear moves problem should join their effort in finding a suitable CAM application. 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)
On 19 April 2012 16:13, Stephen Dubovsky smdubov...@gmail.com wrote: For 3d profiling CAM usually writes the g-code. I don't know anyone who would hand calculate tens of thousands of little segments:) As such, I don't know that its necessarily poor quality. It has to generate as many segments as necessary to fit the arbitrary arcs to the specified precision. Well, generating an arc as tiny G1 moves seems a poorer solution than G2 or G3 moves... -- 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)
Well, generating an arc as tiny G1 moves seems a poorer solution than G2 or G3 moves... There are a number of reasons for doing this: Many CAM packages don't use arcs internally. Breaking arcs into line segments can greatly simplify the maths. When doing 3D work you can quite often get arcs and curves that are not on any standard plane (X-Y, X-Z,Y-Z) They may be cutting curves (i.e not pure arcs) Les -- 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/19 Stephen Dubovsky smdubov...@gmail.com: Around tight curves, that requires lots of short sections w/ high changes in velocity. But you have to go slow within the limits of the machine around those anyway. Just like Andy said - if there is curve in the part, then that is why there are G2 and G3 commands in g-code. Period. Doing arcs with linear moves is _wrong_ approach by definition. Put G2/G3 commands in all arcs and let LinuxCNC do its job - slow down the machine, if necessary, so that it can take given acceleration limits and execute the path with max available velocity. Like I asked: How big of a problem is this really? I guess that this is not the answer to Your question, but still... The task for CNC controller is to control the machine and move it so that it produces the part _exactly_ as described in the code operator feeds in it. The code has to be as simple and unambiguous as possible. If G1 is issued, then it is straight line. If the arc is needed, then use command for arcs instead of using one command in extremely inefficient way to describe another command. Task of CAM application is to produce that code. It should not reinvent the wheel, but use the standard commands from particular language. In case of g-code, G2 and G3 commands belong to the very very basics of this language. IMHO any CAM application, that does not use full potential of G2/G3 moves, is a crap, regardless of other features in it, because: 1) the code consist of such a small moves, that operator cannot understand it and cannot adjust it by hand, if needed; 2) the code is so long that moving around the file is just a disaster; 3) files for complex parts can exceed tenths of thousands of lines, which makes up the file size and also creates unnecessary load for the CNC controller, especially when it is loaded; 4) if such a basic commands have not been implemented, I think that there is serious reason to doubt the overall implementation of any other features, besides G1 moves... I think that in the end it is all about efficiency - smaller g-code file is easier for operator to overlook, easier for CNC controller to handle and efficient g-code leads to efficient work, as the job gets done faster. It seems like CAM authors are living on different planet, if they think that CNC controller should be equally efficient also with poor code. I think that this the same principle as give me Porsche 911 and ask to do a lap time as fast as Michael Schumacher. And then ask me, why was I so much slower, if I had the same car and in the same race track? 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)
I think this is a fairly common problem. There are a number Gcode generators out there that take curvy cutting patterns and turn them into huge files full of short G1 moves. The Gcode generator people expect the machine controller to gobble up the crappy G code and create smooth motions at high speeds. The one commercial application I ran into was for a vinyl cutter for sign making applications. They wanted to run at 1000 ipm while processing Gcode with segment lengths of a couple of thousands of an inch. It was crazy. Needless to say, a solution was never found. And their machines are still running slowly (the last I heard) due to the poor quality Gcode. Dave On 4/19/2012 11:13 AM, Stephen Dubovsky wrote: Im aware the 90deg case is currently covered. I was commenting to the OP who thought about allowing the trajectory planner to run a little faster than it can see could end badly even with such a common case. For 3d profiling CAM usually writes the g-code. I don't know anyone who would hand calculate tens of thousands of little segments:) As such, I don't know that its necessarily poor quality. It has to generate as many segments as necessary to fit the arbitrary arcs to the specified precision. Around tight curves, that requires lots of short sections w/ high changes in velocity. But you have to go slow within the limits of the machine around those anyway. On the longer smooth arcs, it generates longer segments (Im using Visual mill pkg in Alibre) so no problem there either. Are there common CAM pkgs that dont do this well? I guess if I set the curve fit in CAM to a very small number (currently using 0.001) it would bog my machine down. Like I asked: How big of a problem is this really? I can imagine a Hass class machine that can hold tenths at high speed could be fed a huge file w/ tenths arc fitting. Even allowing some small additional error like G64 P0.0001 I can envision a scenario which might not run at the programmed feed rate. So I ask again: Are there real world examples of it being a problem? Stephen On Thu, Apr 19, 2012 at 9:33 AM, andy pughbodge...@gmail.com wrote: On 19 April 2012 14:04, Stephen Dubovskysmdubov...@gmail.com wrote: But I see how it might be a limiting factor for a modern Hass class speed machine w/ massive spindle hp and feed rates possible when profiling. It shouldn't be a limit on any machine with decent G-code. I am describing a problem with poor-quality G-code which is made up of thousands of very short line segments. There is a constraint to at least touch every segment (I think) so your concern about the 90 degree bend is covered. -- 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 -- 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)
-Original Message- From: Viesturs Lacis [mailto:viesturs.la...@gmail.com] Sent: Thursday, April 19, 2012 11:08 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie) snip Just like Andy said - if there is curve in the part, then that is why there are G2 and G3 commands in g-code. Period. Doing arcs with linear moves is _wrong_ approach by definition. Put G2/G3 commands in all arcs and let LinuxCNC do its job - slow down the machine, if necessary, so that it can take given acceleration limits and execute the path with max available velocity. There are many cases where short segments are currently the only workable solution. Among these: 1) The arc is not parallel to the XY, XZ, or YZ planes 2) The path is curved, but not a true arc. It could be an oval, an ellipse, or even a spline or nurbs path. 3) The path is from a digitized source using a sample object or a photograph. With increasing usage of 3D modeling these sorts of paths are becoming more common. Steve Stallings -- 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)
The big problem is that very often the curves in the drawing are not true arcs. This is especially common in artistic and sign work. The quality of the CAM output is directly dependent on the quality of the input drawing. Drawings that contains just arcs and lines will generate nice clean code. Drawings with lots of splines and other curves will always generate big code. Some CAM packages try to do arc fitting on curves but technically this is just as bad as breaking them up into lines. You are compromising the accuracy of the final code. When it comes to 3D work, all bets are off because very often the final tool path will not follow true arcs. Les On 19/04/2012 17:31, Dave wrote: I think this is a fairly common problem. There are a number Gcode generators out there that take curvy cutting patterns and turn them into huge files full of short G1 moves. The Gcode generator people expect the machine controller to gobble up the crappy G code and create smooth motions at high speeds. The one commercial application I ran into was for a vinyl cutter for sign making applications. They wanted to run at 1000 ipm while processing Gcode with segment lengths of a couple of thousands of an inch. It was crazy. Needless to say, a solution was never found. And their machines are still running slowly (the last I heard) due to the poor quality Gcode. 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
Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)
On 19 April 2012 18:44, Steve Stallings steve...@newsguy.com wrote: There are many cases where short segments are currently the only workable solution. Among these: ... 2) The path is curved, but not a true arc. It could be an oval, an ellipse, or even a spline or nurbs path. I _think_ there is a 3D NURBS poised to appear in LinuxCNC. However that will be a LinucCNC-unique option, so I don't expect any CAM systems to support it. -- 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
