Re: [Emc-users] Archived discussion of IRC link - broken
On 1 February 2012 05:24, BRIAN GLACKIN glackin.br...@gmail.com wrote: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/ and results in Not Found I don't think that the IRC archive has worked for quite a long time. There are a couple of private chatbots archiving the IRC, but I am not sure if it is appropriate for the LinuxCNC website to link to them. (That hands an implicit responsibility to the 'bot owners which might not be fair) Try: http://psha.org.ru/irc/ -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rs274ngc bison/flex parser
On 01.02.12 00:05, Michael Haberler wrote: ok, while this wonderful discussion was raging on, I built a working parser for the current linuxcnc dialect, as an experiment in feasability (this is NOT an end-user tool!) It would take all the fun out of it, if it were. :-) Before using the debug facilities to look at any of the 34 conflicts, I've so far just glanced at the lexer and parser. On the first scan of the latter, two things strike me, one significant, and one just a matter of clarity. (1) The grammar specifies expression and control flow constructs, but seems 100% devoid of any explicit gcode grammar. I've scrolled up and down twice now, but still can't see any rapids, moves, feedrates, or toolchanges. Nuffin! It seems that any gcode intelligence, which would enable it to parse the current linuxcnc dialect, is yet to be added. Confirming the growing suspicion, I found only this: block: word | block word ; word: letter optional_value | TGCODE | TMCODE and: optional_value: /* empty */ | expression ; That will pass any gcode with any parameters, without truly parsing any of it. My reading of that grammar is that it will, for example, blindly take G0 with all G76's parameters: G0 P- Z- I- J- R- K- Q- H- E- L- For a parser to _interpret_ the input gcode, it must recognise the difference between G0 and G76, and know which options are permitted for each. This one does not understand gcode at all, AFAICT. Grammars found lying about on the net are not often complete, and this one is no exception, apparently. If the gcode part of the grammar has fallen off on it's way here, I'd love to see it. (2) This, which I saw first, hardly seems significant now, but it's a helpful bit of pedantry, if you're fussy. It's poor grammar to hide the non-optional TO_ENDIF down in opt_elseifs, I suggest: . | TO_IF expression lines opt_elseifs . ; opt_elseifs: TO_ENDIF | TO_ELSE lines TO_ENDIF | TO_ELSIF lines opt_elseifs ; We could document more clearly with a tiny tweak: . | TO_IF expression lines opt_elseifs TO_ENDIF . ; opt_elseifs: /* Empty */ | TO_ELSE lines TO_ENDIF | TO_ELSIF lines opt_elseifs ; Now the grammar snippet for TO_IF makes sense by itself. (It now doesn't end in a subclause.) And opt_elseifs is now what it claims to be - optional. OK, where do we go from here? I'm not able to brew up any enthusiasm for beating 34 conflicts out of the skeleton of a parser which does not yet have gcode grammar. Sorry. Is there any chance of switching your stuff back to C, instead of C++? I've avoided the latter in my entire 30 developer career, and I wonder if we'd have more hackers if we just stick to C? You've prompted me to dig out the parser I started in July, and since there isn't any actual gcode in yours, I'm probably better off dusting it off, and playing with it. I'm sorry if that sounds a bit negative, but it's supposed to be just a neutral record of what I can see. (Maybe I need to go and eat.) Erik -- Use C++ to confuse your enemies; use C to produce stable code. - Wolfgang Denk, on u-boot-users. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ 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 31.01.12 21:45, dave wrote: To my uncluttered mind ... read blank ... is this a good way to set the state of a machine at any given line as a precursor to restart from line no? IIUC¹, running an interpreter through the code from line 1 to a given line, with all external actions suppressed, ought to set the state of a machine for that line, if the gcode takes no input, and does no probing. i.e. state is dependent only on the running of the gcode. (But that's just theory, aka a WAG. Experts may differ.) Erik ¹ I'm not sure what part of the 129 lines quoted constitute this. ;-) -- The difference between theory and practice is much smaller in theory than in practice... -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rs274ngc bison/flex parser
Erik, Am 01.02.2012 um 09:23 schrieb Erik Christiansen: On 01.02.12 00:05, Michael Haberler wrote: (1) The grammar specifies expression and control flow constructs, but seems 100% devoid of any explicit gcode grammar. I've scrolled up and down twice now, but still can't see any rapids, moves, feedrates, or toolchanges. Nuffin! Yes, and that is a feature. It seems that any gcode intelligence, which would enable it to parse the current linuxcnc dialect, is yet to be added. Interpreters and compilers sport post-parsing phases which work the AST, the symbol table etc to find the more interesting static semantic errors. That's where the 'gcode intelligence' needs to be. Your idea of an exclusively lexical and grammar approach to language analysis will be less than helpful, because: a) the idea of catching errors exclusively at the level of a context free grammar is not going beyond the trivial since many errors in G-code programs are not syntactical or indeed subject to static analysis in nature in the first place. To give a trivial example where your purely lexical/syntactic approach fails completely: Try to check the *compatibility* of several words and their parameters within a block. As this boils down to set operations and then some, for which a context free grammar provides exactly zero help, *any parser* for that matter is bound to stay, as you say, 'incomplete' by definition. Wrong tool, wrench broken. b) the language we have *is already runtime extensible* at the word level and your idea kills this property by downgrading it to a compile-time affair. Anybody wanting to add or redefine a code would have to change the *grammar definition*, which IMO isnt exactly what Joe Chipcutter will just love to do in the evening just because he needs to adjust a code's behaviour, or write a new one. That brings the number of people being able to change an existing, or define a new G- or M-code to epsilon, which is worse than we have now. Task and interpreter have enough of an configurability straightjacket as they stand and we need less, not more IMO. c) language preferences: I remember the original topic to be about an executable language description, reducing syntactic noise, and lint-type tools or prettyprinting for that matter. It was not about rewriting the current interpreter, but if that is your topic: the current interpreter is written in C++, so anybody fiddling with it better have/get some working knowledge of C++ or refrain (I did not have it either and did the former). Plus, language breaks are always excellent opportunities to create new support issues, and I dont see the upside, spare manpower or will to deal with it. You've prompted me to dig out the parser I started in July, and since there isn't any actual gcode in yours, I'm probably better off dusting it off, and playing with it. Sharing any better ideas or results would be helpful. To suggest a productive topic of discussion: lint-type tools, prettyprinters and interpreter extensions by (re) defining codes share some aspects: - they need to work the current parsing result, or better an abstract syntax tree and symbol/type information - they suggest a late binding approach for extensibility reasons This suggests to think about either redoing the whole thing in Python in the first place, or alternatively providing a Python binding for AST and symbol/type information if one were to stay with a C++ parser to remain within the current interpreter framework. That would provide a (potentially common) language base for the LinuxCNC interpreter, and any extra tools around it, which would be a big plus in terms of maintainence and consistency since we dont have the manpower and clue for a dozen of personal parsers, all a bit different. See for example the interesting pycparser project at http://code.google.com/p/pycparser. It uses clang/llvm : http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/ which is a bit on the heavy side for the task at hand, but I already used pycparser successfully to aid in a refactoring task, which was pretty close to prettyprinting and fairly simple to do. any opinions on that? - Michael Confirming the growing suspicion, I found only this: block: word | block word ; word: letter optional_value | TGCODE | TMCODE and: optional_value: /* empty */ | expression ; That will pass any gcode with any parameters, without truly parsing any of it. My reading of that grammar is that it will, for example, blindly take G0 with all G76's parameters: G0 P- Z- I- J- R- K- Q- H- E- L- For a parser to _interpret_ the input gcode, it must recognise the difference between G0 and G76, and know which options are permitted for each. This one does not understand gcode at all, AFAICT. Grammars found lying about on the net are not often complete, and this one is no
Re: [Emc-users] rs274ngc bison/flex parser {was: question on gcode parsing}
See for example the interesting pycparser project at http://code.google.com/p/pycparser. It uses clang/llvm : http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/ which is a bit on the heavy side for the task at hand, but I already used pycparser successfully to aid in a refactoring task, which was pretty close to prettyprinting and fairly simple to do. oh, I mixed something up here. pycparser uses ply, which is basically lex yacc for Python; the clang/llvm Python bindings are something else. actually a Python RS274ngc based on ply would be an interesting option, because plugging it into the current interpreter is relatively easy since many of the Python bindings needed are in place, and the infrastructure to extend them works fine and is in the current code base. one would need a bit of ballpark figure performance testing. Other than that, this looks viable. -m -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rs274ngc bison/flex parser
On 01.02.12 11:48, Michael Haberler wrote: Am 01.02.2012 um 09:23 schrieb Erik Christiansen: The grammar specifies expression and control flow constructs, but seems 100% devoid of any explicit gcode grammar. I've scrolled up and down twice now, but still can't see any rapids, moves, feedrates, or toolchanges. Nuffin! Yes, and that is a feature. At some point, LinuxCNC needs to interpret the gcode. The parser you've put up does not do that. Does it have any purpose, if it does not do that? A user need which has been expressed in this thread is for a documented gcode grammar. We'd like to know what is legal gcode, and what is not. If no grammar policing exists in the so-called parser, then either almost any input is accepted, or the real parser is elsewhere. ... b) the language we have *is already runtime extensible* at the word level According to the documentation here: http://www.linuxcnc.org/docview/devel/html/remap/structure.html#_introduction_extending_the_rs274ngc_interpreter_by_remapping_codes you're almost wholly correct in saying: and your idea kills this property by downgrading it to a compile-time affair. because having a documented grammar in the parser would only allow run-time _extending_the_rs274ngc_interpreter_by_remapping_codes. It would only permit remapping of standard gcodes by changing the grammar. But the need to remap gcodes half way through a swarf-making job, without allowing a compile, is probably a rare requirement. So perhaps the real point is that a highly flexible infrastructure for customising the interpreter exists, and no-one is proposing changing it. The main thread is about a filter to supply some things lacking in the current interpreter. One of those is a definition of the standard grammar - the one which allows us to exchange gcode programs, if we haven't pythoned a G0 into a G76. ... c) language preferences: I remember the original topic to be about an executable language description, reducing syntactic noise, and lint-type tools or prettyprinting for that matter. It was not about rewriting the current interpreter, but if that is your topic: No, if you look at my posts, you'll see repeated reference to a gcode filter. A couple of times I've had to answer posts which suggested merging the filter with the interpreter. I don't think that I have at any time adopted that suggestion from you or anyone else. ... You've prompted me to dig out the parser I started in July, and since there isn't any actual gcode in yours, I'm probably better off dusting it off, and playing with it. Sharing any better ideas or results would be helpful. This thread is intended to discover if there is anything to share, and if there is sufficient consensus on what is needed by the users. So far, the same desires as seen in previous years are: o A documented gcode grammar. o Some decluttering of the input, for readability. o More use of meaningful names, for readability. While some users may want to python their machines to use a personal private gcode dialect, used by no-one else, my interest lies at the other end of LinuxCNC and the use-case spectrum: Re-using the standard gcode grammar, but cleaning up its appearance. [snipped lotsa stuff on an apparently variable grammar.] any opinions on that? At this stage, I only have a few questions: Do we implement a default grammar, which we could document in BNF? Is it sufficiently static to warrant the effort of documenting it? Erik PS Thanks for provoking me into reading some of the doco on gcode extensions. It is flexible to a scary degree. -- Do not do unto others as you would they should do unto you. Their tastes may not be the same. - George Bernard Shaw -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rs274ngc bison/flex parser
On 1 February 2012 14:36, Erik Christiansen dva...@internode.on.net wrote: because having a documented grammar in the parser would only allow run-time _extending_the_rs274ngc_interpreter_by_remapping_codes. It would only permit remapping of standard gcodes by changing the grammar. But the need to remap gcodes half way through a swarf-making job, without allowing a compile, is probably a rare requirement. I think there might be some confusion here, between LinuxCNC compile time and run time and G-code compile time and run time Currently LinuxCNC G-code grammar can be changed at LinuxCNC run-time. I don't think there are any plans yet to re-define the G-code from inside G-code. but then you couild probably extend G-code to include commands for extending G-code. In principle a User M-code could do it. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
Another interesting related trawling find, with a some ideas for syntax evolution: A G code precompiler which parses a language based on C control structures, and generates rs274ngc gcode for LinuxCNC (including O-word constructs etc). It's by a fellow named Lawrence Yu, and its based on PLY/(Python lex yacc), and includes some basic yacc grammar for a G-code block syntax an interesting concept I hadnt thought of: he uses whitespace and whitespace/newline combination as language tokens returned by the scanner it makes a lot of sense to do that for rs274ngc and is a way to deal with Ken's 'drop whitespace squashing' idea in a backwards-compatible/selectable way and within a single parser its very well hidden from google: http://tsemsb.blogspot.com/search/label/GCODE http://tsemsb.blogspot.com/2010/04/cgcc-gcode-with-c-constructs.html The code isnt online in a readable fashion - one need to download and unpack the zip archive: http://sites.google.com/site/cgcccompiler/CGCC_v101.zip -m ps: unfortunately, a quick check of performance of pycparsers with a PLY based scanner/parser suggests it needs serious tuning, at least a faster scanner - a dozen or so example program needs near 0.5 sec of CPU time Am 23.01.2012 um 03:16 schrieb Scott Hasse: I understand where you are coming from. Word order is not important as -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Passing file names into a subroutine
this works: 1234.ngc --- O1234 sub (debug,in 1234.ngc, p1=#1 p2=#2 p3=#3) O1234 endsub m2 - in MDI/code do this: #1 = 1234 ; 'filename' - must be a number though O#1 call [47] [11] [15] - Michael Am 01.02.2012 um 16:01 schrieb BRIAN GLACKIN: Hi all. I tried to ask this question on IRC last eve and had trouble staying in channel. equipment - 25 X 49 X 4 gantry router for wookwork - all cutting is 2.5D I have a subroutine o100 that at present, I pass three values too Value 1 is the total depth of cut Value 2 is the incremental depth of cut Value 3 is the feed rate My past practice has been to cut and paste the gcode of a part into this subroutine. This has been fine for multiples of a single part. I recently started calling a gcode file directly from inside the subroutine which worked fine. What I would like avoid constantly cutting and pasting code (or filenames) into my parts program subroutine. I thought I could send via the subroutine a fourth value with the file name. The thought being that I can have a series of calls for different parts that I can cut out from the same sheet without having to mash up a massive gcode file. So I modified the O100 to add that fourth value. In the subroutine, I tried calling the file with O#4 call. ON loading the code into Linuxcnc, I get the error Near Line XXX urnary operation expected . Or something to that effect. I typed the exact error in IRC channel last eve if anyone saw that. Can I pass a filename through a subroutine call?? I did try renaming the file to a numer (1.ngc) and tried passing both 1 and 1.ngc. Brian -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rs274ngc bison/flex parser
Am 01.02.2012 um 13:36 schrieb Erik Christiansen: On 01.02.12 11:48, Michael Haberler wrote: Am 01.02.2012 um 09:23 schrieb Erik Christiansen: The grammar specifies expression and control flow constructs, but seems 100% devoid of any explicit gcode grammar. I've scrolled up and down twice now, but still can't see any rapids, moves, feedrates, or toolchanges. Nuffin! Yes, and that is a feature. At some point, LinuxCNC needs to interpret the gcode. The parser you've put up does not do that. Probably folks use the term 'parser' to mean different things, which might be part of the confusion. I use in the Dragonbook/Compilers 101 sense - a program which recognizes certain syntactic constructs and nothing else. For me the term 'parser' does NOT include static semantic checks, or executable semantics. The term 'interpreter' for me denotes executable semantics, which is different from 'parser', which is a context-free affair so to speak. Does it have any purpose, if it does not do that? A better definition of the language than we currently have it, executable or in the manual? For instance, we dont have anything like a railroad diagram or a current BNF. And it would be great to have that in particular for beginners. Also an executable version at least as point of reference, and as a vehicle for other software. Some examples: 1. Expression syntax my parser actually found an error, or rather my misunderstanding of the current language, in one of the files in emc2-dev/nc_files see line 30 of http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=nc_files/m6demo.ngc;h=85a3c0f7f031a7735e1660403f22beee90302b4e;hb=50d82f006b489a0e2795e60bd617759c902fdafd#l30 : Om6demo_spindle_off if [#tool_change_with_spindle_on] EQ 0 now if you read http://www.linuxcnc.org/docs/devel/html/gcode/o-code.html, the 'if' examples have bracketed expressions. So I though, gee, must be in the language. Well guess what, it isnt - the current interpreter (at least at that point) accepts the above line just fine, and I think it skips from the closing bracket to end-of-line - one would have to read the source code to determine acceptable language. Incidentally the interpretation of 'if [#tool_change_with_spindle_on]' and 'if [[#tool_change_with_spindle_on] EQ 0]' happen to be the same, but one can do better. 2. Is a (comment) whitespace? Whitespace is squashed, we hear. Comments are removed, so I assumed they are gone at the language execution level, and are de-facto whitespace. Really? let's see: $ rs274 -g ... READ = s100m3 17 N. SET_SPINDLE_SPEED(100.) 18 N. START_SPINDLE_CLOCKWISE() READ = s 100 m 3 19 N. SET_SPINDLE_SPEED(100.) 20 N. START_SPINDLE_CLOCKWISE() READ = s 100 (on) m 3 21 N. COMMENT(on) 22 N. SET_SPINDLE_SPEED(100.) 23 N. START_SPINDLE_CLOCKWISE() READ = s(hundred) m 3 bad number format (conversion failed) parsing '' s(hundred) m 3 That kind of 'language spec' can stand improvement.. so my parser doubles as a reverse-engineering tool;) 3. backplot for CAM programs HeeksCad sports some minimalistic understanding of the Gcode it generates, for backplotting the generated tool path. Guess what it uses: a regexp-based 'parser'. Sure. A user need which has been expressed in this thread is for a documented gcode grammar. We'd like to know what is legal gcode, and what is not. If no grammar policing exists in the so-called parser, then either almost any input is accepted, or the real parser is elsewhere. You'd be suprised on what incredible junk gcc accepts as 'legit grammar' once you amputate the backend ;) Currently I dont see a formal way to describe the interdependencies of several words on a block. You can do the optional parameter words in the language but you cant recogize the conflicts and multiple uses within a block that way. It would be nice to have. b) the language we have *is already runtime extensible* at the word level According to the documentation here: http://www.linuxcnc.org/docview/devel/html/remap/structure.html#_introduction_extending_the_rs274ngc_interpreter_by_remapping_codes you're almost wholly correct in saying: and your idea kills this property by downgrading it to a compile-time affair. because having a documented grammar in the parser would only allow run-time _extending_the_rs274ngc_interpreter_by_remapping_codes. It would only permit remapping of standard gcodes by changing the grammar. But the need to remap gcodes half way through a swarf-making job, without allowing a compile, is probably a rare requirement. Good to see somebody is reading this after all.. But 'remapping' is a bit of a misnomer: while a few codes can be 'remapped' (aka changed), practically unlimited new M- and G-codes can be introduced, with new optional and required word parameters. All this happens at the block/word level of the current parser. I never thought of runtime extensions -
Re: [Emc-users] Back to isolcpus=1, again...
Gene, I too see a big improvement in overall system performance by using taskset to move linuxcnc to the idle core (I am running 2.5.0-pre2 built from source). Out of curiosity how much cpu does Axis use on your machine? While running Axis I am using about 60% of the second core. I don't have a base thread (I have mesa cards doing step generation) and have a servo thread running at 600,000. Also, i noticed that if I run the latency-test on the idle core AND run glxgears there (using taskset to move it too), my latency is very bad. Worse even than the machine without isolcpus configured at all. On the IRC today Peter Wallace pointed out that that is a silly scenario since there wouldn't be anything running on the isolated core other than linuxcnc, and I agree, but I thought it interesting that the latency on that core was so much worse. -Tom -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] question on gcode parsing
I have been working for sometime on a subset of RS274ngc parser. I have a program on my Mac which reads a dxf file and converts it to RS274ngc and allows you to invoke some wizards along with it. The purpose of my parser is to re-read the RS274ngc files I create an allow them to be edited and see the output on the screen in terms of generated 3d paths. Long intro but the reason for this post is to say that writing a parser that will make sense of the current state of RS274ngc code that is acceptable to linuxcnc, is non-trivial. Even the subset that I am trying to handle is not so easy. A EBNF parser should reject code (or at least flag it as error) that is not legal for linuxcnc. As long as we allow people to define gcodes and or mcodes on the fly, it is much more difficult. I am one of those people who doesn't like code written without any whitespace but I have no problem with the current linuxcnc parser/interpreter. My goal was/is to be able to generate code that I like, formatted like I want, and that is still acceptable to linuxcnc. I see no benefit to an EBNF parser that is so loose that it will pass anything that sort of resembles gcode without flagging invalid code. Alan --- Alan Condit 1085 Tierra Ct. Woodburn, OR 97071 Email -- acon...@ipns.com Home-Office (503) 982-0906 -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Passing file names into a subroutine
And another way that works with ngcgui (files tst2.ngc,1.ngc,2.ngc must be in [RS274NGC]SUBROUTINE_PATH) $ cat tst2.ngc otst2 sub #partno = #1 (=1 partno) #value= #2 (=123) o#partno call [#value] otst2endsub $ cat 1.ngc o1 sub #thevalue = #1 (debug, this is part1 value=#thevalue) o1 endsub $ cat 2.ngc o2 sub #thevalue = #1 (debug, this is part2 value=#thevalue) o2 endsub -- Dewey Garrett -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Passing file names into a subroutine
On Wed, 2012-02-01 at 10:01 -0500, BRIAN GLACKIN wrote: ... snip What I would like avoid constantly cutting and pasting code (or filenames) into my parts program subroutine. I thought I could send via the subroutine a fourth value with the file name. The thought being that I can have a series of calls for different parts that I can cut out from the same sheet without having to mash up a massive gcode file. ... snip Why not write a g-code file for each part, then write a shell script batch file to execute the files in order? -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Fear and Loathing on the Internet
I confess that I don't read the mailing lists, or IRC on a regular basis. This morning I was searching the user's list for some information when I came upon the thread about the name change. I had made some early comments on this subject, then paid no more attention. After reading some of the posts, and noting the pledges of support by many contributors, I was trying to figure out how I could contribute to the project. I don't have any money, and my coding skills are sub-ordinary as well. What I can offer is to be the defendant of any lawsuits against the project. Any entity, like EMC Corporation, who feels they have a claim against the project can feel free to sue me if they like. I've sued and been sued, so I won't lose any sleep if the sheriff shows up with papers for me. Hopefully this will allow others, like the members of the Board, who make valuable contributions to continue their work without feeling threatened or distracted by legal issues. If this would be useful, just let me know. Thanks, Matt -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ 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 Wed, 1 Feb 2012 19:34:09 +1100 Erik Christiansen dva...@internode.on.net wrote: On 31.01.12 21:45, dave wrote: To my uncluttered mind ... read blank ... is this a good way to set the state of a machine at any given line as a precursor to restart from line no? IIUC¹, running an interpreter through the code from line 1 to a given line, with all external actions suppressed, ought to set the state of a machine for that line, if the gcode takes no input, and does no probing. i.e. state is dependent only on the running of the gcode. (But that's just theory, aka a WAG. Experts may differ.) Erik ¹ I'm not sure what part of the 129 lines quoted constitute this. ;-) Erik, The theory seems to work. Years ago I wrote such in C but I put in the dropbox and is has gotten lost in my transitions of machines and the apparent disappearance of the dropbox. I was just wondering if there was a better way. Dave -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Back to isolcpus=1, again...
On Wed, 2012-02-01 at 10:59 -0500, Tom Easterday wrote: run the latency-test on the idle core AND run glxgears there (using taskset to move it too), my latency is very bad. That makes perfect sense: the video involved in glxgears locks out interrupts for protracted periods, so running it on the same core as the real-time handler should dramatically increase interrupt latency. It seems the AXIS UI is much better behaved, so running it on the real-time core doesn't affect latency all that much. Of course, running AXIS on an otherwise idle core will vastly improve overall performance, but that's not really the point of fencing off that core. I'd want to study the whole latency thing a lot more closely, with steppers whining away and the interpreter chewing through G-Code, before concluding that running *anything* other than real-time tasks on that core was a Good Idea. Now, if you had a four-core CPU, you could put the real-time stuff on one core, AXIS on another, have two left for everything else, and get wonderful performance... but, then, that's not a cheap Atom box. [grin] -- Ed http://softsolder.com -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Passing file names into a subroutine
THanks Michael and Dwey, I think I failed to properly code the individual part files and that is the probable error. I will pluck away at it this evening and try again. Kurt, While that is one option, I am usually cutting out of a sheet of wood. I have a higher level routine that I pass the upper left coordinates of the part then use that with a G92/G92.1 This allows me to try a couple of placements simply by changing the coordinate positions in the call. Thanks all for your help. Brian On Wed, Feb 1, 2012 at 11:35 AM, Kirk Wallace kwall...@wallacecompany.comwrote: On Wed, 2012-02-01 at 10:01 -0500, BRIAN GLACKIN wrote: ... snip What I would like avoid constantly cutting and pasting code (or filenames) into my parts program subroutine. I thought I could send via the subroutine a fourth value with the file name. The thought being that I can have a series of calls for different parts that I can cut out from the same sheet without having to mash up a massive gcode file. ... snip Why not write a g-code file for each part, then write a shell script batch file to execute the files in order? -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Fear and Loathing on the Internet
On Feb 1, 2012, at 09:13 , Matt Shaver wrote: What I can offer is to be the defendant of any lawsuits against the project. Any entity, like EMC Corporation, who feels they have a claim against the project can feel free to sue me if they like. And if anyone has electronic equipment (such as computers) plugged in to wall outlets (such as power or Ethernet), I volunteer to sit on your roof and act as a lightning rod. -- Sebastian Kuzminsky -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Simulator based on Ubuntu 11.10 Oneiric
Gentlemen (I've asked before, here are no women), Anders Wallin got the simulator running within 11.10, and I made it as well by some slight changes to Anders guide. I wrote it all down at the wiki: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Build_A_Simulator_Manually And made a demo case here: http://youtu.be/PFdNbaBq760 Regards, Sven -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Control a hot wire foam cutter using LinuxCNC?
On 1 Feb 2012, at 19:03, Peter Georgi georg...@bluewin.ch wrote: I found the file with the patch from Lothar and downloaded it. So far so good. But I do not have any idea how to install it. Is their any procedure or just copy it into the Axis directory and rename it? I am in a hotel on my phone, so can't really check anything, but typically a patch is a list of changes to a number of files and has to be merged into the source code which is then recompiled. It is a bit different for Axis, as that is in python which is an interpreted language, but I am not sure how deep the changes go. If the patch contains changes to C or C++ files then you will need to install git, download the source code, install the build dependencies, merge the patch and recompile. None of this is particularly difficult, even if it sounds it. The wiki.linuxcnc.org page on installing EMC2 describes the process. Man patch and/or man git patch might help too. It is not impossible to read the patch file and make the changes manually. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ 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/31/2012 11:14 PM, Erik Christiansen wrote: On 30.01.12 07:54, Kenneth Lerman wrote: On 01/30/2012 12:28 AM, Erik Christiansen wrote: 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 No. I don't think so. The current implementation does it; not the current parser. If we go back to the compilation/execution analogy, some error conditions are detected at run time; not at compile time. There is no compile time. Both the current and future parsers are interpreters only, AIUI. I don't see how the parser can require that G1 has an Fn clause defined on the same or some previously executed line. Nor can I. It doesn't. AIUI, gcode executes with whatever value of that modaility is current. It does that now, and any new interpreter easily does the same. The grammar then _permits_ an Fn clause where we choose. The parser knows nothing about execution order; only about lexical order. Since the Fn might be hidden away in some subroutine, the parse might not have seen it. I would think that knowing whether an Fn is active is a difficult problem when looking from the outside, but a simple problem from the inside of the run time environment. (Of course, feel free to prove me wrong.) Any need to know the run-time state of a modality before run-time is illusory. That which needs to be known at run-time needs to be known at run time, not before. It is worth understanding that the run-time value of a modality is not part of the grammar. I'm not sure what you're basing these imaginary concerns on, but I can't relate them to reality, despite some effort :-) In the past you've implied this, and roughly three or four posts in the future, you bemoan the fact that Haberler's trial grammar is devoid of any explicit gcode grammar. My concerns were based on previous statements that you thought this should be done. While you could put some grammar rules in place, it is my contention that no matter how good the grammar, you will need some semantic analysis. Once we have that requirement, I believe that a framework that tests for appropriate semantics (including for example, that there MUST have been a previous -- in the execution sense, not the lexical sense -- Fword for G1) will be both necessary. If that exists, and I believe that it must, there is little extra benefit to having the formal grammar handle some of the cases. In short, I'm suggesting that: 1 -- An automated lexer would be useful 2 -- An automated parser might be useful (if it can give reasonable error messages, etc AND be reasonably modified.) If minor changes require digging through shift/reduce conflicts and trying to resolve them, that might be reason to avoid such technology. 3 -- A semantic analyzer (whether rule based or coded) will be necessary. Regards, Ken Don't get me wrong. I agree that we need a better definition of the grammar and a more structured implementation. In general, though, I prefer recursive descent parsers such as the present parser that is used for each line. I consider the ability to generate excellent diagnostic and error messages to be worth the effort of hand coding. We usually prefer what we're good at. I'm as guilty of that as the next bloke. The actual merits of the alternatives have been kicked about upthread. I wouldn't propose replacing the current parser in the forseeable future. Since there is interest in a more readable input syntax, expressed several times per year by a subset of LinuxCNC users, I have upthread already discussed implementing a filter which supplements the existing parser, but does not replace it. That way, there is scope for pleasing two groups. I recognize that my control structure (o-word) implementation leaves a lot to be desired -- to say the least. About its only saving grace is that it enables us to do a lot of things we couldn't do before. It must be redone in a way that is obviously correct and maintainable. As they say, The perfect is the enemy of the good. An available practical implementation is superior to any imagined perfection which does not yet exist. If the limitations of the current parser have forced clutter upon the user, just to get the parser to work, not to improve readability, then no-one could do a better job with the current tools. And I sincerely want to express my thanks for the working gem that is LinuxCNC. It is so infuriatingly easy for someone to come along, after all the hard work of making something good out of nothing, and say Ya know, we could improve this bit here. But it isn't done to be a PITA. There is a large user base which is happy with the status quo. That is worth infinitely more than any amount of talk about making the syntax prettier. The current implementation satisfactorily makes swarf around the globe. I
Re: [Emc-users] question on gcode parsing
On 02/01/2012 03:34 AM, Erik Christiansen wrote: On 31.01.12 21:45, dave wrote: To my uncluttered mind ... read blank ... is this a good way to set the state of a machine at any given line as a precursor to restart from line no? IIUC¹, running an interpreter through the code from line 1 to a given line, with all external actions suppressed, ought to set the state of a machine for that line, if the gcode takes no input, and does no probing. i.e. state is dependent only on the running of the gcode. (But that's just theory, aka a WAG. Experts may differ.) Erik ¹ I'm not sure what part of the 129 lines quoted constitute this. ;-) Unfortunately, if you have control structures that include loops and subroutines, the statement restart from line no may have no real meaning for some places in the code. Restart from the Nth execution of line no might be more meaningful, although it might be difficult for the user to determine the appropriate value of N. A better way to get the desired functionality might be to jog backwards along the previously executed path until the desired place in the code has been reached. The display could show the runtime subroutine stack and any important variables with an ability for the user to select items of interest. Of course, the current line would be highlighted. Then the user could say run from the current position. Ken -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Passing file names into a subroutine
On 02/01/2012 10:01 AM, BRIAN GLACKIN wrote: Hi all. I tried to ask this question on IRC last eve and had trouble staying in channel. equipment - 25 X 49 X 4 gantry router for wookwork - all cutting is 2.5D I have a subroutine o100 that at present, I pass three values too Value 1 is the total depth of cut Value 2 is the incremental depth of cut Value 3 is the feed rate My past practice has been to cut and paste the gcode of a part into this subroutine. This has been fine for multiples of a single part. I recently started calling a gcode file directly from inside the subroutine which worked fine. What I would like avoid constantly cutting and pasting code (or filenames) into my parts program subroutine. I thought I could send via the subroutine a fourth value with the file name. The thought being that I can have a series of calls for different parts that I can cut out from the same sheet without having to mash up a massive gcode file. So I modified the O100 to add that fourth value. In the subroutine, I tried calling the file with O#4 call. ON loading the code into Linuxcnc, I get the error Near Line XXX urnary operation expected . Or something to that effect. I typed the exact error in IRC channel last eve if anyone saw that. Can I pass a filename through a subroutine call?? I did try renaming the file to a numer (1.ngc) and tried passing both 1 and 1.ngc. I believe the answer is yes (I've done it in the past). You can pass a numeric argument. Then: O#4 call ... Will call O100 if argument 4 is 100. When this is called, I believe the interpreter will look for O100 in the usual way. That includes looking for o100 in a file named o100.ngc (I think). I believe that the o in o100 must be lower case because the interpret converts everything to lowercase as the first step in the parsing. At any rate, the O#4 should be treated EXACTLY as if the code was written as O100 call if #4 has the value 100. BTW: That's another place where it would be nice to have variables with string values. Ken Brian -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] rs274ngc bison/flex parser
On 02/01/2012 10:45 AM, Michael Haberler wrote: Am 01.02.2012 um 13:36 schrieb Erik Christiansen: On 01.02.12 11:48, Michael Haberler wrote: Am 01.02.2012 um 09:23 schrieb Erik Christiansen: The grammar specifies expression and control flow constructs, but seems 100% devoid of any explicit gcode grammar. I've scrolled up and down twice now, but still can't see any rapids, moves, feedrates, or toolchanges. Nuffin! Yes, and that is a feature. At some point, LinuxCNC needs to interpret the gcode. The parser you've put up does not do that. Probably folks use the term 'parser' to mean different things, which might be part of the confusion. I use in the Dragonbook/Compilers 101 sense - a program which recognizes certain syntactic constructs and nothing else. For me the term 'parser' does NOT include static semantic checks, or executable semantics. The term 'interpreter' for me denotes executable semantics, which is different from 'parser', which is a context-free affair so to speak. Does it have any purpose, if it does not do that? A better definition of the language than we currently have it, executable or in the manual? For instance, we dont have anything like a railroad diagram or a current BNF. And it would be great to have that in particular for beginners. Also an executable version at least as point of reference, and as a vehicle for other software. Some examples: 1. Expression syntax my parser actually found an error, or rather my misunderstanding of the current language, in one of the files in emc2-dev/nc_files see line 30 of http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=nc_files/m6demo.ngc;h=85a3c0f7f031a7735e1660403f22beee90302b4e;hb=50d82f006b489a0e2795e60bd617759c902fdafd#l30 : Om6demo_spindle_off if [#tool_change_with_spindle_on] EQ 0 now if you read http://www.linuxcnc.org/docs/devel/html/gcode/o-code.html, the 'if' examples have bracketed expressions. So I though, gee, must be in the language. Well guess what, it isnt - the current interpreter (at least at that point) accepts the above line just fine, and I think it skips from the closing bracket to end-of-line - one would have to read the source code to determine acceptable language. Incidentally the interpretation of 'if [#tool_change_with_spindle_on]' and 'if [[#tool_change_with_spindle_on] EQ 0]' happen to be the same, but one can do better. Blame me. Part of my specification (which was never written) is that the interpreter executes correct programs correctly. I did not implement complete error detection. Oword handling is particularly nasty. A call will execute from the first matching oword sub up to and including the matching oword that might be a return or a endsub. 2. Is a (comment) whitespace? Whitespace is squashed, we hear. Comments are removed, so I assumed they are gone at the language execution level, and are de-facto whitespace. Really? let's see: $ rs274 -g ... READ = s100m3 17 N. SET_SPINDLE_SPEED(100.) 18 N. START_SPINDLE_CLOCKWISE() READ = s 100 m 3 19 N. SET_SPINDLE_SPEED(100.) 20 N. START_SPINDLE_CLOCKWISE() READ = s 100 (on) m 3 21 N. COMMENT(on) 22 N. SET_SPINDLE_SPEED(100.) 23 N. START_SPINDLE_CLOCKWISE() READ = s(hundred) m 3 bad number format (conversion failed) parsing '' s(hundred) m 3 That kind of 'language spec' can stand improvement.. so my parser doubles as a reverse-engineering tool;) I believe that the comment IS being ignored. The objection isn't to the comment; it is to the letter m. Regards, Ken 3. backplot for CAM programs HeeksCad sports some minimalistic understanding of the Gcode it generates, for backplotting the generated tool path. Guess what it uses: a regexp-based 'parser'. Sure. A user need which has been expressed in this thread is for a documented gcode grammar. We'd like to know what is legal gcode, and what is not. If no grammar policing exists in the so-called parser, then either almost any input is accepted, or the real parser is elsewhere. You'd be suprised on what incredible junk gcc accepts as 'legit grammar' once you amputate the backend ;) Currently I dont see a formal way to describe the interdependencies of several words on a block. You can do the optional parameter words in the language but you cant recogize the conflicts and multiple uses within a block that way. It would be nice to have. b) the language we have *is already runtime extensible* at the word level According to the documentation here: http://www.linuxcnc.org/docview/devel/html/remap/structure.html#_introduction_extending_the_rs274ngc_interpreter_by_remapping_codes you're almost wholly correct in saying: and your idea kills this property by downgrading it to a compile-time affair. because having a documented grammar in the parser would only allow run-time _extending_the_rs274ngc_interpreter_by_remapping_codes. It
Re: [Emc-users] Simulator based on Ubuntu 11.10 Oneiric
On Thu, Feb 2, 2012 at 4:59 AM, Sven Wesley svenne.d...@gmail.com wrote: Gentlemen (I've asked before, here are no women), Anders Wallin got the simulator running within 11.10, and I made it as well by some slight changes to Anders guide. I wrote it all down at the wiki: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Build_A_Simulator_Manually And made a demo case here: http://youtu.be/PFdNbaBq760 Interesting Video! Which tool are you using for recording the screen operations? Thanks, Yishin -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Passing file names into a subroutine
You can pass a numeric argument. Then: O#4 call ... Here is where I made a grammar error - I typed o#4 call [var1][var2] instead Got rid of the and it passed this point of the code. The second error is I failed to put o1 sub and o1 endsub around my code. BTW: That's another place where it would be nice to have variables with string values. Guess thats a reason to upgrade to 2.5 Still running 2.4.6 here. I still have a few bugs in the while loop that increments the Z axis for each successive pass. I sent Linuxcnc into a infinte loop trying to load a malformed routine. Time to brush up on my logic statements. Thanks all for your help. Brian -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Passing file names into a subroutine
On 2 February 2012 03:51, Kenneth Lerman kenneth.ler...@se-ltd.com wrote: BTW: That's another place where it would be nice to have variables with string values. Considering that C doesn't really do strings, adding them to G-code might be nontrivial. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Back to isolcpus=1, again...
On Thursday, February 02, 2012 01:54:13 AM Tom Easterday did opine: Gene, I too see a big improvement in overall system performance by using taskset to move linuxcnc to the idle core (I am running 2.5.0-pre2 built from source). Out of curiosity how much cpu does Axis use on your machine? While running Axis I am using about 60% of the second core. I don't have a base thread (I have mesa cards doing step generation) and have a servo thread running at 600,000. Running a 25 u-sec base thread I'm seeing about 45-60% on the 2nd cpu from linuxcnc. The last version of 2.6.0-pre before the rename developed an offset in the Z that could not be homed out, so I went back to the slightly newer linuxcnc-2.6.0-pre, problem solved. Also, i noticed that if I run the latency-test on the idle core AND run glxgears there (using taskset to move it too), my latency is very bad. Expected, the screen updates for glxgears will eat a lot of time cpu. I get 7 to 12 u-secs latency running it normal, and under 3 u-secs using taskset and glxgears has no effect if it is run normally. Worse even than the machine without isolcpus configured at all. On the IRC today Peter Wallace pointed out that that is a silly scenario since there wouldn't be anything running on the isolated core other than linuxcnc, and I agree, but I thought it interesting that the latency on that core was so much worse. That's why I only run one thing at a time using taskset, latency-test OR linuxcnc. -Tom Cheers Tom, 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 Too much is not enough. -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
