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] That single channel digital pocket scope has arrived :(
On 04/20/2012 12:27 AM, gene heskett wrote: It wasn't there. What I did was take my card interface, and the card to the tv station where we plugged in into a W7 box. It never found the SDHC card. So Jim had a reader in another machine, which found it in 2 or 3 seconds. My reader wasn't SDHC compatible. The, re-reading the docs that came with the scope, it isn't compatible with SDHC, only SD. That comes in 2Gb max, and there are none in captivity within 50 miles of me. So I bought a new reader that claims it can do SDHC which is what I think is in my Nikon and came home, and have now ordered 2 of them from some schlock that insists on paypal. Cheers, Gene Gene, I forgot, which scope did you end up getting? Mark -- 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
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] That single channel digital pocket scope has arrived :(
On Friday, April 20, 2012 09:01:21 AM Mark Wendt did opine: On 04/20/2012 12:27 AM, gene heskett wrote: It wasn't there. What I did was take my card interface, and the card to the tv station where we plugged in into a W7 box. It never found the SDHC card. So Jim had a reader in another machine, which found it in 2 or 3 seconds. My reader wasn't SDHC compatible. The, re-reading the docs that came with the scope, it isn't compatible with SDHC, only SD. That comes in 2Gb max, and there are none in captivity within 50 miles of me. So I bought a new reader that claims it can do SDHC which is what I think is in my Nikon and came home, and have now ordered 2 of them from some schlock that insists on paypal. Cheers, Gene Gene, I forgot, which scope did you end up getting? Mark The DSO Nano, V1. Single channel, max of 1 megasample/second. 12 bit a/d, 4096 sample buffer. 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 To be loved is very demoralizing. -- Katharine Hepburn -- 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
[Emc-users] persistent homing
I don't have home switches, etc. I want my last home position to be remembered between software cycles. I currently have NO_FORCE_HOME = 1 in my ini, but that doesn't seem to make these persistent. Can this be done? The reason? I have different emc.vars files with persistent variables that I want to load, and cycling the software seems the only way currently. -- 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] That single channel digital pocket scope has arrived :(
On 04/20/2012 09:04 AM, gene heskett wrote: On Friday, April 20, 2012 09:01:21 AM Mark Wendt did opine: On 04/20/2012 12:27 AM, gene heskett wrote: It wasn't there. What I did was take my card interface, and the card to the tv station where we plugged in into a W7 box. It never found the SDHC card. So Jim had a reader in another machine, which found it in 2 or 3 seconds. My reader wasn't SDHC compatible. The, re-reading the docs that came with the scope, it isn't compatible with SDHC, only SD. That comes in 2Gb max, and there are none in captivity within 50 miles of me. So I bought a new reader that claims it can do SDHC which is what I think is in my Nikon and came home, and have now ordered 2 of them from some schlock that insists on paypal. Cheers, Gene Gene, I forgot, which scope did you end up getting? Mark The DSO Nano, V1. Single channel, max of 1 megasample/second. 12 bit a/d, 4096 sample buffer. Cheers, Gene I see they've now got V2 out, and discontinued V1. Same price too. Mark -- 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] persistent homing
How would you know what state stepper/servos are in without homing in some way do you have absolute encoders Dave Caroline -- 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] persistent homing
2012/4/20 Erik Friesen e...@aercon.net: I don't have home switches, etc. I want my last home position to be remembered between software cycles. If I understand You correctly, then You want LinuxCNC to remember the position of joints/axes, when program is closed so that when You start it over again, it shows, where the tool actually is. Is that correct? 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] That single channel digital pocket scope has arrived :(
On Friday, April 20, 2012 09:17:15 AM Mark Wendt did opine: On 04/20/2012 09:04 AM, gene heskett wrote: On Friday, April 20, 2012 09:01:21 AM Mark Wendt did opine: On 04/20/2012 12:27 AM, gene heskett wrote: It wasn't there. What I did was take my card interface, and the card to the tv station where we plugged in into a W7 box. It never found the SDHC card. So Jim had a reader in another machine, which found it in 2 or 3 seconds. My reader wasn't SDHC compatible. The, re-reading the docs that came with the scope, it isn't compatible with SDHC, only SD. That comes in 2Gb max, and there are none in captivity within 50 miles of me. So I bought a new reader that claims it can do SDHC which is what I think is in my Nikon and came home, and have now ordered 2 of them from some schlock that insists on paypal. Cheers, Gene Gene, I forgot, which scope did you end up getting? Mark The DSO Nano, V1. Single channel, max of 1 megasample/second. 12 bit a/d, 4096 sample buffer. Cheers, Gene I see they've now got V2 out, and discontinued V1. Same price too. Mark The V2 has an additional control button, but the current SW runs on either. 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 There is something in the pang of change More than the heart can bear, Unhappiness remembering happiness. -- Euripides -- 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] persistent homing
2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: How would you know what state stepper/servos are in without homing in some way do you have absolute encoders If there are no significant external forces to shift motors, when they are not powered, then steppers would not drift more than a half step from their previous position, when power is reapplied. 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] persistent homing
Thats right, I will still check homing, but if it remembers the last location with a step that is close enough for me. On Fri, Apr 20, 2012 at 9:24 AM, Viesturs Lācis viesturs.la...@gmail.comwrote: 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: How would you know what state stepper/servos are in without homing in some way do you have absolute encoders If there are no significant external forces to shift motors, when they are not powered, then steppers would not drift more than a half step from their previous position, when power is reapplied. 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] persistent homing
On Fri, Apr 20, 2012 at 2:24 PM, Viesturs Lācis viesturs.la...@gmail.com wrote: 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: How would you know what state stepper/servos are in without homing in some way do you have absolute encoders If there are no significant external forces to shift motors, when they are not powered, then steppers would not drift more than a half step from their previous position, when power is reapplied. Proof/reference/url ? but which phase will the drivers take on starting and which type of stepper are you asserting that for all very indeterminate Dave Caroline -- 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] persistent homing
proof = my eyes?? Proof doesn't need to be objective here. :-) On Fri, Apr 20, 2012 at 9:31 AM, Dave Caroline dave.thearchiv...@gmail.comwrote: On Fri, Apr 20, 2012 at 2:24 PM, Viesturs Lācis viesturs.la...@gmail.com wrote: 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: How would you know what state stepper/servos are in without homing in some way do you have absolute encoders If there are no significant external forces to shift motors, when they are not powered, then steppers would not drift more than a half step from their previous position, when power is reapplied. Proof/reference/url ? but which phase will the drivers take on starting and which type of stepper are you asserting that for all very indeterminate Dave Caroline -- 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)
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
Re: [Emc-users] Nonplanar arcs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not that it really matters, but three points can define a plane and it's normal based on the order in which they are listed. For example, declare that you always list the points in a clockwise direction (based on the desired plane normal). Then you can take the same set of points, list them in a different order, and provide for either normal direction. On 4/19/2012 2:08 PM, Ian McMahon wrote: Yep, you're right... you need a plane normal to be able to put a value on clockwise :) On Apr 19, 2012, at 2:57 PM, Chris Radek wrote: On Thu, Apr 19, 2012 at 09:45:42PM +0300, Viesturs L??cis wrote: Uhhh, You are right, halfcircles. All three points are on a straight line, around which the arc can freely rotate. I guess that this is special case (is there any other?), That is just the worst problem. Your system doesn't uniquely identify any arc. For every start, center, end points there are a pair of arcs that share the points. This is why we have G2/G3. If you don't have a normal vector you can't say which way is clockwise, so G2/G3 don't make sense. This is also a problem you get when you specify the arbitrary plane with three points, as was proposed by Ian M. The correct solution is probably to specify the plane's normal vector. While it's entirely possible to do, I doubt anyone would ever use this feature if someone did the work to implement it. Chris -- 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 - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+RZ/sACgkQLywbqEHdNFzVFACdG2DgE8JHjU0S2qe8g56pu7+S y+QAnjJa73lfevSnxB6n1yyj+QMmceFD =nncz -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] persistent homing
•POSITION_FILE = position.txt - If set to a non-empty value, the joint positions are stored between runs in this file. This allows the machine to start with the same coordinates it had on shutdown. This assumes there was no movement of the machine while powered off. If unset, joint positions are not stored and will begin at 0 each time LinuxCNC is started. This can help on smaller machines without home switches. http://linuxcnc.org/docs/2.5/html/config/ini_config.html#_traj_section_a_id_sub_traj_section_a I think is what you are looking for? sam On Fri, 20 Apr 2012 09:33:46 -0400 Erik Friesen e...@aercon.net wrote: proof = my eyes?? Proof doesn't need to be objective here. :-) On Fri, Apr 20, 2012 at 9:31 AM, Dave Caroline dave.thearchiv...@gmail.comwrote: On Fri, Apr 20, 2012 at 2:24 PM, Viesturs Lācis viesturs.la...@gmail.com wrote: 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: How would you know what state stepper/servos are in without homing in some way do you have absolute encoders If there are no significant external forces to shift motors, when they are not powered, then steppers would not drift more than a half step from their previous position, when power is reapplied. Proof/reference/url ? but which phase will the drivers take on starting and which type of stepper are you asserting that for all very indeterminate Dave Caroline -- 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] persistent homing
Yes, I thought I'd seen it somewhere. I'm running a little shy here, I had my machine set on noforcehoming, and it threw an joint out of range error while running, and everything was within the bounding box. On Fri, Apr 20, 2012 at 9:47 AM, sa...@empirescreen.com wrote: •POSITION_FILE = position.txt - If set to a non-empty value, the joint positions are stored between runs in this file. This allows the machine to start with the same coordinates it had on shutdown. This assumes there was no movement of the machine while powered off. If unset, joint positions are not stored and will begin at 0 each time LinuxCNC is started. This can help on smaller machines without home switches. http://linuxcnc.org/docs/2.5/html/config/ini_config.html#_traj_section_a_id_sub_traj_section_a I think is what you are looking for? sam On Fri, 20 Apr 2012 09:33:46 -0400 Erik Friesen e...@aercon.net wrote: proof = my eyes?? Proof doesn't need to be objective here. :-) On Fri, Apr 20, 2012 at 9:31 AM, Dave Caroline dave.thearchiv...@gmail.comwrote: On Fri, Apr 20, 2012 at 2:24 PM, Viesturs Lācis viesturs.la...@gmail.com wrote: 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: How would you know what state stepper/servos are in without homing in some way do you have absolute encoders If there are no significant external forces to shift motors, when they are not powered, then steppers would not drift more than a half step from their previous position, when power is reapplied. Proof/reference/url ? but which phase will the drivers take on starting and which type of stepper are you asserting that for all very indeterminate Dave Caroline -- 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...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, 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 in
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] persistent homing
I was thinking about introducing handlers similar to ON_ABORT which would execute on startup, first machine-on and shutdown this could be either NGC or Python functions which could - among other things - save/restore arbitrary state; in reality only Python has the powers to do read/write files and introspection - Michael Am 20.04.2012 um 15:05 schrieb Erik Friesen: I don't have home switches, etc. I want my last home position to be remembered between software cycles. I currently have NO_FORCE_HOME = 1 in my ini, but that doesn't seem to make these persistent. Can this be done? The reason? I have different emc.vars files with persistent variables that I want to load, and cycling the software seems the only way currently. -- 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] persistent homing
2012/4/20 Michael Haberler mai...@mah.priv.at: I was thinking about introducing handlers similar to ON_ABORT which would execute on startup, first machine-on and shutdown There is INI file option to execute separate HAL file on shutdown: SHUTDOWN = shutdown.hal 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)
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
[Emc-users] Relay driver not working
Hello, gentlemen! I would appreciate, if someone could advice, what is wrong with my diy relay driver. I built it according to this scheme: http://www.cutting.lv/fileadmin/user_upload/bd140_scheme.gif Relay is PE014005: http://www.te.com/catalog/pn/en/1393219-3 The transistor is BD140-16 http://www.datasheetcatalog.org/datasheet/stmicroelectronics/4186.pdf The diode is 1n4007 R1 is 220 ohm. M is output pin on Mesa card, set for current sinking. Base current should be 22mA, minimum HFE should be slightly below 40, so current on collector should be several hundreds of mA, while the datasheet says that relay coil is rated at 200mW, so it needs 40 mA. Output pin on Mesa card is working - it swings from +5,07 VDC to 0,60 VDC as I switch it on and off. But it seems that the transistor is not working - the voltage on collector does not rise above 0,00 VDC regardless of the state of Mesa output pin. I have tried: 1) shortcircuit base of transistor to GND (disconnected from Mesa card): relay not clicking; 2) shortcircuit collector of transistor to +5V: relay is clicking; So I know that relay is ok, but there is something about the transistor. I have exchanged 3 transistors already without any luck. What could I be missing here? Thanks in advance! 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)
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] Relay driver not working
Measure the base voltage in the two states relative to +5 Dave Caroline On Fri, Apr 20, 2012 at 4:18 PM, Viesturs Lācis viesturs.la...@gmail.com wrote: Hello, gentlemen! I would appreciate, if someone could advice, what is wrong with my diy relay driver. I built it according to this scheme: http://www.cutting.lv/fileadmin/user_upload/bd140_scheme.gif Relay is PE014005: http://www.te.com/catalog/pn/en/1393219-3 The transistor is BD140-16 http://www.datasheetcatalog.org/datasheet/stmicroelectronics/4186.pdf The diode is 1n4007 R1 is 220 ohm. M is output pin on Mesa card, set for current sinking. Base current should be 22mA, minimum HFE should be slightly below 40, so current on collector should be several hundreds of mA, while the datasheet says that relay coil is rated at 200mW, so it needs 40 mA. Output pin on Mesa card is working - it swings from +5,07 VDC to 0,60 VDC as I switch it on and off. But it seems that the transistor is not working - the voltage on collector does not rise above 0,00 VDC regardless of the state of Mesa output pin. I have tried: 1) shortcircuit base of transistor to GND (disconnected from Mesa card): relay not clicking; 2) shortcircuit collector of transistor to +5V: relay is clicking; So I know that relay is ok, but there is something about the transistor. I have exchanged 3 transistors already without any luck. What could I be missing here? Thanks in advance! 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] Relay driver not working
a common mistake is to assume collector is the middle pin like the npn but its the base Dave Caroline -- 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] Relay driver not working
2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: Measure the base voltage in the two states relative to +5 It changes from +5,07 VDC to 0,60 VDC. +5 actually are +5,17, so it means that base voltage swings from -0,1 to -4,57V, relative to +5V. But it does not work, even if I connect the base straight to GND, which gave base -5 V, relative to +5. 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: a common mistake is to assume collector is the middle pin like the npn but its the base I checked for the errors in connections at least 4 or 5 times, especially not to mix up collector and emmiter, I knew that the base is in middle, but never found anything. Diode also is soldered correctly (the light stripe on diode's case is on the transistor's side). What else could possibly wrong? 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] Relay driver not working
There is no way a base can go beyond around .6 volts if the transistor is ok or it is connected correctly shorting the base to ground will kill the transistor unless the psu is rubbish Dave Caroline -- 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
[Emc-users] Open Hardware Summit
http://summit.oshwa.org/call/ Something that I saw pop up on one of the other lists I lurk on. One of the topics certainly looks to possibly fit in with one of the current hot discussions (cad/cam). Brian -- 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] Emc-users Digest, Vol 72, Issue 106
20 apr 2012 kl. 18.54 skrev emc-users-requ...@lists.sourceforge.net: As Dave said below, U can't shortcircuit base to ground in your circuit, the resistor is intended to limit the base current in your schematics so what U can do is to set the M point to ground, that should make your relay klick. The mentioned fact that U measure approx - 4 V relative +5 on the base pin does in fact prove that the Base-Collector junction is burnt. So first U have to replace your semiconductor! / Roger -- Message: 5 Date: Fri, 20 Apr 2012 17:21:06 +0100 From: Dave Caroline dave.thearchiv...@gmail.com Subject: Re: [Emc-users] Relay driver not working To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Message-ID: CALfYgtkMK31Yq53-LcvyV3DXjkZ8wm8wyT=NL1i=ztbnxv-...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 There is no way a base can go beyond around .6 volts if the transistor is ok or it is connected correctly shorting the base to ground will kill the transistor unless the psu is rubbish Dave Caroline -- 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] Relay driver not working
Ok, I have 3 more BD140s to play with, so will try again tomorrow. Viesturs 2012. gada 20. Apr. 18:24 Dave Caroline dave.thearchiv...@gmail.com rakstīja: There is no way a base can go beyond around .6 volts if the transistor is ok or it is connected correctly shorting the base to ground will kill the transistor unless the psu is rubbish Dave Caroline -- 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
[Emc-users] OT: Chinese servo motor
Hello everybody, This is not a pure LinuxCNC question, but it's a question about servo motors, and I'm going to control them using LinuxCNC, and given the knowledge and experience on this list I think you could clear some of my doubts. I'm looking for cheap servo motors to control some positioning movements on a grinder, since the steppers are way too limited in their torque. So I was looking for chinese servo motors, (since my steppers and drives are from china and work very well), and I found this:http://www.alibaba.com/product-gs/466312062/130ST_M07725_2kw_industrial_motor.html I was wondering if any of you have experience with these kind of servos, and what do you think about it, because the prices are way too cheap. USD 265 for a 2kw servo motor and USD 290 for the driver. So I would be thanked if you can tell me your thoughts about this, and of course I'll be more thanked if you have any recomendation. Best regards! -- *Leonardo Marsaglia*. -- 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] OT: Chinese servo motor
20 квітня 2012 р. 23:08 Leonardo Marsaglia leonardomarsagli...@gmail.comнаписав: Hello everybody, This is not a pure LinuxCNC question, but it's a question about servo motors, and I'm going to control them using LinuxCNC, and given the knowledge and experience on this list I think you could clear some of my doubts. I'm looking for cheap servo motors to control some positioning movements on a grinder, since the steppers are way too limited in their torque. So I was looking for chinese servo motors, (since my steppers and drives are from china and work very well), and I found this: http://www.alibaba.com/product-gs/466312062/130ST_M07725_2kw_industrial_motor.html I was wondering if any of you have experience with these kind of servos, and what do you think about it, because the prices are way too cheap. USD 265 for a 2kw servo motor and USD 290 for the driver. So I would be thanked if you can tell me your thoughts about this, and of course I'll be more thanked if you have any recomendation. Best regards! Hi Leonardo, I got similar chinese motors (MiGe with Maxsine EP2 drivers) from http://hzmgdj.en.alibaba.com/ Used them with analog control. Can't find anything bad to say, all looks very good for the price. 2500ppr encoders, all cables and connectors included. Just choose the drives carefully, there are two series: position control only, and position+velocity+torque. Andrew -- 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] Relay driver not working
On Friday, April 20, 2012 04:10:40 PM Viesturs Lācis did opine: Hello, gentlemen! I would appreciate, if someone could advice, what is wrong with my diy relay driver. I built it according to this scheme: http://www.cutting.lv/fileadmin/user_upload/bd140_scheme.gif Relay is PE014005: http://www.te.com/catalog/pn/en/1393219-3 The transistor is BD140-16 http://www.datasheetcatalog.org/datasheet/stmicroelectronics/4186.pdf The diode is 1n4007 R1 is 220 ohm. M is output pin on Mesa card, set for current sinking. Base current should be 22mA, minimum HFE should be slightly below 40, so current on collector should be several hundreds of mA, while the datasheet says that relay coil is rated at 200mW, so it needs 40 mA. Output pin on Mesa card is working - it swings from +5,07 VDC to 0,60 VDC as I switch it on and off. But it seems that the transistor is not working - the voltage on collector does not rise above 0,00 VDC regardless of the state of Mesa output pin. I have tried: 1) shortcircuit base of transistor to GND (disconnected from Mesa card): relay not clicking; 2) shortcircuit collector of transistor to +5V: relay is clicking; So I know that relay is ok, but there is something about the transistor. I have exchanged 3 transistors already without any luck. What could I be missing here? One, shorting the base of that transistor to ground will blow the base emitter junction instantly, if not sooner. It may be safe to ground the left end of that 220 ohm resistor, but I'd be tempted to use a 1k resistor as additional current limiting. Test your transistors. Those you have pulled back out will likely not have a detectable emitter/base junction. Modern digital meters should have a diode function on their function switch, which applies about a volt across the junction, and then displays the voltage at which the junction diode has become forward biased enough to start conducting the quite low test current available from the meter, and should, on a good junction, show something in the range of (for an Si semiconductor which that one is) between .55 and .75 volts as displayed by the meter. Reverse the probe placement and the meter should show whatever it displays when the probes aren't touching anything, usually OD or OL depending on the meter. A reading both directions is a no-no. This circuit is a current load on the Mesa, activating the relay when the Mesa output pin goes to 4.2 volts or below. If the Mesa pin goes to below a volt, you will have close to 20-22 milliamps of base drive, which given a beta of 40 min, will give around .9 amps to drive the relay, which needs only .03 amps to close it, albeit that is likely the ragged edge of low. So I would raise that 220 ohm resistor by 2 to 4x, basing how high on the measured drop across the transistor when it is turned on. When you raise it until the voltage drop across the transistor has risen to .5 volts when the relay is energized, I would install for good, 30 to 50% of the value of whatever the test resistor in place of the 220 was then being used. IOW if 2200 gives that half volt, install a 1000 permanently. Make sure D1 is good, its purpose is to absorb the inductive spike that goes below ground when the transistor is suddenly turned off, thereby protecting the transistor from a Vceo breakdown which is said to be at -45 volts according to that .pdf data sheet. If the relay is noticeably slow at opening, a small ohmage resistor could be inserted in series with that diode in order to speed the power dissipation of the free wheeling current the diode allows. 100 ohms should be safe but I'd say 47 would be a SWAG value to use there. And although the resistor will never develop any great amount of heat, I would not use a resistor rated for less than 1/2 watt in that position because the smaller ones will not have enough internal breakdown under the surge conditions and will over time drift low, but will finally open, removing the diode from the circuit completely. It will not be discolored or have any other visible damage when that happens, but the transistor will likely be 'punched thru' and the relay then stuck on till the circuit is powered down and the transistor replaced. BTW, when checking the transistors, when you find the direction thge probes need to be to find the base-emitter junction, leave the probe on the base and move the other probe to the collector, you should see a similar reading there, and trading the probes should also be equ to no connection. As that is a Si transistor, I'd also say that readings below .45 volts make the devices health quite suspect. Ge transistors OTOH can be below .2 volts. HTH. 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 Knowledge is power.
Re: [Emc-users] Relay driver not working
On Friday, April 20, 2012 05:18:06 PM Dave Caroline did opine: a common mistake is to assume collector is the middle pin like the npn but its the base Dave Caroline This one, according to the data sheet, is conventional, with the collector on the middle pin. -- 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 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 He who slings mud generally loses ground. -- Adlai Stevenson -- 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] Relay driver not working
It may be safe to ground the left end of that 220 ohm resistor, but I'd be tempted to use a 1k resistor as additional current limiting. NONO this user has already killed a mesa card Dave Caroline -- 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] OT: Chinese servo motor
Leonardo, I have had good luck buying new and used Yaskawa servos from eBay. Jim - Original Message - From: Leonardo Marsaglia leonardomarsagli...@gmail.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Fri Apr 20 15:08:32 2012 Subject: [Emc-users] OT: Chinese servo motor Hello everybody, This is not a pure LinuxCNC question, but it's a question about servo motors, and I'm going to control them using LinuxCNC, and given the knowledge and experience on this list I think you could clear some of my doubts. I'm looking for cheap servo motors to control some positioning movements on a grinder, since the steppers are way too limited in their torque. So I was looking for chinese servo motors, (since my steppers and drives are from china and work very well), and I found this:http://www.alibaba.com/product-gs/466312062/130ST_M07725_2kw_industrial_motor.html I was wondering if any of you have experience with these kind of servos, and what do you think about it, because the prices are way too cheap. USD 265 for a 2kw servo motor and USD 290 for the driver. So I would be thanked if you can tell me your thoughts about this, and of course I'll be more thanked if you have any recomendation. Best regards! -- *Leonardo Marsaglia*. -- 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 This communication is for the use of the intended recipient only. It may contain information that is privileged and confidential. If you are not the intended recipient of this communication, the disclosure, copying, distribution or use hereof is prohibited. If you have received this communication in error, please advise me by return e-mail or by telephone and then delete it immediately. -- 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] Relay driver not working
On Friday, April 20, 2012 05:19:30 PM Viesturs Lācis did opine: 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: Measure the base voltage in the two states relative to +5 It changes from +5,07 VDC to 0,60 VDC. +5 actually are +5,17, so it means that base voltage swings from -0,1 to -4,57V, relative to +5V. But it does not work, even if I connect the base straight to GND, which gave base -5 V, relative to +5. 2012/4/20 Dave Caroline dave.thearchiv...@gmail.com: a common mistake is to assume collector is the middle pin like the npn but its the base I checked for the errors in connections at least 4 or 5 times, especially not to mix up collector and emmiter, I knew that the base is in middle, but never found anything. That data sheet pdf you gave the URL of doesn't say that. Looking at the top side, epoxy face of it with the legs hanging down, the left leg is #3, the emitter. The center leg, #2, is the collector, and the right leg, #1 is the base. Be aware that the center leg is also going to be tied to any heat sinking used unless a sheet of mica is interposed. That shaded area on the other side, the exposed metal as in the right image on page 3, shows the metal heat spreader, which is likely a direct connection to the collector of the transistors die as its all one stamping. To do otherwise makes a very poor heat path to get rid of the heat. That said, driving that relay, heat isn't going to be any higher than about 30 down on the list of priorities for this. Heat sinking not needed IOW. Diode also is soldered correctly (the light stripe on diode's case is on the transistor's side). What else could possibly wrong? 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 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 He who slings mud generally loses ground. -- Adlai Stevenson -- 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] Relay driver not working
On Fri, Apr 20, 2012 at 10:18 PM, gene heskett ghesk...@wdtv.com wrote: On Friday, April 20, 2012 05:18:06 PM Dave Caroline did opine: a common mistake is to assume collector is the middle pin like the npn but its the base Dave Caroline This one, according to the data sheet, is conventional, with the collector on the middle pin. which data sheet? I found http://www2.picturepush.com/photo/a/4802175/img/Polovodice/bd140.gif could be wrong as many sites are Dave Caroline -- 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] Relay driver not working
On Friday, April 20, 2012 05:32:42 PM Dave Caroline did opine: It may be safe to ground the left end of that 220 ohm resistor, but I'd be tempted to use a 1k resistor as additional current limiting. NONO this user has already killed a mesa card If a 1k resistor to ground can kill a Mesa card, I'll buy the beer. That would be, with the far end of the resistor tied either to 5 volts or to ground, a half a milliamp current flow. I might start checking things at 10 mills or more, but some of the buffer chips in use today can source or sink 24 mills. Half a milliamp s/b a total non-issue. Dave Caroline -- 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 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 I'm sure that that could be indented more readably, but I'm scared of the awk parser. -- Larry Wall in 6...@jpl-devvax.jpl.nasa.gov -- 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] Relay driver not working
On Fri, Apr 20, 2012 at 10:36 PM, gene heskett ghesk...@wdtv.com wrote: On Friday, April 20, 2012 05:32:42 PM Dave Caroline did opine: It may be safe to ground the left end of that 220 ohm resistor, but I'd be tempted to use a 1k resistor as additional current limiting. NONO this user has already killed a mesa card If a 1k resistor to ground can kill a Mesa card, I'll buy the beer. That would be, with the far end of the resistor tied either to 5 volts or to ground, a half a milliamp current flow. I might start checking things at 10 mills or more, but some of the buffer chips in use today can source or sink 24 mills. Half a milliamp s/b a total non-issue. It may be safe to ground the left end of that 220 ohm resistor, but thats the part I take issue with Dont forget thats the method he has been using base to ground Dave Caroline -- 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] Relay driver not working
On Fri, 20 Apr 2012, gene heskett wrote: Date: Fri, 20 Apr 2012 17:36:29 -0400 From: gene heskett ghesk...@wdtv.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Relay driver not working On Friday, April 20, 2012 05:32:42 PM Dave Caroline did opine: It may be safe to ground the left end of that 220 ohm resistor, but I'd be tempted to use a 1k resistor as additional current limiting. NONO this user has already killed a mesa card If a 1k resistor to ground can kill a Mesa card, I'll buy the beer. That would be, with the far end of the resistor tied either to 5 volts or to ground, a half a milliamp current flow. I might start checking things at 10 mills or more, but some of the buffer chips in use today can source or sink 24 mills. Half a milliamp s/b a total non-issue. Dave Caroline All of our FPGA cards can safely sink 24 mA (and source 24 ma from 3.3V) Damaged cards are usually from applying voltages in excess of 5.5V (Spartan 2) or ~8V (Spartan3 and 6 with series bus switches for 5V tolerance) A dozen or so shorted I/O lines is unlikely to cause FPGA damage (ask me how I know) -- 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] Relay driver not working
On 04/20/2012 06:20 PM, Peter C. Wallace wrote: A dozen or so shorted I/O lines is unlikely to cause FPGA damage (ask me how I know) I can imagine... 5 years from now someone is looking at a LinuxCNC configuration using a MESA card and wonders Why is he using stepper outputs 4, 5 and 6 for X, Y and Z? Wouldn't 1,2 and 3 make more sense? -- 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] OT: Chinese servo motor
Thank you guys for your answers. I think I'm going to try these servos, with analog drivers to close the loop on LinuxCNC. James, here in my country, Argentina, there are suppliers that sell yaskawa motors, but the price is four times the price for a chinese driver, and the connectors and cables are not included. I'm going to check out on ebay to see if there are some good priced yaskawa servo motors, but I don't think any other servo motor can be cheaper as the chinese. El 20 de abril de 2012 17:55, James Louis james.lo...@gastechnology.orgescribió: Leonardo, I have had good luck buying new and used Yaskawa servos from eBay. Jim - Original Message - From: Leonardo Marsaglia leonardomarsagli...@gmail.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Fri Apr 20 15:08:32 2012 Subject: [Emc-users] OT: Chinese servo motor Hello everybody, This is not a pure LinuxCNC question, but it's a question about servo motors, and I'm going to control them using LinuxCNC, and given the knowledge and experience on this list I think you could clear some of my doubts. I'm looking for cheap servo motors to control some positioning movements on a grinder, since the steppers are way too limited in their torque. So I was looking for chinese servo motors, (since my steppers and drives are from china and work very well), and I found this: http://www.alibaba.com/product-gs/466312062/130ST_M07725_2kw_industrial_motor.html I was wondering if any of you have experience with these kind of servos, and what do you think about it, because the prices are way too cheap. USD 265 for a 2kw servo motor and USD 290 for the driver. So I would be thanked if you can tell me your thoughts about this, and of course I'll be more thanked if you have any recomendation. Best regards! -- *Leonardo Marsaglia*. -- 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 This communication is for the use of the intended recipient only. It may contain information that is privileged and confidential. If you are not the intended recipient of this communication, the disclosure, copying, distribution or use hereof is prohibited. If you have received this communication in error, please advise me by return e-mail or by telephone and then delete it immediately. -- 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 -- *Leonardo Marsaglia*. -- 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] OT: Chinese servo motor
Sorry, I meant the price is four times the chinese motor+driver. El 20 de abril de 2012 22:19, Leonardo Marsaglia leonardomarsagli...@gmail.com escribió: Thank you guys for your answers. I think I'm going to try these servos, with analog drivers to close the loop on LinuxCNC. James, here in my country, Argentina, there are suppliers that sell yaskawa motors, but the price is four times the price for a chinese driver, and the connectors and cables are not included. I'm going to check out on ebay to see if there are some good priced yaskawa servo motors, but I don't think any other servo motor can be cheaper as the chinese. El 20 de abril de 2012 17:55, James Louis james.lo...@gastechnology.orgescribió: Leonardo, I have had good luck buying new and used Yaskawa servos from eBay. Jim - Original Message - From: Leonardo Marsaglia leonardomarsagli...@gmail.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Fri Apr 20 15:08:32 2012 Subject: [Emc-users] OT: Chinese servo motor Hello everybody, This is not a pure LinuxCNC question, but it's a question about servo motors, and I'm going to control them using LinuxCNC, and given the knowledge and experience on this list I think you could clear some of my doubts. I'm looking for cheap servo motors to control some positioning movements on a grinder, since the steppers are way too limited in their torque. So I was looking for chinese servo motors, (since my steppers and drives are from china and work very well), and I found this: http://www.alibaba.com/product-gs/466312062/130ST_M07725_2kw_industrial_motor.html I was wondering if any of you have experience with these kind of servos, and what do you think about it, because the prices are way too cheap. USD 265 for a 2kw servo motor and USD 290 for the driver. So I would be thanked if you can tell me your thoughts about this, and of course I'll be more thanked if you have any recomendation. Best regards! -- *Leonardo Marsaglia*. -- 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 This communication is for the use of the intended recipient only. It may contain information that is privileged and confidential. If you are not the intended recipient of this communication, the disclosure, copying, distribution or use hereof is prohibited. If you have received this communication in error, please advise me by return e-mail or by telephone and then delete it immediately. -- 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 -- *Leonardo Marsaglia*. -- *Leonardo Marsaglia*. -- 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)
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] Relay driver not working
On Fri, 2012-04-20 at 21:24 -0400, gene heskett wrote: On Friday, April 20, 2012 09:19:33 PM gene heskett did opine: On Friday, April 20, 2012 05:40:00 PM Dave Caroline did opine: On Fri, Apr 20, 2012 at 10:18 PM, gene heskett ghesk...@wdtv.com wrote: On Friday, April 20, 2012 05:18:06 PM Dave Caroline did opine: a common mistake is to assume collector is the middle pin like the npn but its the base Dave Caroline This one, according to the data sheet, is conventional, with the collector on the middle pin. which data sheet? I found http://www2.picturepush.com/photo/a/4802175/img/Polovodice/bd140.gif could be wrong as many sites are It sure as heck doesn't agree with the .pdf, the 4186.pdf from STE that his first URL gave me on a family of bugs including the bd140. No idea if the mail server will pass it, but that 79KiB file is attached. Dave Caroline The list moderator rejected the message, so go to the STE site and search for your own copy of 4186.pdf. It should prove my point, that the basing Viesturs used to build his circuit is wrong. Cheers, Gene I'm just getting into the middle of this thread, but if I recall, the last time we visited this circuit we found two sets of datasheets for the same device with different pin outs. Maybe a multimeter could sort out the pins. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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] Relay driver not working
On Saturday, April 21, 2012 01:27:51 AM Kirk Wallace did opine: On Fri, 2012-04-20 at 21:24 -0400, gene heskett wrote: On Friday, April 20, 2012 09:19:33 PM gene heskett did opine: On Friday, April 20, 2012 05:40:00 PM Dave Caroline did opine: On Fri, Apr 20, 2012 at 10:18 PM, gene heskett ghesk...@wdtv.com wrote: On Friday, April 20, 2012 05:18:06 PM Dave Caroline did opine: a common mistake is to assume collector is the middle pin like the npn but its the base Dave Caroline This one, according to the data sheet, is conventional, with the collector on the middle pin. which data sheet? I found http://www2.picturepush.com/photo/a/4802175/img/Polovodice/bd140.g if could be wrong as many sites are It sure as heck doesn't agree with the .pdf, the 4186.pdf from STE that his first URL gave me on a family of bugs including the bd140. No idea if the mail server will pass it, but that 79KiB file is attached. Dave Caroline The list moderator rejected the message, so go to the STE site and search for your own copy of 4186.pdf. It should prove my point, that the basing Viesturs used to build his circuit is wrong. Cheers, Gene I'm just getting into the middle of this thread, but if I recall, the last time we visited this circuit we found two sets of datasheets for the same device with different pin outs. Maybe a multimeter could sort out the pins. Oh, loverly. Yes, ID'ing the base is easy, it will have one Vbe (nominally 0.6 volts) of diode drop to the other two legs. But then which of the other two are emitter and collector? Since those show the base on different pins, I'd have to assume that which ever drawing shows the base on the correct pin as (probably) the correct device basing. In that event, measuring from the metal surface on the back of the device to see which leg it is less than 2 ohms to, would do a pretty god job of identifying the collector. The remaining leg then, by the process of elimination, is the emitter. Bear in mind I have actually seen devices that were claimed to be replacements for the OEM part number, that have had different base pinouts! Everybody has to have a gimmick... Cheers Kent, 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 Time as he grows old teaches all things. -- Aeschylus -- 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
