On 11/18/2013 06:06 AM, Rafael Skodlar wrote: > First, I'm not familiar with the program details. However, I wonder why > unit of measure throughout the program matters at all?
There is a simple reason why it matters. The output stage, where values are output to XYZ coordinates, will use a conversion depending on how you run gcmc (-i option). (Please note that the following interpretation will be consistent from version 1.3.0 (which is in the pipeline).) Without "-i", gcmc will default all "none" units to mm. With "-i", gcmc will default all "none" units to inch. If you use scripts solely for your own use, then there is probably no problem. However, when you start to share, then differences will eventually pop up. It is the eternal portability problem all coders have to deal with. > Mixed hardcoded measurement units inside functions is unnecessary or > even dangerous [1] I believe. Mixing metric, inches, etc. is like saying > I'm going to create a program that will compile code written in python > sprinkled with some functions in java, or perl in between into a running > program. Not necessarily a bad thing. It depends on what you are trying to achieve. Units are a far cry from mixing languages. Units are a concept. > If I understand this correctly, default units are metric. Why not > convert everything to metric? Don't all CNC machines understand it? Gcmc will convert everything to millimeter on output by default (unless you specify -i). Using units at the output-level should in my opinion always be either/or, but the problem resides not in the output. The reason for units in gcmc is to support designs that are mixed units. The problem I regularly deal with is making a box (metric) for a PCB (imperial). Now I can specify the coordinates in the design's source units and have everything fit correctly. No longer any need to do manual conversions, which are prone to error. > A unit is a unit and should not change throughout the gcmc program. > Units represent distance relationship between places of work (drilling, > welding, tapping, extruding material, etc.). Units do not change as such. You have distance units and angular units. You normally only deal with units when adding them to constants. The point being, calculation will be distance or angular throughout the calculations. The problem is when you start mixing it with "none". A value with no units associated can be interpreted in different ways, due to scaling. You need to /know/ what you are doing. Gcmc has a fixed set of rules to deal with these cases. Like any programming language, the programmer must express things in a way that will reach the proper result. > Well designed programs come with configuration file(s) which define > default values. If you work with inches all the time then set that in > the configuration file and all will be "translated" to metric in the > final code. If you use something else, like the ear size of current > crown prince of England, then that would "translate" to G-code > accordingly. [2] Configuration files are a hell to work with. Which files make up a project? I'd rather have everything in one source and define a few variables at the top to make the setup flexible. > It would also be easy to resize (scale) working units on the fly, i.e. > change from the original to whatever you want. At the top of gcmc > programs you would change/redefine default variables into whatever is > needed in a particular program. Ex. > units = inch > scale_x = 1.75 > scale_y = 1.75 > scale_z = 1 Scaling is an issue that can be seen on different levels. It is easy to scale any defined path in gcmc using vector math. However, there is no scaling at the output-level. The program defines what is output. Scaling at the output level raises a lot of issues, but you surely could implement an affine matrix to post-process all output. > Knowing you dare dealing with inches, a special function would be called > to swap "metric G-code" to US specific (G20 and G21, etc.). There are > other G-codes exceptions, specific to some older machines, that would > need code adaptation but everything else can stay the same for basic > positioning functions I believe. Gcmc will not insert G20/G21 anywhere in the output other than in the prologue, which defines the initial setup. Everything else in the g-code will always use the same output unit format. You can, of course, insert them yourselves, but that may lead to unpredictable results. It is like changing a CPU from binary to decimal in the middle of a program. > [1] If you are going to mix units (cutter.gcmc): > > move([-,-,-2.0mm]); > tracepath(padpath + offset, -2.0mm, DWELL); > move([-,-,-1.0mm]); > > goto([50mil, 0mil] + offset); This example is exactly why there are units. The above snippet uses a path that cuts out space for components (which are on a PCB). The components are placed in imperial units. However, I just want to cut 2mm into a block of plastic, which is enough to cover the component's height. > I bet you will break the tools if not worse because of a typo or you'll > miscalculate something somewhere. What happens if you enter > "move([-,-,-1.0m])" instead of "move([-,-,-1.0mm])" Bam! There is no "m" or meter suffix in gcmc. > Opinions on syntax: > "move([-,-,-1.0mm])" -> better: "move([0,0,-1.0])" or > move(0,0,-1.0mm) is it's used in other languages. The two moves are *not* the same. move([-,-,-1.0mm]) will *only* move the Z-axis move([0,0,-1.0]) will move axes X, Y and Z That is a _very_ important difference. Vectors can include "undef" values (the '-' values), which are used to move in exclusive axes only. The vector math in gcmc works in such way that "undef" is preserved over many calculations subject to a fixed set of rules. FWIW, move() and goto() accept a 9-coordinate vector (XYZABCUVW). Gcmc implicitly has "undef" values for all coordinates not specified: [-,-,1] is actually interpreted by move/goto as [-,-,1,-,-,-,-,-,-] > Line termination is also too perl-ish or java-ish IMO. LF tells you it's > the end of command or comment, why add extra character to it? I hated ; > in perl and javascripts. The ';' is part of the statement and terminates a statement. It is a grammar thing to ensure that you can easily parse the syntax with a LALR(1) parser. The ';' is there because gcmc uses a context-free grammar, i.e. white-space is inconsequential. If you do not like it, use another language. > Looking at "Gcmc example" on the website I see need to declare the > variables. Python for example takes care of variables by itself. Not at all. All variables are instantiated at the spot where you write them. There is no need to declare anything. The language is late binding and lazy evaluating. Data must be available at the time of execution for each statement. Each rvalue is evaluated during execution and not stored (i.e. re-evaluated if executed more than once). Variables are assigned values where they appear in the code. Functions too can be declared out-of-order and still run fine because the parsing of code is decoupled from the execution. This feature ensures that no forward declarations are required. What you mistake for declarations are configuration/setup for the script. It is generally a good idea to have some global setup in a place where you can easily change it if you wish. > [2] I just wish that US would stop using silly imperial inches! We are > in 2013 with dual or four core computers in everybody's pocket so it's > easy to convert to metric. There are free HP calculator emulators > available for android for those who insist dragging feet into this century. Even if the remaining few countries change to metric, we will still have a legacy that will haunt us for many many years to come. > Command line options are ok, but it's hard to remember them all. Some > are awkward or missing: --help is there, -h is not. When run without > parameters, the program should either dump a help page or present a > menu. It's not hard to provide a simple menu to handle input or output > file locations etc. "select" in bash can do this very well. Actually, "--help" is not implemented in any released version. It /is/ implemented in the current git-version. Option "-h" has been implemented from the start. Gcmc is not an interactive program and it will never be interactive. If you want a menu, then you can write a script as a wrapper. Gcmc is a command-line program and works in the tradition of all/most unix style commands. > Adding default configuration file is also a good thing IMO. No, adding configuration files to gcmc is a Bad Thing(TM). Configuration files hide what you are doing and that is not good. You can add your own wrapper with configuration files if you want, but the core of gcmc is a "simple" conversion utility, translating from one language into another. > I'm not sure what audience this program is trying to address so my > comments might be off base. Not everybody using CNC machines is able to > write complex programs so user interface, strict code verification, and > debugging/help functionality are very important. The first target was /me ;-) Writing G-code annoyed me and, as a EE/CS, I can write languages that suit me. The second target is every person who writes G-code manually. The third target is every one else. Not everybody will benefit from gcmc or wants/needs/requires to use it. User interface and strict code verification is something in another area than the actual compiler. Debugging and help will evolve. You should realize that, as of writing this mail, gcmc is 3.5 weeks old. There is no "vast body of experience" for this new language as of yet. It will evolve and improve as time passes. -- Greetings Bertho (disclaimers are disclaimed) ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
