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] LinuxCNC Sandybridge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/22/2012 11:25 PM, Karl Schmidt wrote: On 04/21/2012 09:37 PM, Charles Steinkuehler wrote: Never mind...I chroot'd into the LinuxCNC Ubuntu install from a parallel Debian wheezy installation, which allowed me to grab build-essentials and the Intel e1000e driver source off the 'net. I also installed the linux-image-generic-lts-backport-natty (2.6.38) as a fall-back if I ever need newer HW support temporarily until I can build it for the 2.6.32 RTAI kernel. What happens if you use the RTAI kernel in Debian? http://packages.debian.org/squeeze/rtai - stable is using 2.6.32 kernel I haven't tested this. The 2.6.32 kernel is pretty dated (I'm already building custom modules for it to talk to my motherboard chipset and it's just going to get worse going forward). If sticking with 2.6.32 is desired/required, I would think the Debian package would be fine if you didn't want to just use the Ubuntu LinuxCNC install. For now, I'm using the Ubuntu Live-CD install for testing with the RTAI 2.6.32 kernel. You could go to testing and the linux-image-3.2.0-2-rt-amd64 kernel? http://packages.debian.org/wheezy/linux-image-rt-amd64 I'm working on getting that building and operational as a separate project. Some other folks have been doing work with the mainline kernels and the PREEMPT_RT kernel configuration option. Check the dev list archives for a few recent threads about this. Is there something special about the LinuxCNC patch? There's not a LinuxCNC patch AFAIK. Both the RTAI patches and the PREEMPT_RT patches are general efforts to make the Linux kernel more responsive for real-time applications. LinuxCNC sits on top of the new kernel real-time capabilities but doesn't require any kernel patching specific _just_ to LinuxCNC. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VZJ4ACgkQLywbqEHdNFw5xQCg90+eBn5+NxOjxtXV3h5TrFHE yXsAnif3VWJbhLwVDAX8Lx5FA+W5ljXh =bOPN -END PGP SIGNATURE- -- 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] Fixed Dwell
On Sun, 22 Apr 2012 07:25:26 +0100 Mike Bennett mjb1...@gmail.com wrote: Hi I'm nearing the end of building a DIY gantry router. The router I'm using has soft start, so takes several seconds to come up to speed. I realise I could add dwell commands to the G-Code, but is it possible to add a fixed dwell to Linux CNC after spindle start. From reading other posts I see that HAL has a spindle-at-speed input that is intended to be used with encoders, but could it be used with a timer? Mike On 22 Apr 2012, at 00:12, charles green xxzzb...@yahoo.com wrote: 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 G4 P delay is meant to delay movement while the spindle gets up to speed. 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
Re: [Emc-users] Fixed Dwell
On Monday, April 23, 2012 01:54:59 PM dave did opine: Viesturs G4 P delay is meant to delay movement while the spindle gets up to speed. Dave Which works fine Dave, BUT must be written into every piece of code that will be executed. Far better IMO to configure linuxcnc, in the hal file, to do it automatically so there aren't any I forgot surprises. And some snippets posted here in the last days would appear to handle that nicely, either with a fixed delay, or even by a spindle_at_speed signal if a valid one can be derived from the hardware itself. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene An American's a person who isn't afraid to criticize the president but is always polite to traffic cops. -- 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] axis-remote issues
I am trying to use axis-remote and get the following error when I try to send a command to Axis: emc@emc-desktop:~$ axis-remote --reload X server insecure (must use xauth-style authorization); command ignored Has anyone else come across this and if so, how did you get around it? 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] axis-remote issues
A work around for this (or at least a similar problem occuring with Ubuntu 10.04 and tk8.5) was incorporated in axis (v2.5 or later): http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=e863002919cd1fc0c8395abbe29fcec14e5c1cae You can also try the shell commands directly as: $ xhost -SI:localuser:gdm -SI:localuser:root on the machine displaying axis (the XServer) -- Dewey Garrett -- 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
