Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 06:37 schrieb Erik Christiansen: - wouldnt it be more readable to write: -- $var1 = $foo + 1 $var2 = 10 if $var1 $var 2 ... else ... endif -- Indeedy, but even the '$' is unnecessary. I'm not sure whether thats possible in all cases. There are several syntactic constructs - blocks, expressions, assignments and control structures. The noise in expressions really is only needed within blocks; in assignments, and expressions within control structure probably can be completely 'de-noised' and probably 'de-dollared' and partially 'de-hashed' too;). as Ken laid out, the tough decision is disambiguating within blocks by re-introducing whitespace as delimiter; or stay with using brackets to delimit expressions. I think its possible to: - make the bracketing requirement for expressions and assignments in control structure tests optional; - drop the # requirement for named variables references and assignments in above; an introducer for numbered params is still needed - make the bracketing requirement *within* expressions optional. - introduce more natural aliases for the EQ/NE/LT etc operators I'm unsure whether the () comment syntax can be disambiguated from normal function parameter lists like atan(param); this might need a backtracking parser or stay with brackets and there isnt much that gain. This is untested conjecture, but I think one could come up with a grammar which would still parse the current language and be able to write: sub func ;blablah endsub baz = 0.45 foo = atan[bar * 47.11] ; possible foo = atan(bar * 47.11) ; unsure - guess not; no much gain either #43 = foo / 10 if foo bar g10 x[foo * baz] else g0 y[baz] z#43 x[func[10]] ; likely possible g0 y[baz] z#43 x[func(10)] ; I guess not endif that's less filling, but in effect requires bracketing expressions ins block, without requiring it elsewhere, which is a bit confusing. It's one possible route. The other is the 'dont squash whitespace' route. That is a big decision since the latter isnt backwards compatible. What I could think of is use Scott's idea of a pretty printer for the current language, which could introduce whitespace in blocks as needed. The output would likely be compatible with a 'dont squash whitespace' parser. To stay with Ken's example, it could rewrite: 'X#AY#B' into 'X#A Y#B' after which it is possible to drop the # variable delimiters and rewrite again into new syntax: 'XA YB' which would be equivalent to 'X#A Y#B' in the old syntax (or 'X$A Y$A' - whatever the ensuing inspired discussion diligently shepherded by the EMC board will arrive at ;) that would mean that despite the non-backwards compatible language change automatic upgrade is possible Both in the code, selected in the config file or on the command line, perhaps? Or mandate a gcode+ keyword on the first line of input, to allow either type at run-time? the latter would break backwards compatibility - that keyword and the rest of the file in 'old rs274ngc' syntax wouldnt parse, at least not now and with old versions of linuxcnc. Manually, a custom regression testing framework, or move to DejaGnu? IMO the next person to introduce another piece of TCL to linuxcnc should be damned to use Forth exclusively for the rest of her life. The primary benefit of TCL was to get John Ousterhout tenure at Berkeley, but then LSD and BSD came from there too, no coincidence IMO ;) That shouldnt prevent us to look for a more comprehensive regression testing framework. Testing GUI applications 'end to end' is lacking sorely, btw. If we could move to a BNF specification of our permissible grammar, then the problem would diminish, I think. An example of a flex/bison parser for something which might eventually resemble rs274ngc, in c++, plumbed into the linuxcnc build system (Submakefile) is in http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/parser-v2-dev Its fairly useless and defunct right now but if somebody wants to play based on an example which builds its a start. The grammar in the fennic.net parser needs a lot of work, and the EBNF from the Tom Kramer paper too. -m -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question about tapered threading (etc)
On Sat, 28 Jan 2012 22:40:29 +, you wrote: Haven't seen the belated 2.5 yet... It has, indeed, been imminent for a long time. I suspect that a lot of the delay has been due to the EMC lawyers. Last time I asked here the reason given for the delay was bugs - not so long ago either. I have a suspicion that 2.6 will follow fairly shortly after 2.5. It is available as pre-compiled packages, and as far as I know has few bugs. Hope so, it's been far too long since last official update. Steve Blackmore -- -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
Viesturs, regardless of possible tuning questions, if I recall right, you are using a 24 volts supply for the stepper amplifiers. This seems a little low to me as I was using 90 volts on my dual Parker Hannifing amplifier/driver. I had stepper motors attached to the two slides of my lathe and never experienced any oscillations. The amps came to a maximum of about 30 kHz, but as the steppers were coupled directly to the spindles (no gears) they reached the spindle ends before frequency could grow any higher anyway. The motors have about 85 mm diameter and are labelled for 3 volts so there is a lot of momentum in this drive. When a slide accidentally hit the physical end of a way (no limit switches there), it usually turned off the 3 mm steel dowel I am using in the couplings. I think at your 24 volt level and the resulting maximum motor forces or angular momenta, you are working near the physical resonance limit where anything can happen. Try a higher power supply voltage in any case. Peter Viesturs La-cis schrieb: 2012/1/28 Peter C. Wallace p...@mesanet.com: OK so commutation is ok, but somthing is funny here. You said it oscillated even with a P of 1 and all else 0. Did it not oscillate with a P of 3? what is the difference between the setup now and when it oscillates? I will try to explain: I am trying to tune 2 motors simultaneously, because it is a gantry machine. So what I did few minutes ago: For both motors: all PID parameters set to 0 P = 3 I tried to jog the gantry at slow speed. At 240 mm/min it is smooth, at 480 mm/min still smooth, but at 676 mm/min there are spots, when one of motors stalls and oscillates in small amount at high frequency. I suspect that the stalling is due to some uneven load to motor, when moving forward. Anyway, I d not know, how to overcome such stalls and subsequent oscillation. Hitting F2 to disable and re-enable motion stops oscillation and I can jog forward. Until one of motors stalls and starts vibrating again. I do understand that final settings for both gantry motors might differ, I just think that in the beginning they could be tuned together as both of them are stalling now. Viesturs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
Peter, just as the name of threads says, I am trying to tune servo motors, not steppers :) I just checked - the supply voltage is 27,9 VDC, because 7i39 drives have 28 VDC limit. Ohh, and there is update: The motor that yesterday worked fine at 4000 mm/min, today is not working fine at that speed - it also stalls and starts oscillating at relatively high frequency... Just as the name of thread says - I have no idea wtf is wrong with this machine. I just remembered one thing that I had not mentioned, but which probably might make a difference - Keling servos are equipped with CUI AMT102 encoders. I recall that Jon Elson wrote some time ago that these encoders have a lag during change of acceleration, so I looked at that thread again. Is there anything I can do to confirm, if the encoders are the real problem of the instability of the feedback loop. Viesturs 2012/1/29 Peter Blodow p.blo...@dreki.de: Viesturs, regardless of possible tuning questions, if I recall right, you are using a 24 volts supply for the stepper amplifiers. This seems a little low to me as I was using 90 volts on my dual Parker Hannifing amplifier/driver. I had stepper motors attached to the two slides of my lathe and never experienced any oscillations. The amps came to a maximum of about 30 kHz, but as the steppers were coupled directly to the spindles (no gears) they reached the spindle ends before frequency could grow any higher anyway. The motors have about 85 mm diameter and are labelled for 3 volts so there is a lot of momentum in this drive. When a slide accidentally hit the physical end of a way (no limit switches there), it usually turned off the 3 mm steel dowel I am using in the couplings. I think at your 24 volt level and the resulting maximum motor forces or angular momenta, you are working near the physical resonance limit where anything can happen. Try a higher power supply voltage in any case. Peter Viesturs La-cis schrieb: 2012/1/28 Peter C. Wallace p...@mesanet.com: OK so commutation is ok, but somthing is funny here. You said it oscillated even with a P of 1 and all else 0. Did it not oscillate with a P of 3? what is the difference between the setup now and when it oscillates? I will try to explain: I am trying to tune 2 motors simultaneously, because it is a gantry machine. So what I did few minutes ago: For both motors: all PID parameters set to 0 P = 3 I tried to jog the gantry at slow speed. At 240 mm/min it is smooth, at 480 mm/min still smooth, but at 676 mm/min there are spots, when one of motors stalls and oscillates in small amount at high frequency. I suspect that the stalling is due to some uneven load to motor, when moving forward. Anyway, I d not know, how to overcome such stalls and subsequent oscillation. Hitting F2 to disable and re-enable motion stops oscillation and I can jog forward. Until one of motors stalls and starts vibrating again. I do understand that final settings for both gantry motors might differ, I just think that in the beginning they could be tuned together as both of them are stalling now. Viesturs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 09:31, Michael Haberler wrote: Am 29.01.2012 um 06:37 schrieb Erik Christiansen: -- $var1 = $foo + 1 $var2 = 10 if $var1 $var 2 ... else ... endif -- Indeedy, but even the '$' is unnecessary. I'm not sure whether thats possible in all cases. There are several syntactic constructs - blocks, expressions, assignments and control structures. The noise in expressions really is only needed within blocks; in assignments, and expressions within control structure probably can be completely 'de-noised' and probably 'de-dollared' and partially 'de-hashed' too;). To 'de-hash' our cleaner gcode, an alternative means of identifying numbered parameters would be required. Otherwise they'd be indistinguishable from simple integers. My personal preference would be to use the '$' freed up from variable names to identify numbered parameters, freeing '#' for the comment delimiter, thus completely disambiguating func (foo + $100) # Comment. as Ken laid out, the tough decision is disambiguating within blocks by re-introducing whitespace as delimiter; or stay with using brackets to delimit expressions. Perhaps I'm failing to imagine sufficiently pathological syntax cases, but the only inescapable need for whitespace floating before my eyes is two consecutive names, and I don't think that occurs in gcode. There will always be either a parenthesis or operator in between, I suspect. I think its possible to: - make the bracketing requirement for expressions and assignments in control structure tests optional; - drop the # requirement for named variables references and assignments in above; an introducer for numbered params is still needed - make the bracketing requirement *within* expressions optional. - introduce more natural aliases for the EQ/NE/LT etc operators +1 I'm unsure whether the () comment syntax can be disambiguated from normal function parameter lists like atan(param); this might need a backtracking parser or stay with brackets and there isnt much that gain. I know of no other laguage which has a similar comment kludge. We can also move up to the standard of having an unambiguous comment delimiter. One way is described above. It has the merit of increased consistency with scripting languages encountered by LinuxCNC integrators, reducing language whiplash when we go from one to another. This is untested conjecture, but I think one could come up with a grammar which would still parse the current language and be able to write: sub func ;blablah endsub baz = 0.45 foo = atan[bar * 47.11] ; possible foo = atan(bar * 47.11) ; unsure - guess not; no much gain either Language insularity does have an ongoing cost. I'd be interested to hear whether the broad user base thinks the last line above looks more like a function, than the preceding one. Running with parallel distinct parsers, and a switch word in the input, has the major advantage that there will be no regression in the old parser due to the new, and grammar conflicts which might arise in a combined parser are effortlessly avoided. Trying to be both Arthur and Martha, at the one time, is usually much more difficult than settling for alternation. #43 = foo / 10 While that could be 'de-hashed' without an alternative numbered parameter identifier, I don't see how you'd propose to handle: #43 = foo / #44 if foo bar g10 x[foo * baz] else g0 y[baz] z#43 x[func[10]] ; likely possible g0 y[baz] z#43 x[func(10)] ; I guess not endif that's less filling, but in effect requires bracketing expressions ins block, without requiring it elsewhere, which is a bit confusing. With the minor grammar change outlined above, we could have: g0 y[baz] z$43 x[func(10)] # I guess so. To declutter further, this is readily parsable with a simple grammar: g0 y baz; z $43; x func(10); # Jeez, readable or wot? would not necessitate a ' ' delimiter. And it would be just as parsable if written: g0 ybaz; z$43; xfunc(10); # Not as readable, is it? I might need a stateful lexer to do that easily, but they're simple enough in lex. (So I often use them straight off.) Oh, even the latter form would allow names which start with an axis letter, e.g.: g0 yyaz; z$43; xzunc(10); # Not as readable, is it? It's one possible route. The other is the 'dont squash whitespace' route. That is a big decision since the latter isnt backwards compatible. Still haven't seen a case which needs space delimiters. (While I like whitespace for readability, I don't favour dependence on it in the grammar, because humans can't always find the space bar. Be demanding in your output, but tolerant of your input. is a good mantra for both a coder and (to a lesser extent) a grammar designer.) ... Or mandate a gcode+ keyword on the first line of input, to allow either type at run-time? the latter would break backwards compatibility - that keyword
Re: [Emc-users] question on gcode parsing
On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote: While that could be 'de-hashed' without an alternative numbered parameter identifier, I don't see how you'd propose to handle: #43 = foo / #44 I am puzzled how you would handle foo = 10 oo = 1 g1fooZ100 Is it not a significant problem that every single letter of the alphabet is already a G-code command? -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. FF2 = Acceleration Feed Forward Gain or Friction Feed Forward Gain. I would like to update the docs with some descriptive text in addition to 0th order feed forward gain as that and the other descriptions only seem to make sense to a mathematics professor. Position Feed Forward Gain. Compensates for position-based effects in a system. Its effect is similar to having a spring attached to the stage. (DAC counts / position counts) Velocity Feed Forward Gain. Compensates for velocity-based friction or similar effects in a system. (DAC counts * (commanded position counts / sample period)) Acceleration Feed Forward Gain. Compensates for mass in a system. (DAC counts / (commanded position counts / sample period^2 )) Friction Feed Forward Gain. Compensates for Friction in a stage. (DAC counts) Thanks John On 1/28/2012 10:28 AM, Jon Elson wrote: John Thornton wrote: Jon, What is FF0 used for if it should be set to 0 for a motion axis? I used to think it was useless, but if you use the PID for a spindle speed control, for instance, then it is quite useful for a velocity servo. It serves about the same purpose as FF1 in a positioning servo. In a positioning servo, it would add an offset proportional to position. In a velocity servo, it would add an offset proportional to speed, thereby correcting for finite gain in the loop. Jon -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 1/29/2012 12:37 AM, Erik Christiansen wrote: On 25.01.12 21:22, Michael Haberler wrote: [this should move to emc-developers, which is why I'm cc'ing there] It would be a pity if the rest of us were to be excluded. It is a very interesting discussion, and the EMC issue was secretive enough. Doing the same with possible user syntax improvements seems very unhelpful. Erik: There's nothing secretive about emc-developers. Anyone can subscribe to the list and anyone can peruse its archive of messages. (see the Wiki) Perhaps they would feel less like exclusionary clubs had the two lists been named, say, emc-usage and emc-technical or emc-internals to reflect their topical themes rather than their target audiences. I try to judge which list is more appropriate for any new message I compose. On the other hand, I read and respond to messages regardless of where they show up. The record shows the same to be true for Michael and many others. Hence, deeply technical discussions can break out on the emc-users list as the result of an initial question. Less frequently, questions and ensuing discussions typical of new-user problems pop up on emc-developers. No harm. No foul. For me a bigger problem is the nature of email. We click reply and the subject line is copied over directly. This makes clear what message we are responding to but not what part of the message we are responding to. By the second reply, it isn't even clear which message, the original or one of its replies, is being responded to. Case in point: I am talking about administrative functioning of the email lists in response to a point you raised in your message about question of gcode parsing. This kind of cloaking happens daily, where the content of a series of replies may wander all over the map while the subject line stays distressingly constant. The real world of information and its classification is considerably messier than the theoretical one. Sigh. Regards, Kent -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 12:59, andy pugh wrote:
On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:
While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:
#43 = foo / #44
I am puzzled how you would handle
foo = 10
If the concern is that it could be confused with F 10, then I'll
cheerfully admit that F should be a keyword in the grammar, as it is
to us, and so no variable may be named F. Thus, there is no problem.
If we imagine a case where disambiguation were not so simple, then a
quick way out is manually coded lookahead. That's not needed here.
oo = 1
OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords, sub, call, endsub, etc. Each is easily recognised by the
lexer, and a unique token ID passed to the parser, so that it
immediately knows which grammar subclauses apply.
We won't be able to have a variable called call, or a function called
endsub, but oo isn't a keyword, so here it's unambiguously a
variable name, since it is preceded by neither sub nor call.
g1fooZ100
Is there an axis identifier missing here? If it's supposed to be:
g1YfooZ100
Then the gcode ends at the numeric - alpha transition. The grammar then
demands some {axis_identifier,magnitude} pairs, optionally with embedded
stuff like feedrate. Thus Y foo and Z 100 are easily picked out,
whether spaced or not. Since there is no '#' in front of 100, it is a
literal numeric.
There is no parsing complexity in any of these cases.
Is it not a significant problem that every single letter of the
alphabet is already a G-code command?
No, not of itself. So long as we have an unambiguous grammar, then the
parser has no trouble. The grammar tells the parser when a
[xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first
letter of a name. To avoid the constraint that a name could not begin
with one of those letters, I would need to employ a stateful lexer, but
that is easy. The parser then fine tunes the lexer's eyesight, token by
token, as it walks along a line of gcode.
Incidentally, spaces in the input are usually eliminated by one line in
the lexer. The parser never sees spaces, so that one line is all the
space handling there is. (Well, that's how I do it, 'cos it's easier.)
The parser is automatically generated from the BNF grammar and its
embedded output actions (coded in C), so it's only necessary to write
the lexer, the grammar, and the leaf actions. The fun begins if the
grammar is ambiguous, resulting in conflicts. Debugging that adds to the
entertainment value.
But I haven't seen a troublesome gcode example yet. :-)
Erik
--
... with proper design, the features come cheaply. This approach is
arduous, but continues to succeed.-Dennis Ritchie
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On 29 January 2012 13:23, John Thornton bjt...@gmail.com wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. FF2 = Acceleration Feed Forward Gain or Friction Feed Forward Gain. I would like to update the docs with some descriptive text in addition to 0th order feed forward gain as that and the other descriptions only seem to make sense to a mathematics professor. There is a reason that mathematicians talk the way they do, it is to be unambiguous in the general case. I think the best solution would be for all LinuxCNC users to take a maths degree, but that might be impractical. The problem with your explanation is that it assumes a position-command / position-feedback system and there are other possibilities that are not that unusual. (closed-loop spindle control is one) FF0: This term adds a value to the PID output directly proportional to the input. It is useful for any system where a steady-state output requires a non-zero input. The most likely case is a closed-loop spindle speed control, where 10V might give 1000rpm, and a FF0 gain of 0.01 would mean that the PID terms were only required as correction, not the basic output value. This term would not normally be used with a position-feedback system, except possibly to compensate for the effects of a spring counterbalance. FF1: This term adds a value to the PID output proportional to the rate of change of the input. So, if the input is position, FF1 is proportional to velocity demand. If the input is rpm then FF1 is proportional to angular acceleration/torque demand. This term can often be very useful to increase the responsiveness of a position-feedback system with velocity-control servos. FF2: This adds a value to the PID output which is proportional to the rate of change of the rate of change of the input (mathematically, the second order differential with respect to time). In a typical position-control loop this would correspond to the acceleration. (in a velocity-control system it would correspond to the jerk). In the position-control case this would be useful to compensate for the mass of a heavy table, for example. FF3: This value does not exist and has been inserted to see who is still paying attention. A negative FF3 term could be used to add a degree of jerk control to a position-feedback system. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29 January 2012 14:02, Erik Christiansen dva...@internode.on.net wrote: oo = 1 OK, O Codes. They'll all go in a declutter, replaced by their naked keywords, No, that is creating a second named parameter in order to be more ambiguous later: g1fooZ100 Is there an axis identifier missing here? If it's supposed to be: g1YfooZ100 And here is the question? What did I mean? I was actually meaning feed at the rate defined by the parameter oo, but how is the parser to know that is what I wanted rather than there being a missing S (for example) in G1 Sfoo Z100 (not a totally random case, my machine has a very reluctant S key, I very often type M31000 in MDI) I think we should keep the # for all variables. It is what humans reading G-code expect to see. A linked point is that we seem to be discussing mainly human-generated G-code, whereas a large proportion of G-code executed by EMC2 machines is machine-generated. As well as discussing machine-parsing we also might need to consider machine-generation. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] [OT] Mailing list admin netiquette [Was: question on gcode parsing]
On 29.01.12 08:57, Kent A. Reed wrote: Erik: There's nothing secretive about emc-developers. Anyone can subscribe to the list and anyone can peruse its archive of messages. (see the Wiki) My point was not self-referential, it related to keeping the discussion in front of all users. I feel that the user base should see what is afoot, and throw roses or overripe fruit, as appropriate. Anyway, there were just on 1200 emails waiting for me after a week and a half out on the farm. Adding another list doesn't appeal much. (Unless this lex/bison thing takes off this time round.) For me a bigger problem is the nature of email. We click reply and the subject line is copied over directly. This makes clear what message we are responding to but not what part of the message we are responding to. Forgive me please, for pointing out that only fullquoters cause this problem. Anyone who makes the effort to selectively cut all but the minimum relevant quote, as you have efficiently done, makes entirely explicit what he's responding to. In-line replies do too, just with much more effort on the part of maybe several hundred readers. By the second reply, it isn't even clear which message, the original or one of its replies, is being responded to. Case in point: I am talking about administrative functioning of the email lists in response to a point you raised in your message about question of gcode parsing. This kind of cloaking happens daily, where the content of a series of replies may wander all over the map while the subject line stays distressingly constant. If we use threaded mail readers, then threads are presented groupwise. In a thread of 100 posts, I see clearly who replied to whom, on what date, and at what time. Any two-party ping-pong, or a flurry of replies to Viesturs stand out clearly. And if we make the effort to update the subject line, as I have done, then the post is still presented in the thread by my mailreader, but the subject immediately identifies it as a digression. There being no cloaking, recipients are then empowered to skip it, unread. To my vim I've added a mapping so that an Alt-W brackets the existing subject with [Was: and ], leaving the cursor in front of the first automatic insert, so that I only need to type the new subject. Such convenience helps me maintain the discipline of keeping the subject header relevant. (Memory permitting.) The real world of information and its classification is considerably messier than the theoretical one. Sigh. The only thing which really throws me on this list is posts which fail to quote the text to which they're replying. Separating what should have been quoted, and what is reply, is then quite difficult. My mailreader lets me skip monstrous fullquotes with a keystroke, and a plug-in helps a bit as well. Oh, and if a thread is clearly not up my alley, then I can delete all its posts with one double keystroke. Judicious choice of mailreader/editor, customised for individual convenience, makes the task of catching up on 1200 posts much more manageable. Erik -- Do not do unto others as you would they should do unto you. Their tastes may not be the same. - George Bernard Shaw -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On dom, 2012-01-29 at 14:04 +0200, Viesturs Lācis wrote: Peter, just as the name of threads says, I am trying to tune servo motors, not steppers :) I just checked - the supply voltage is 27,9 VDC, because 7i39 drives have 28 VDC limit. Ohh, and there is update: The motor that yesterday worked fine at 4000 mm/min, today is not working fine at that speed - it also stalls and starts oscillating at relatively high frequency... Just as the name of thread says - I have no idea wtf is wrong with this machine. I just remembered one thing that I had not mentioned, but which probably might make a difference - Keling servos are equipped with CUI AMT102 encoders. I recall that Jon Elson wrote some time ago that these encoders have a lag during change of acceleration, so I looked at that thread again. Is there anything I can do to confirm, if the encoders are the real problem of the instability of the feedback loop. Viesturs Hallo Viesturs, i don't remember who suggested, but i've read, with those encoders, it's better to glue them to the rotating axle, because they can slip at high speeds and during fast accelerations. If it was like that, i think it's possible the resulting issue that you have. Or i would try something with the encoders connection. maybe a not perfect conctact. Davide. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
2012/1/29 Spiderdab 77...@tiscali.it: Hallo Viesturs, i don't remember who suggested, but i've read, with those encoders, it's better to glue them to the rotating axle, because they can slip at high speeds and during fast accelerations. Thanks! I already did that this morning. Did not help... Or i would try something with the encoders connection. maybe a not perfect conctact. I am now reading a thread, started by Jon Elson in June 2011 on developers' list about these encoders. It turns out that they have acceleration lag, so overall conclusion - do not use them in CNC machine! I have yet to read it all through - maybe there is a clue for some workaround. Viesturs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] [OT] Mailing list admin netiquette [Was: question on gcode parsing]
On 1/29/2012 9:52 AM, Erik Christiansen wrote: And if we make the effort to update the subject line, as I have done, then the post is still presented in the thread by my mailreader, but the subject immediately identifies it as a digression. There being no cloaking, recipients are then empowered to skip it, unread. And that's the key, but many list participants don't use as good a mailreader and see only that the thread was broken. A number of times in the past, I've tried to update a subject line in the midst of a thread to reflect the shift in topic, only to see the subject line revert in further replies. As the GBS quote in your email sig put it ...tastes may not be the same. Regards, Kent -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On 29 January 2012 15:10, Viesturs Lācis viesturs.la...@gmail.com wrote: I am now reading a thread, started by Jon Elson in June 2011 on developers' list about these encoders. It turns out that they have acceleration lag, so overall conclusion - do not use them in CNC machine! I have yet to read it all through - maybe there is a clue for some workaround. There is a jumper, I believe. Only accessible if you haven't glued the encoder to the shaft :-) -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
Sorry, Viesturs, that was a language glitch of mine. Servo is used in German as a general classification for anything moving with power assistance, above all in the motor vehicle sector, e. g. Servolenkung (power steering) or Servobremse (power brake) as well as in Ruderservo (RC model actuator) etc. Only as a specific technical term it is used in the field of control technology as a name for a feedback controlled continous motor drive. At this moment, regarding my own (stepper) gear I didn't even think of someone else using servomotors for moving machine elements. Peter Viesturs La-cis schrieb: Peter, just as the name of threads says, I am trying to tune servo motors, not steppers :) I just checked - the supply voltage is 27,9 VDC, because 7i39 drives have 28 VDC limit. Ohh, and there is update: The motor that yesterday worked fine at 4000 mm/min, today is not working fine at that speed - it also stalls and starts oscillating at relatively high frequency... Just as the name of thread says - I have no idea wtf is wrong with this machine. I just remembered one thing that I had not mentioned, but which probably might make a difference - Keling servos are equipped with CUI AMT102 encoders. I recall that Jon Elson wrote some time ago that these encoders have a lag during change of acceleration, so I looked at that thread again. Is there anything I can do to confirm, if the encoders are the real problem of the instability of the feedback loop. Viesturs 2012/1/29 Peter Blodow p.blo...@dreki.de: Viesturs, regardless of possible tuning questions, if I recall right, you are using a 24 volts supply for the stepper amplifiers. This seems a little low to me as I was using 90 volts on my dual Parker Hannifing amplifier/driver. I had stepper motors attached to the two slides of my lathe and never experienced any oscillations. The amps came to a maximum of about 30 kHz, but as the steppers were coupled directly to the spindles (no gears) they reached the spindle ends before frequency could grow any higher anyway. The motors have about 85 mm diameter and are labelled for 3 volts so there is a lot of momentum in this drive. When a slide accidentally hit the physical end of a way (no limit switches there), it usually turned off the 3 mm steel dowel I am using in the couplings. I think at your 24 volt level and the resulting maximum motor forces or angular momenta, you are working near the physical resonance limit where anything can happen. Try a higher power supply voltage in any case. Peter Viesturs La-cis schrieb: 2012/1/28 Peter C. Wallace p...@mesanet.com: OK so commutation is ok, but somthing is funny here. You said it oscillated even with a P of 1 and all else 0. Did it not oscillate with a P of 3? what is the difference between the setup now and when it oscillates? I will try to explain: I am trying to tune 2 motors simultaneously, because it is a gantry machine. So what I did few minutes ago: For both motors: all PID parameters set to 0 P = 3 I tried to jog the gantry at slow speed. At 240 mm/min it is smooth, at 480 mm/min still smooth, but at 676 mm/min there are spots, when one of motors stalls and oscillates in small amount at high frequency. I suspect that the stalling is due to some uneven load to motor, when moving forward. Anyway, I d not know, how to overcome such stalls and subsequent oscillation. Hitting F2 to disable and re-enable motion stops oscillation and I can jog forward. Until one of motors stalls and starts vibrating again. I do understand that final settings for both gantry motors might differ, I just think that in the beginning they could be tuned together as both of them are stalling now. Viesturs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy
Re: [Emc-users] Servo tuning - wtf?
2012/1/29 andy pugh bodge...@gmail.com: On 29 January 2012 15:10, Viesturs Lācis viesturs.la...@gmail.com wrote: I am now reading a thread, started by Jon Elson in June 2011 on developers' list about these encoders. It turns out that they have acceleration lag, so overall conclusion - do not use them in CNC machine! I have yet to read it all through - maybe there is a clue for some workaround. There is a jumper, I believe. Only accessible if you haven't glued the encoder to the shaft :-) I took one of them off, I see 4 DIP switches, but do not see a jumper. Their manual also does not show, where on that pcb jumper would be located. Viesturs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On Sun, 29 Jan 2012, Viesturs L?cis wrote: Date: Sun, 29 Jan 2012 14:04:43 +0200 From: [UTF-8] Viesturs L?cis viesturs.la...@gmail.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Servo tuning - wtf? Peter, just as the name of threads says, I am trying to tune servo motors, not steppers :) I just checked - the supply voltage is 27,9 VDC, because 7i39 drives have 28 VDC limit. Ohh, and there is update: The motor that yesterday worked fine at 4000 mm/min, today is not working fine at that speed - it also stalls and starts oscillating at relatively high frequency... Just as the name of thread says - I have no idea wtf is wrong with this machine. As I metioned earlier, please check if you are losing/gaining encoder counts, this will cause symptoms like you are seeing. Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 14:20, andy pugh wrote: On 29 January 2012 14:02, Erik Christiansen dva...@internode.on.net wrote: oo = 1 OK, O Codes. They'll all go in a declutter, replaced by their naked keywords, No, that is creating a second named parameter in order to be more ambiguous later: Yes, the variable assignment is unmistakable, but the sneaky intent wasn't. :-) g1fooZ100 Is there an axis identifier missing here? If it's supposed to be: g1YfooZ100 And here is the question? What did I mean? I was actually meaning feed at the rate defined by the parameter oo, but how is the parser to know that is what I wanted rather than there being a missing S (for example) in G1 Sfoo Z100 (not a totally random case, my machine has a very reluctant S key, I very often type M31000 in MDI) As it should, a parser slavishly applies its grammar to the input which we _do_ provide, not what we didn't. In the BNF grammar, we need to specify that a feedrate_clause may appear after a g1, as an alternative to an axis_motion. That causes the 'f' to be recognised as a keyword, which in turn causes oo to be detected as a variable name. It is equally straightforward to allow and optional 'S' clause to this part of the grammar. What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part of the grammar tree for G1 then gets the handling of the common clauses for free, and we only need to tack on the stuff that G0 doesn't have. Not only does this reduce coding and testing effort, but it ensures consistency across commands, where it should exist. i.e. Anything which is even moderately common in gcode should be specified only once in the grammar. To allow removal of the square brackets currently containing an axis_motion clause, we need alternative clause termination. Upthread I suggested ';', as is used between elements of a for loop in most languages. Your line then becomes: g1foo;Z100 Or if we are in industry, and someone else might need to read it: g1 foo; z100 # Either GFZ or gfz is easier on humans. Now a LALR(1) parser can deal not only with that, but also with a variable named foo or Foo, so long as we configure a stateful lexer, which is able to look for only a keyword immediately after the G1, and resume seeing a variable name after the f keyword is consumed. I think we should keep the # for all variables. It is what humans reading G-code expect to see. That is admirably achieved by changing nothing, fully maintaining historical authenticity. I respect such a preference. The purpose of the proposed changes is expressly to eliminate such useless visual clutter. My expectation is that if we proceed to implementation, then users will choose to use one syntax or the other. The two need to be equivalent in function, but the old clutter need not adhere to the more readable alternative syntax. A linked point is that we seem to be discussing mainly human-generated G-code, whereas a large proportion of G-code executed by EMC2 machines is machine-generated. As well as discussing machine-parsing we also might need to consider machine-generation. Yes, it needs to be considered, but I don't quite see an impact. Compatible machine-generated gcode is currently in the historical format, and it is adequately handled by the existing parser. The purpose of the decluttered parser is to allow human-generated gcode to become human readable. If, in time, some machine-generated gcode should transition to the more readable format, then that's OK too. One thing with a lex/bison based interpreter is that the implementation itself contains a BNF specification of the legal grammar. Whether input is legit or not is easily looked up in one place. And if error messages are not sufficiently explicit, then it's fairly easy to see if steps can easily be taken to fix it. Erik -- Habit is habit, and not to be flung out of the window by any man, but coaxed down-stairs a step at a time. - Mark Twain, Pudd'nhead Wilson's Calendar -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] DIY output driver
Viesturs, if your laser seems too bulky - have you tried transporting the beam to the work head via optic fibres? In the laser division of my former company, we had several powerful (many, say, 50 watts output) gold vapor ans other lasers that weighed about a ton each and filled a whole labratory room. The beams were focused by a microscope objective and transported all the way through the building by a single glass fibre (later on by plastic wires, try a guitar string!) into the surgery room. Sometimes the fibres had to be cut off as the beam burned their light entrance area. Peter Viesturs La-cis schrieb: 2012/1/28 Rafael Skodlar ra...@linwin.com: Of course that won't work with most if not all the suggestions I've seen so far. If I understand it correctly, your laser already has a circuit to drive it at reasonable current to do it's magic. Circuit I suggested earlier was under assumption you have a bare laser diode connected to it. You cannot daisy chain circuits one after another and expect laser to work properly. Relays are out of question IMO because they are too slow mechanical devices with many other drawbacks for this application. I see no reason to bring in solid state relays into the picture either. You are not driving high voltage stuff. You either need to modify your PCB that came with the laser diode or build a new circuit. Maybe you can reverse engineer that PCB and use one spot to inject signal from the EMC side. Ed, Kirk, Rafael, thank You! Given my lack of skills in electronics, I think that interfering and modifying the pcb that comes with laser is the last thing I want to do. Here are some pics of the laser and its pcb I took late in last night with my phone (it was late enough that I forgot to upload them yesterday evening): http://picpaste.com/2012-01-27_21.54.59-QzJqS24n.jpg http://picpaste.com/2012-01-27_21.55.16-mx4U2GiU.jpg http://picpaste.com/2012-01-27_21.55.36-wtANcKHw.jpg http://picpaste.com/2012-01-27_21.56.28-ySpITI8d.jpg I think that I will try the use a relay approach, because: 1) it is simple enough for me to do it; 2) it does not require modifying existing laser's board; 3) it will be fast enough for me, because I am going to use the laser in a a la milling fashion - move laser along the line to be burned instead of moving it back and forth and switching it on, when necessary, because: a) the laser is weak, so by definition it can't burn quickly; b) machine is heavy and relatively slow, compared to normal laser engravers, so it would not be able to handle very powerful laser anyway; c) g-code generation - I have no idea, how to generate g-code for normal laser engraving, but I know, how to do it for a la milling style. BTW client was happy, when he saw the first hand-burned lines in the wood that I managed to do last night in that small moment, when the laser was working... Viesturs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] [OT] Mailing list admin netiquette [Was: question on gcode parsing]
On 29.01.12 10:23, Kent A. Reed wrote: On 1/29/2012 9:52 AM, Erik Christiansen wrote: And if we make the effort to update the subject line, as I have done, then the post is still presented in the thread by my mailreader, but the subject immediately identifies it as a digression. There being no cloaking, recipients are then empowered to skip it, unread. And that's the key, but many list participants don't use as good a mailreader and see only that the thread was broken. A number of times in the past, I've tried to update a subject line in the midst of a thread to reflect the shift in topic, only to see the subject line revert in further replies. As the GBS quote in your email sig put it ...tastes may not be the same. But Kent, the thread is not broken if the In-Reply-To: header is present in the reply, as it is in yours: In-Reply-To: 20120129145241.GD3857@ratatosk That is the primary threading link, _not_ the subject. It is the mail reader which is broken if it is so useless that it only uses the subject for threading. But you're right. We're often content to muddle through with less effective tools and methods, because the brief discomfort of learning something more effective is more acute than wallowing in the sub-optimal. Erik (Who should give up. It's 3 a.m., for the sky-fairy's sake!) -- Never worry about theory as long as the machinery does what it's supposed to do. - Robert A. Heinlein -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 1/29/2012 10:55 AM, Erik Christiansen wrote: ... What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part of the grammar tree for G1 then gets the handling of the common clauses for free, and we only need to tack on the stuff that G0 doesn't have. Not only does this reduce coding and testing effort, but it ensures consistency across commands, where it should exist. i.e. Anything which is even moderately common in gcode should be specified only once in the grammar. Whatever qualms I may have about the difficulty of interjecting meaningful error messages into an interpreter based on lex'ing and parsing is overcome by the benefits you point out here. Regards, Kent -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] DIY output driver
2012/1/29 Peter Blodow p.blo...@dreki.de: Viesturs, if your laser seems too bulky - have you tried transporting the beam to the work head via optic fibres? The laser itself is less than 100g, so that is not the problem. The machine itself has heavy construction as its primary task is wood routing. That is why it is not very agile. Viesturs -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On 29 January 2012 15:47, Viesturs Lācis viesturs.la...@gmail.com wrote: I took one of them off, I see 4 DIP switches, but do not see a jumper. Their manual also does not show, where on that pcb jumper would be located. http://www.amtencoder.com/Resources/Frequently-Asked-Questions#3 -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Nitpicking , was: Servo tuning - wt_?
On Sun, 2012-01-29 at 16:16 +, andy pugh wrote: On 29 January 2012 15:47, Viesturs Lācis viesturs.la...@gmail.com wrote: I took one of them off, I see 4 DIP switches, but do not see a jumper. Their manual also does not show, where on that pcb jumper would be located. http://www.amtencoder.com/Resources/Frequently-Asked-Questions#3 Maybe I'm too picky, but WT_ may be considered offensive to some. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On Sunday, January 29, 2012 12:00:01 PM andy pugh did opine: On 29 January 2012 13:23, John Thornton bjt...@gmail.com wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. FF2 = Acceleration Feed Forward Gain or Friction Feed Forward Gain. I would like to update the docs with some descriptive text in addition to 0th order feed forward gain as that and the other descriptions only seem to make sense to a mathematics professor. Bingo John. There is a reason that mathematicians talk the way they do, it is to be unambiguous in the general case. I think the best solution would be for all LinuxCNC users to take a maths degree, but that might be impractical. Well, not too practical, and certainly at my age. My math extends into the trig realm because it has had to in the electronics field, but the actual operation (sin,tan,hyp) are things that to me are not at all obvious, but I have an idea what the answer should look like so I grab my TI-35 or whatever, and see which gives me the good answer I need, usually without paying attention to which of those function families it was that gave me the correct answer. The problem with your explanation is that it assumes a position-command / position-feedback system and there are other possibilities that are not that unusual. (closed-loop spindle control is one) FF0: This term adds a value to the PID output directly proportional to the input. It is useful for any system where a steady-state output requires a non-zero input. The most likely case is a closed-loop spindle speed control, where 10V might give 1000rpm, and a FF0 gain of 0.01 would mean that the PID terms were only required as correction, not the basic output value. This term would not normally be used with a position-feedback system, except possibly to compensate for the effects of a spring counterbalance. What if the spring is either too much or too little, this seems to invite the need for a non-symmetrical FF0 function. FF1: This term adds a value to the PID output proportional to the rate of change of the input. So, if the input is position, FF1 is proportional to velocity demand. If the input is rpm then FF1 is proportional to angular acceleration/torque demand. This term can often be very useful to increase the responsiveness of a position-feedback system with velocity-control servos. I don't know enough about this to comment since all my teeny stuff is stepper driven. FF2: This adds a value to the PID output which is proportional to the rate of change of the rate of change of the input (mathematically, the second order differential with respect to time). In a typical position-control loop this would correspond to the acceleration. (in a velocity-control system it would correspond to the jerk). In the position-control case this would be useful to compensate for the mass of a heavy table, for example. Now, here is something that could even be useful to me. What is needed as I see it, is some way to convert the tables weight (mass actually) into something reasonably approximating the correct FF2 setting. Having example maths included in the description would ISTM, be a huge amount of help, lots more than the general recommendation of starting at .01 and working up. IOW, it the table weighs 30 pounds, or the table weighs 3000 pounds, it should be able to make an 'optimum' starting value a calculate-able item. I think it would have to be peak controlled by the individual stepgens MAX_ACCEL limits of course. FF3: This value does not exist and has been inserted to see who is still paying attention. A negative FF3 term could be used to add a degree of jerk control to a position-feedback system. See, I'm still reading... And on the face of it, reads like it could be a useful to have function. But I didn't see the word 'stiction' in the above, and this is largely independent of mass in my mind. Its also quite real in my Z axis in particular. Probably somewhat reducible by more precise counterweight spring tensioning, but with the limited length of the bearing surface available, not likely a totally eliminate-able item. It IS going to rock and tilt with only a 3.5 bearing length on the posts ways. Not much, but I can measure it with a dial indicator. A users $0.02. 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 Do not handicap your children by making their lives easy. -- Robert Heinlein -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
Re: [Emc-users] Nitpicking , was: Servo tuning - wt_?
On 1/29/2012 12:03 PM, Kirk Wallace wrote: On Sun, 2012-01-29 at 16:16 +, andy pugh wrote: On 29 January 2012 15:47, Viesturs Lācisviesturs.la...@gmail.com wrote: I took one of them off, I see 4 DIP switches, but do not see a jumper. Their manual also does not show, where on that pcb jumper would be located. http://www.amtencoder.com/Resources/Frequently-Asked-Questions#3 Maybe I'm too picky, but WT_ may be considered offensive to some. Hmmm... Worldly Technological Failure ? ;-) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] IRC thread with cradek from yesterday about G38.2 not working
Hi Chris; I think I may have it grokked as to why it wasn't working yesterday. I wasn't giving the G38.2 a z value that would have gone more than a thou past the expected contact detection based on my fear of damaging the gage I had just made, and my thoughts on this overnight came to the conclusion that if it was already IN the decel ramp to stop, and the contact was triggered in that time frame, the contact was missed because it was already doing the stop. At that speed (F0.5), a deadband so to speak of maybe 2 thou max, and growing with the commanded F passed I'd assume. When I gave it another thou to search in is when it started working. Is this making any sense? The gage can in fact absorb as much as 30 thou of over travel by a blunt object although sharp tools would be another matter, it is a piece of .068 thick dbl-sided pcb material, with 2 9/32 holes fitted with rubber grommets, on 1.35 centers, with the target contact point centered between the pair of 4-40 bolts thru the grommets, so the pcb could flex downward quite a bit if it had to, both from its own flexibility and perhaps a small crushing of the grommets. 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 Drunks are rarely amusing unless they know some good songs and lose a lot a poker. -- Karyl Roosevelt -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 13:59 schrieb andy pugh: On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote: While that could be 'de-hashed' without an alternative numbered parameter identifier, I don't see how you'd propose to handle: #43 = foo / #44 I am puzzled how you would handle foo = 10 oo = 1 g1fooZ100 Is it not a significant problem that every single letter of the alphabet is already a G-code command? those can be disambiguated through the '=' which makes it an assignment statement wheres the last one is a block the meaning of 'oo' or 'foo' need not be resolved until its clear whether the line is a block or an assignment statement (I *think* ;) -m -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 1/29/2012 9:02 AM, Erik Christiansen wrote:
On 29.01.12 12:59, andy pugh wrote:
On 29 January 2012 12:29, Erik Christiansendva...@internode.on.net wrote:
While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:
#43 = foo / #44
I am puzzled how you would handle
foo = 10
If the concern is that it could be confused with F 10, then I'll
cheerfully admit that F should be a keyword in the grammar, as it is
to us, and so no variable may be named F. Thus, there is no problem.
If we imagine a case where disambiguation were not so simple, then a
quick way out is manually coded lookahead. That's not needed here.
oo = 1
OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords, sub, call, endsub, etc. Each is easily recognised by the
lexer, and a unique token ID passed to the parser, so that it
immediately knows which grammar subclauses apply.
We won't be able to have a variable called call, or a function called
endsub, but oo isn't a keyword, so here it's unambiguously a
variable name, since it is preceded by neither sub nor call.
g1fooZ100
Is there an axis identifier missing here? If it's supposed to be:
g1YfooZ100
Then the gcode ends at the numeric - alpha transition. The grammar then
demands some {axis_identifier,magnitude} pairs, optionally with embedded
stuff like feedrate. Thus Y foo and Z 100 are easily picked out,
whether spaced or not. Since there is no '#' in front of 100, it is a
literal numeric.
There is no parsing complexity in any of these cases.
Is it not a significant problem that every single letter of the
alphabet is already a G-code command?
No, not of itself. So long as we have an unambiguous grammar, then the
parser has no trouble. The grammar tells the parser when a
[xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first
letter of a name. To avoid the constraint that a name could not begin
with one of those letters, I would need to employ a stateful lexer, but
that is easy. The parser then fine tunes the lexer's eyesight, token by
token, as it walks along a line of gcode.
Incidentally, spaces in the input are usually eliminated by one line in
the lexer. The parser never sees spaces, so that one line is all the
space handling there is. (Well, that's how I do it, 'cos it's easier.)
The parser is automatically generated from the BNF grammar and its
embedded output actions (coded in C), so it's only necessary to write
the lexer, the grammar, and the leaf actions. The fun begins if the
grammar is ambiguous, resulting in conflicts. Debugging that adds to the
entertainment value.
But I haven't seen a troublesome gcode example yet. :-)
Erik
Remember that just because a computer can understand a grammar does not
mean that a person can. (Consider the C++ grammar.)
Also, I'd like to add a requirement to have variables with string
values (together with some added functions). That's so someone could
write code that does engraving.
Someone commented about the comment syntax -- using parens to delimit
comments -- in a somewhat deprecating manner. I'd suggest that it is
certainly no worse than the /* */ comments in my favorite language. I do
find it useful to be able to embed a comment in the middle of a line;
not just at the end.
Ken
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 15:20 schrieb andy pugh: g1YfooZ100 And here is the question? What did I mean? I was actually meaning feed at the rate defined by the parameter oo, but how is the parser to know that is what I wanted rather than there being a missing S (for example) in G1 Sfoo Z100 (not a totally random case, my machine has a very reluctant S key, I very often type M31000 in MDI) that is what I mean with 'either retain bracketing letters' or go the 'make whitespace significant' route g1YfooZ100 is ambiguous as to the end of the feed variable g1Y Foo Z100 would mean G1Y f#oo Z100 under the 'make whitespace significant' rule I think we should keep the # for all variables. It is what humans reading G-code expect to see. Fine - that's a decision item. - Michael. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 1/29/2012 9:20 AM, andy pugh wrote: On 29 January 2012 14:02, Erik Christiansendva...@internode.on.net wrote: oo = 1 OK, O Codes. They'll all go in a declutter, replaced by their naked keywords, No, that is creating a second named parameter in order to be more ambiguous later: g1fooZ100 Is there an axis identifier missing here? If it's supposed to be: g1YfooZ100 And here is the question? What did I mean? I was actually meaning feed at the rate defined by the parameter oo, but how is the parser to know that is what I wanted rather than there being a missing S (for example) in G1 Sfoo Z100 (not a totally random case, my machine has a very reluctant S key, I very often type M31000 in MDI) I think we should keep the # for all variables. It is what humans reading G-code expect to see. A linked point is that we seem to be discussing mainly human-generated G-code, whereas a large proportion of G-code executed by EMC2 machines is machine-generated. As well as discussing machine-parsing we also might need to consider machine-generation. I like the point that you bring out. Not only does this have to be ambiguous, it has to be robust in the case of common errors. One could imagine a language where every utterance was grammatically legal. That would mean that you could never write an illegal program. I don't think I would like that. Redundancy in language can be very useful. Ken -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 1/29/2012 10:55 AM, Erik Christiansen wrote: On 29.01.12 14:20, andy pugh wrote: On 29 January 2012 14:02, Erik Christiansendva...@internode.on.net wrote: oo = 1 OK, O Codes. They'll all go in a declutter, replaced by their naked keywords, No, that is creating a second named parameter in order to be more ambiguous later: Yes, the variable assignment is unmistakable, but the sneaky intent wasn't. :-) g1fooZ100 Is there an axis identifier missing here? If it's supposed to be: g1YfooZ100 And here is the question? What did I mean? I was actually meaning feed at the rate defined by the parameter oo, but how is the parser to know that is what I wanted rather than there being a missing S (for example) in G1 Sfoo Z100 (not a totally random case, my machine has a very reluctant S key, I very often type M31000 in MDI) As it should, a parser slavishly applies its grammar to the input which we _do_ provide, not what we didn't. In the BNF grammar, we need to specify that a feedrate_clause may appear after a g1, as an alternative to an axis_motion. That causes the 'f' to be recognised as a keyword, which in turn causes oo to be detected as a variable name. It is equally straightforward to allow and optional 'S' clause to this part of the grammar. What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part of the grammar tree for G1 then gets the handling of the common clauses for free, and we only need to tack on the stuff that G0 doesn't have. Not only does this reduce coding and testing effort, but it ensures consistency across commands, where it should exist. i.e. Anything which is even moderately common in gcode should be specified only once in the grammar. I'd rather NOT have the details of what is mandatory and what is optional for various g-codes be part of the grammar. Right now, it is pretty straightforward to add a new g-code. I don't think we should require modifying the grammar to be necessary to add (or change) a g-code. To allow removal of the square brackets currently containing an axis_motion clause, we need alternative clause termination. Upthread I suggested ';', as is used between elements of a for loop in most languages. Your line then becomes: g1foo;Z100 Or if we are in industry, and someone else might need to read it: g1 foo; z100 # Either GFZ or gfz is easier on humans. Now a LALR(1) parser can deal not only with that, but also with a variable named foo or Foo, so long as we configure a stateful lexer, which is able to look for only a keyword immediately after the G1, and resume seeing a variable name after the f keyword is consumed. I think we should keep the # for all variables. It is what humans reading G-code expect to see. That is admirably achieved by changing nothing, fully maintaining historical authenticity. I respect such a preference. The purpose of the proposed changes is expressly to eliminate such useless visual clutter. My expectation is that if we proceed to implementation, then users will choose to use one syntax or the other. The two need to be equivalent in function, but the old clutter need not adhere to the more readable alternative syntax. I find it interesting that you consider removing (what you refer to as) the clutter makes the code more readable. I consider having the clutter more readable. Removing the clutter makes it easier to write (there are fewer keystrokes). A typography analogy might be useful. My understanding is that fonts with serifs are easier to read than san-serif fonts. I'm sure that it has been suggested that serifs be removed to eliminate clutter. Redundundancy is sometimes useful. :-) A linked point is that we seem to be discussing mainly human-generated G-code, whereas a large proportion of G-code executed by EMC2 machines is machine-generated. As well as discussing machine-parsing we also might need to consider machine-generation. Yes, it needs to be considered, but I don't quite see an impact. Compatible machine-generated gcode is currently in the historical format, and it is adequately handled by the existing parser. The purpose of the decluttered parser is to allow human-generated gcode to become human readable. If, in time, some machine-generated gcode should transition to the more readable format, then that's OK too. One thing with a lex/bison based interpreter is that the implementation itself contains a BNF specification of the legal grammar. Whether input is legit or not is easily looked up in one place. And if error messages are not sufficiently explicit, then it's fairly easy to see if steps can easily be taken to fix it. Erik Regards, Ken -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just
Re: [Emc-users] question on gcode parsing
Am 29.01.2012 um 16:55 schrieb Erik Christiansen: What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part By 'grouping common clauses' do you mean testing for required or permitted 'words' pertaining to a particular code? - Michael -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. If one insists on improving g-code, I would start over with a language using keywords rather than letters. The need to to extract the most context from single symbols is a throwback from when teletypes ran at 300 Baud. Just my opinion based on very limited experience. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29 January 2012 18:43, Kirk Wallace kwall...@wallacecompany.com wrote: Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. Which FOSS, Linux, CAM system would you suggest? -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On Jan 29, 2012 12:44 PM, Kirk Wallace kwall...@wallacecompany.com wrote: Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. I would agree if there were an open source CAM that was good. I tried pycam but it is lacking. Given that I can't afford an expensive package I find it pretty easy to just write gcode. Especially for simple things. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On Sun, Jan 29, 2012 at 6:43 PM, Kirk Wallace kwall...@wallacecompany.com wrote: Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. If one insists on improving g-code, I would start over with a language using keywords rather than letters. The need to to extract the most context from single symbols is a throwback from when teletypes ran at 300 Baud. There is no open source cam for 5 axis I know of no other way than hand coding for my machine I NEED better syntax not less syntax Dave Caroline -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On 1/29/2012 8:10 AM, andy pugh wrote: On 29 January 2012 13:23, John Thorntonbjt...@gmail.com wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. FF2 = Acceleration Feed Forward Gain or Friction Feed Forward Gain. I would like to update the docs with some descriptive text in addition to 0th order feed forward gain as that and the other descriptions only seem to make sense to a mathematics professor. There is a reason that mathematicians talk the way they do, it is to be unambiguous in the general case. I think the best solution would be for all LinuxCNC users to take a maths degree, but that might be impractical. The problem with your explanation is that it assumes a position-command / position-feedback system and there are other possibilities that are not that unusual. (closed-loop spindle control is one) The problem explaining it is I don't know enough about it to even pretend to know... FF0: This term adds a value to the PID output directly proportional to the input. It is useful for any system where a steady-state output requires a non-zero input. The most likely case is a closed-loop spindle speed control, where 10V might give 1000rpm, and a FF0 gain of 0.01 would mean that the PID terms were only required as correction, not the basic output value. This term would not normally be used with a position-feedback system, except possibly to compensate for the effects of a spring counterbalance. FF1: This term adds a value to the PID output proportional to the rate of change of the input. So, if the input is position, FF1 is proportional to velocity demand. If the input is rpm then FF1 is proportional to angular acceleration/torque demand. This term can often be very useful to increase the responsiveness of a position-feedback system with velocity-control servos. FF2: This adds a value to the PID output which is proportional to the rate of change of the rate of change of the input (mathematically, the second order differential with respect to time). In a typical position-control loop this would correspond to the acceleration. (in a velocity-control system it would correspond to the jerk). In the position-control case this would be useful to compensate for the mass of a heavy table, for example. Thanks for the explanations for the above... If I add FF3 to the manual then someone has to make it work right? FF3: This value does not exist and has been inserted to see who is still paying attention. A negative FF3 term could be used to add a degree of jerk control to a position-feedback system. John -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On 29 January 2012 17:31, gene heskett ghesk...@wdtv.com wrote: What if the spring is either too much or too little, this seems to invite the need for a non-symmetrical FF0 function. You could account for the constant offset with the PID bias term. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On Sun, 2012-01-29 at 19:08 +, andy pugh wrote: On 29 January 2012 18:43, Kirk Wallace kwall...@wallacecompany.com wrote: Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. Which FOSS, Linux, CAM system would you suggest? What little code I've created so far is done by hand, Qcad/dxf2gcode or Synergy, but it's not LinuxCNC's fault that there aren't more choices. In my opinion, g-code should be a script for telling the machine how to operate, not a utility for creating or bypassing code. I just want to float the Spartan ideal to try to help keep the interpreter and LinuxCNC from getting bloated. Over the years I've seen good enough software become bloated to the point of needing other programs to make them usable again. I like jumpers instead of Plug-N-Play. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
John Thornton wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. You have these reversed. Jon -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
gene heskett wrote: On Sunday, January 29, 2012 12:00:01 PM andy pugh did opine: On 29 January 2012 13:23, John Thornton bjt...@gmail.com wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. FF2 = Acceleration Feed Forward Gain or Friction Feed Forward Gain. I would like to update the docs with some descriptive text in addition to 0th order feed forward gain as that and the other descriptions only seem to make sense to a mathematics professor. Bingo John. To get more specific, FF0 is an adjustment based on the commanded parameter of the PID. FF1 is based on the first derivative of the commanded parameter, FF2 is based on the second derivative. In a positioning servo, then FF0 is proportional to the position, FF1 is proportional to velocity and FF2 is proportional to acceleration. In a velocity servo, perhaps a closed-loop spindle speed control, FF0 would be proportional to velocity, FF1 would be proportional to acceleration, and FF2 would be proportional to change in acceleration, sometimes referred to as jerk. Jon -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On Sunday, January 29, 2012 06:37:43 PM andy pugh did opine: On 29 January 2012 17:31, gene heskett ghesk...@wdtv.com wrote: What if the spring is either too much or too little, this seems to invite the need for a non-symmetrical FF0 function. You could account for the constant offset with the PID bias term. I realized that Andy, at about the same time I was pulling on my coat to head for the shop. With strong enough steppers its moot in any event. But that doesn't negate the fact that with the load offset, you have more rapids available going one way than the other. So you wind up tweaking for the slowest direction. Often by reducing accel to what it can handle, then raising vel a bit. 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 If we see the light at the end of the tunnel, it's the light of an oncoming train. -- Robert Lowell -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] File naming conventions in an oname call?
Greets all; I've written a testz.ngc that is about 6 or 7 lines of code, whose main reason for existance is to test my autoz function when called as a file. I get as far when I try to load it, because it cannot open the 'lathe- encoder/autoz.ngc' file. Then I try to load it directly, and linuxcnc acts as if the () is no longer a legit comment surrounding) as it is then squawking about line two in the loaded file, which is a comment. If I put a blank line before and after the comment, it then makes the same fus about line 3. Is there, someplace in the wiki, a good, as in you must do this this way tutorial in the wiki? 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 No bird soars too high if he soars with his own wings. -- William Blake -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
So you agree with Andys description? I have a hard time keeping them straight... John On 1/29/2012 3:46 PM, Jon Elson wrote: John Thornton wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. You have these reversed. Jon -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 13:12, Kenneth Lerman wrote: On 1/29/2012 9:02 AM, Erik Christiansen wrote: But I haven't seen a troublesome gcode example yet. :-) Remember that just because a computer can understand a grammar does not mean that a person can. (Consider the C++ grammar.) Point taken. (And perl is C++ cubed, with even authors of perl books admitting in print that it is execrable. See sig.) Andy's example with foo and oo is also a prime example. I had no idea what the example was supposed to mean, but a grammar of your choice would parse it according to the specified rules even if neither of us correctly anticipated the outcome. Gcode should be explicit, and therefore readily understood. Obfuscated examples, such as Andy's are demonstrably not human readable, but a parser should not be confused by them, even if we are. My point is that I believe that all legal gcode is eminently parsable, and I have yet to see any supposedly pathological gcode example which is very difficult to parse. Also, I'd like to add a requirement to have variables with string values (together with some added functions). That's so someone could write code that does engraving. That sounds like fun, but I'm not sure how you'd get from ascii to the G1 moves to produce any font at all. Isn't ascii to gcode a cam function? The interpreter doesn't generate gcode. is more or less our primary maxim, AIUI. Someone commented about the comment syntax -- using parens to delimit comments -- in a somewhat deprecating manner. I'd suggest that it is certainly no worse than the /* */ comments in my favorite language. I do find it useful to be able to embed a comment in the middle of a line; not just at the end. Ah, yes, shouldn't exclude embedded comments I suppose. How about [This is a comment], or This comment style frees up () too. It's the conflict with the greater utility of () in functions and expressions, which complicates a parser. Replacing the square brackets with the more conventional parentheses reduces gcode,s weirdness, making it human readable with less mind-twisting when moving from all the other scripting languages an integrator is exposed to. The embryonic human_readable_syntax to gcode translator which I started in july last year, using lex/bison, does use the # as comment delimiter, but I could easily add This comment style as well, allowing use of either. It's not an attempt at an alternative interpreter, but would simply be run as a filter. It would need quite some work before being ready for prime time, since the current input syntax is made highly readable by using English words which state what is to happen, rather than cryptic gcode non-mnemonic cryptic numbers. Gcode veterans would hate it with a vengeance. For any chance of broader appeal, I'd have to make it also accept conventional gcode with only decluttering added, I see. I'll have a look at what it'll take to do that. (Just a suite of alternative grammar clauses, one up from the leaf level, I expect.) Erik -- Yes, sometimes Perl looks like line-noise to the uninitiated, but to the seasoned Perl programmer, it looks like checksummed line-noise with a mission in life. - The Llama Book -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On Sun, 29 Jan 2012 10:43:18 -0800, you wrote: Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. If one insists on improving g-code, I would start over with a language using keywords rather than letters. The need to to extract the most context from single symbols is a throwback from when teletypes ran at 300 Baud. Just my opinion based on very limited experience. Your limited experience is good, IMO. My experience comes from working in the commercial world for 40 yrs. The simpler the code, the better. It doesn't matter these days how long the code is, but it has to be simple. The guys running CNC machines in factories are not rocket scientists. They don't have to be. Subroutines are a big NO. They are rarely understandable to anyone else other than the geek who wrote them, and they are impossible to recover from if anything goes wrong. Canned cycles aren't much better! None of the modern commercial code I see contains either. Fanuc controls, in the main, can't feed hold in a canned cycle or subroutine and recover. They can with plain Gcode. One of the companies I do a bit for make hydraulic manifolds. They start with a steel forging. It has over 40 holes drilled and reamed in it and ALL are threaded for plugs or hose connectors. The rough forgings are over £1000 each. There are four of these in each machine on a tombstone mount, one of the risky actions is drilling through end to end, (600mm) then reaming with a scissor action floating reamer. The whole process is done with G1 and G0 moves. Not a peck or deep hole cycle in sight. Simple reason is the ops can hear if it goes wrong, stop the machine, jog out, rewind a few lines, change tools and carry on. Some may think it's clever writing fancy subs and others may marvel at how clever you are reducing 100 to 4 lines of code. Those who actually work in the real Engineering world often laugh/curse and think - what a Steve Blackmore -- -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 11:14, Kent A. Reed wrote: On 1/29/2012 10:55 AM, Erik Christiansen wrote: ... What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part of the grammar tree for G1 then gets the handling of the common clauses for free, and we only need to tack on the stuff that G0 doesn't have. Not only does this reduce coding and testing effort, but it ensures consistency across commands, where it should exist. i.e. Anything which is even moderately common in gcode should be specified only once in the grammar. Whatever qualms I may have about the difficulty of interjecting meaningful error messages into an interpreter based on lex'ing and parsing is overcome by the benefits you point out here. It's good to talk this stuff over then, because we then all have a better understanding of where we can get to from here, with manageable effort and useful improvement. (I.e. The perfect is the enemy of the good.) I just don't know how to generate enthusiasm for a decluttered amateur-readable syntax which helps us dilettantes up the gcode learning curve. (As a 30-year programming veteran, I can't hack going back to the days when we didn't even have an assembler to convert human-readable mnemonics to the meaningless machine code. There's no difference between 0x01 and G01 in terms of human-readability.) Error messages can be made meaningful to an experienced user of a tool. They cannot remove the learning curve which a newcomer to the discipline must climb, I find. I've seen some unreasonable expectations expressed by new users, when the primary problem was that they did not understand that they need to understand the language they're using, and make some inferences from the hints provided by a translation tool which is not a tutor. (Well, especially not when it's in beta.) When developing language translators, I usually have implemented basic translation, followed by low-hanging (i.e. easy to implement) error messages, then trickier translation, and finally less obvious error messages. The latter may continue to be added throughout the life of the product. Erik -- Note that this is Perl code and I'm well-aware of the general unparseable nature of Perl. A most works solution would be fine. - Ovid, on Vim Users ML. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On Sun, 29 Jan 2012 19:08:23 -0600 John Thornton bjt...@gmail.com wrote: So you agree with Andys description? I have a hard time keeping them straight... John On 1/29/2012 3:46 PM, Jon Elson wrote: John Thornton wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. You have these reversed. I think I have this right. ;-) 0 is a constant 1 is first derivative and therefore velocity 2 is 2nd derivative and accel 3 is 3rd jerk Dave Jon -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo tuning - wtf?
On Sun, 29 Jan 2012 19:08:23 -0600 John Thornton bjt...@gmail.com wrote: So you agree with Andys description? I have a hard time keeping them straight... John On 1/29/2012 3:46 PM, Jon Elson wrote: John Thornton wrote: So, looking at one of the links for servo tuning is our FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. You have these reversed. I think I have this right. ;-) 0 is a constant offset 1 is first derivative and therefore velocity 2 is 2nd derivative and accel 3 is 3rd jerk Dave Jon -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 13:30, Kenneth Lerman wrote: On 1/29/2012 10:55 AM, Erik Christiansen wrote: What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part of the grammar tree for G1 then gets the handling of the common clauses for free, and we only need to tack on the stuff that G0 doesn't have. Not only does this reduce coding and testing effort, but it ensures consistency across commands, where it should exist. i.e. Anything which is even moderately common in gcode should be specified only once in the grammar. I'd rather NOT have the details of what is mandatory and what is optional for various g-codes be part of the grammar. Right now, it is pretty straightforward to add a new g-code. I don't think we should require modifying the grammar to be necessary to add (or change) a g-code. Oh Deeearr, that's a bit of a problem. You see, having a BNF grammar specification to eliminate any confusion over what is legal syntax, is a major purpose of the improvement. (I believe it is broadly considered a defect in the current parser.) It is worth understanding that it is not possible to intelligently generate error messages if the grammar fails to specify what is mandatory and what is optional for various g-codes. Clearly, that is the explicit _purpose_ of the grammar. Having that BNF grammar specification embedded in the new parser means that it abides by the language specification. A coder cannot diddle the parsing significantly in a corner of the code. Changing the BNF specification, and filling in the blanks in the leaf code, _is_ adding or changing the legal gcode. Nothing else needs to be done, other than update the documentation, since the parser is auto-generated from the few keystrokes we have added. The process is disciplined, highly structured, and minimises hand coding to the nth degree. There's not a lot of code to wade through. (Some people will hate it. ;-) ... The purpose of the proposed changes is expressly to eliminate such useless visual clutter. My expectation is that if we proceed to implementation, then users will choose to use one syntax or the other. The two need to be equivalent in function, but the old clutter need not adhere to the more readable alternative syntax. I find it interesting that you consider removing (what you refer to as) the clutter makes the code more readable. I consider having the clutter more readable. Removing the clutter makes it easier to write (there are fewer keystrokes). The change nothing preference is admirably handled by the existing parser. The alternative syntax can be expected to be alternative. ;-) My interest in this was reawakened by others expressing distaste at the obfuscating clutter in the current gcode syntax, yet again. When there's enough interest, we'll do something about it. A typography analogy might be useful. My understanding is that fonts with serifs are easier to read than san-serif fonts. I'm sure that it has been suggested that serifs be removed to eliminate clutter. I prefer to avoid that clutter too, and don't use serif fonts. If syntax highlighting is used to impose different colours on different parts of some code within a line, then I have trouble reading it. Redundundancy is sometimes useful. :-) Hmmm, I don't think it exists in mathematical or programming expressions, and I abhor it in gcode. To my mind, it only introduces potential conflict between the parts of the unnecessary duplication. However, what we have in gcode is not redundancy, but clutter lacking in any information content of any kind. The variable and function names, as well as keywords, contain _all_ of the information in their alphanum names. The surrounding crutches for low capability parsers give nothing to the user. Erik -- Am I correct that perl5-porters is the proper forum for submitting my ideas? I think you didn't get a reply because you used the terms correct and proper, neither of which has much meaning in Perl culture. :-) -Larry Wall -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 01/29/2012 10:40 PM, Erik Christiansen wrote: On 29.01.12 13:30, Kenneth Lerman wrote: On 1/29/2012 10:55 AM, Erik Christiansen wrote: What further simplifies the task is that we can, for example, group the clauses which are common to G0, G1, etc., and give them a name. The part of the grammar tree for G1 then gets the handling of the common clauses for free, and we only need to tack on the stuff that G0 doesn't have. Not only does this reduce coding and testing effort, but it ensures consistency across commands, where it should exist. i.e. Anything which is even moderately common in gcode should be specified only once in the grammar. I'd rather NOT have the details of what is mandatory and what is optional for various g-codes be part of the grammar. Right now, it is pretty straightforward to add a new g-code. I don't think we should require modifying the grammar to be necessary to add (or change) a g-code. Oh Deeearr, that's a bit of a problem. You see, having a BNF grammar specification to eliminate any confusion over what is legal syntax, is a major purpose of the improvement. (I believe it is broadly considered a defect in the current parser.) I would put the details of what letter codes are valid for which gcodes in the semantics of the implementation of the particular code (the way it is now). Are you suggesting that a three axis machine where there is no A axis should have a different grammar than a four axis machine that does have an A axis. I don't believe it would be reasonable to specify the total grammar the way you suggest using BNF. How would you specify that G1 can have X Y Z values in any order, but only one of each? And that in some cases the X Y or Z values are optional if they use the same value as a previous line? Remember, of course, that when we have subroutines, a previous line means a previously executed line. Ken It is worth understanding that it is not possible to intelligently generate error messages if the grammar fails to specify what is mandatory and what is optional for various g-codes. Clearly, that is the explicit _purpose_ of the grammar. Having that BNF grammar specification embedded in the new parser means that it abides by the language specification. A coder cannot diddle the parsing significantly in a corner of the code. Changing the BNF specification, and filling in the blanks in the leaf code, _is_ adding or changing the legal gcode. Nothing else needs to be done, other than update the documentation, since the parser is auto-generated from the few keystrokes we have added. The process is disciplined, highly structured, and minimises hand coding to the nth degree. There's not a lot of code to wade through. (Some people will hate it. ;-) ... The purpose of the proposed changes is expressly to eliminate such useless visual clutter. My expectation is that if we proceed to implementation, then users will choose to use one syntax or the other. The two need to be equivalent in function, but the old clutter need not adhere to the more readable alternative syntax. I find it interesting that you consider removing (what you refer to as) the clutter makes the code more readable. I consider having the clutter more readable. Removing the clutter makes it easier to write (there are fewer keystrokes). The change nothing preference is admirably handled by the existing parser. The alternative syntax can be expected to be alternative. ;-) My interest in this was reawakened by others expressing distaste at the obfuscating clutter in the current gcode syntax, yet again. When there's enough interest, we'll do something about it. A typography analogy might be useful. My understanding is that fonts with serifs are easier to read than san-serif fonts. I'm sure that it has been suggested that serifs be removed to eliminate clutter. I prefer to avoid that clutter too, and don't use serif fonts. If syntax highlighting is used to impose different colours on different parts of some code within a line, then I have trouble reading it. Redundundancy is sometimes useful. :-) Hmmm, I don't think it exists in mathematical or programming expressions, and I abhor it in gcode. To my mind, it only introduces potential conflict between the parts of the unnecessary duplication. However, what we have in gcode is not redundancy, but clutter lacking in any information content of any kind. The variable and function names, as well as keywords, contain _all_ of the information in their alphanum names. The surrounding crutches for low capability parsers give nothing to the user. Erik -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases
Re: [Emc-users] Servo tuning - wtf?
FF0 = Velocity Feed Forward Gain. FF1 = Position Feed Forward Gain. FF2 = Acceleration Feed Forward Gain or Friction Feed Forward Gain. As Jon and others wrote, FF0,1,2 are related to consecutive time derivatives of the controlled parameter: if the controlled parameter is the position (which is the most common case), FF0/1/2 are derived from commanded position, velocity, and acceleration. In a velocity-controlled loop, it's velocity, acceleration and 'jerk', or rate of change of acceleration. I would like to update the docs with some descriptive text in addition to 0th order feed forward gain as that and the other descriptions only seem to make sense to a mathematics professor. The reason why it's useful to get into the math part is that one doesn't have to remember them by rote. There's a symmetry and organization that appears in the mathematical description of those systems; once understood, it helps to keep a picture in one's head how those things interact. The three PID controller parameters (P, I and D) are similar and analogous to the three feed-forward parameters (FF0, FF1 and FF2). In each sequence, the parameters act on increasing time derivatives of some system parameter. The difference is that the PID parameters act upon the error term (difference between the commanded position and the actual position) whereas the feed-forward terms act directly on the input parameters, regardless of the actual output position. Knowing that, it's possible to get a glimpse of which parameters are related to each other---for instance, the FF0 term is related to the I term in an interesting way, which helped me to understand better the principle of operation of those systems. I have only a basic understanding of control theory, but I hope the following explanation is accurate and might help others to get a better intuitive grasp of how those things work. The P term is of course the most important: it reflects the direct error or difference between the commanded and actual output, so if we had a servo fairy that automatically and perfectly runs the system that we're trying our PID controller on, P would be always zero (and of course I, D also would be zero). If the fairy got tired and started making mistakes, the P term would kick in and push the system towards zeroing that error again. As everyone here knows, the D term represents drag or braking forces, and helps to dampen the system, thus preventing the oscillations. The 'I' term is interesting---by integrating the error over time, it gradually kicks in when the P term alone is unable to keep the system at the commanded position. It is common, however, that such extra force is known ahead of time, and instead of acquiring it gradually over time, like the I term does, we could just immediately add it---as provided by the FF0 term. If you can see it this way, the usual tuning procedure (P, then D, then I, then FF) starts making sense. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 19:31, Michael Haberler wrote:
Am 29.01.2012 um 16:55 schrieb Erik Christiansen:
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
By 'grouping common clauses' do you mean testing for required or
permitted 'words' pertaining to a particular code?
Not writing any testing code, no. It's just extracting and re-using some
BNF grammar clauses. You'll get that straight off, I'm sure, but for
casual readers, an example might help. Back in July, I only got as far
as handling a bunch of modal commands, and don't have the G0, G1 example
implemented at this instant, so hopefully some of what is already there
will serve to illustrate the principle of hiving off a group of leaf
clauses into a grammar clause which can be used repeatedly. (Even if the
example clause isn't one which we would re-use, it's probably clear
enough how easy it is to do the same with one we would.)
The following BNF defines a parser-internal modal_directive, for which
it will accept six alternative input clauses:
modal_directive: compensation_directive
| motion_directive
| plane_directive
| spindle_directive
| tool_directive
| workspace_directive
;
None of the six are raw input, so they all need to be defined by
lower level grammar clauses. Let's take plane_directive:
plane_directive: PLANE XY{ plane = XY ; emit( G17) ; }
| PLANE ZX{ plane = ZX ; emit( G18) ; }
| PLANE YZ{ plane = YZ ; emit( G19) ; }
| PLANE UV{ plane = UV ; emit( G17.1) ; }
| PLANE WU{ plane = WU ; emit( G18.1) ; }
| PLANE VW{ plane = VW ; emit( G19.1) ; }
;
Here, PLANE and the following word are both tokens passed by the lexer
as it recognises input keywords. The C code in {} is the leaf action
needed to complete processing.¹
I'll try to put some time aside to implement G0 and G1 translation, but
if we accept that plane_directive: can be mimicked by e.g.
common_options:, then there could be a common set for G0 and G1. The
parameter clauses for G0 and G1 could then look something like:
g0_options: common_options
;
g1_options: common_options
| feedrate_option
| another_option_not_for_g0
| yet_another_option_not_for_g0
;
In practice, common_options may be just axes words.
Any input on what G1 can take, and G0 can't, is gratefully accepted.
(I'm not finding http://www.linuxcnc.org/docs/html/gcode_main.html
particularly definitive. ;)
I'll take a look at the grammars mentioned upthread, to see if they
contain such information. If we have it, I don't know where.
Another way to proceed is for anyone interested in a decluttered syntax
to pass on what they know about the legal options for one command. After
that's implemented, we'll soon find out if any subsequent user
disagrees.
¹ Being only a translator from a human-readable input form to gcode, the
actions are only translation and remembering the active modality, not
least for generating meaningful error messages, such as in this other
clause:
compensation_modality: RADIUS ON LEFT { if (plane == YZ)
error(Illegal plane selected.)
emit( G41)
}
| RADIUS ON RIGHT { if (plane == YZ)
error(Illegal plane selected.)
emit( G42)
}
| RADIUS OFF { emit( G40) ; }
;
Please don't panic about the input syntax. That is easily made more
cryptic and similar to gcode. ;-)
Erik
--
[Perl is] more like a tank than a mine field. It may be ugly, but it
shoots straight and gets you where you're going, if you don't mind a few
squashed daisies.- Larry Wall
But how much more?
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 29.01.12 23:05, Kenneth Lerman wrote: Are you suggesting that a three axis machine where there is no A axis should have a different grammar than a four axis machine that does have an A axis. No, there is no such constraint in the current parser, and there is no reason to imagine that there might be in the new. A language like C does not constrain whether the user can count by twos or threes, and nor is there any connection between a gcode grammar and the peculiarities of a specific machine. One grammar handles them all. I think most users understand that the machine specifics are entirely dealt with by run-time configuration and the gcode input. It is worth understanding that the current parser _does_ have a fixed grammar, just like the proposed alternative. The significant difference is that in the current parser, it is not revealed in a concise human-readable form. As far as grammars go, the only structural change is transition from an amorphous hand-coded parser to a structured auto-generated parser, using a formal BNF grammar specification, instead of an undocumented one. How would you specify that G1 can have X Y Z values in any order, but only one of each? And that in some cases the X Y or Z values are optional if they use the same value as a previous line? That is trivial, and is achieved without writing any program code to do it. Multiple alternatives, independent of order, and optional parameters, are the most basic meat of writing a BNF grammar. A prior post today shows how a BNF grammar allows alternatives, in any order. Here is an example of how to allow an optional parameter: tool_options: /* Empty */ | ',' spindle_directive As with the rest of the grammar, the code to implement our wishes is auto-generated. We just have to get the grammar right. ;-) If you read the early chapters in O'Reilly's Lex Yacc book, you'll see how completely straightforward these simple cases are. :-) Remember, of course, that when we have subroutines, a previous line means a previously executed line. An interpreter must retain the state of any modal directive. That's rather simple. A translator benefits from doing the same, since it can then generate better error messages. The grammar example posted earlier today includes an example of this. It's also pretty simple. What is being missed here is that the present parser does all that you fear above, just without the maintainability and documentation benefits conferred by a higher level implementation, using powerful tools. Erik -- In general, they do what you want, unless you want consistency. - Larry Wall in the perl man page -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
On 30.01.12 02:33, Steve Blackmore wrote: On Sun, 29 Jan 2012 10:43:18 -0800, [Kirk] wrote: Regarding messing with the g-code interpreter, my vote is that g-code should describe axis position, feedrate; and spindle speed and direction, and little more. Everything else should be handled with CAM, including canned cycles and such. Less is more. +1 Despite being keen to work towards an optional human readable syntax, it should perform _identically_ to the current one. (All I have implemented so far is the beginnings of a filter, so it _can't_ do anything the current one doesn't.) If one insists on improving g-code, I would start over with a language using keywords rather than letters. The need to to extract the most context from single symbols is a throwback from when teletypes ran at 300 Baud. That is what I have begun to do. The syntax might need to be whacked with a 4lb hammer to displease the least number of users, but it has a number of goals: 1) Be mnemonic. i.e. give some farnarckling clue as to what the command does. (Even MOV is orders of magnitude superior to 0x01 or g01.) 2) Compress the learning curve, by making more explicit what the program does. In industry, the benefit is measurable in dollars. It accrues from 1). 3) Reduce the number of ruined $2000 workpieces. It is infinitely easier to mistype G0 instead of G01, than it is make Rapid out of Move. No amount of error checking will pick up a destructive misprogramming in legal syntax. Someone else posted that redundancy can be useful. When it not only gives the commands explicit meaning, but also helps catch typos, then the extra keystrokes can be worth a great deal. Just my opinion based on very limited experience. Your limited experience is good, IMO. My experience comes from working in the commercial world for 40 yrs. The simpler the code, the better. It doesn't matter these days how long the code is, but it has to be simple. The guys running CNC machines in factories are not rocket scientists. They don't have to be. In a production environment I imagine that there is not always time to cross-check a program edit with another employee. Does it ever happen that G0 instead of G01 (or something even more exciting) goes in, due to a momentary lapse in mentally converting what-should-happen to those cryptic codes? Subroutines are a big NO. They are rarely understandable to anyone else other than the geek who wrote them, and they are impossible to recover from if anything goes wrong. Canned cycles aren't much better! If we all had CAM, I don't think we'd labour over hand written subroutines either. It's to cope with work which would otherwise need CAM, that subroutines are a godsend to the amateur user. Erik -- Programs must be written for people to read, and only incidentally for machines to execute.- Abelson and Sussman -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
