On 11/18/2013 02:45 AM, Bertho Stultiens wrote:
> 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.
That's why I jumped on it ;-)
>
>> 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.
Exactly. Write once, resize with scale at the top. Everything else stays
the same. That's my opinion.
>
> 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.
Don't assume things. I see programmers assume too many things and the
rest of us have to deal with it later on.
>
> 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.
This is where I disagree. Your example program has
TW2 = TW / 2.0;
used later as
padpath = {
[0mil+TW2, -75mil+TW2], [0mil+TW2, 75mil-TW2],
[550mil-TW2, 75mil-TW2], [550mil-TW2, -75mil+TW2]
};
If you can declare some value at the top, then everything could be
assumed to be a (metric) unit and adjusted later with added or
subtracted value stored in a variable. Why use special command line
option when you can declare it in the program?
> 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 understand. However, danger in mixing different units is very big.
That's how NASA crashed a satellite on Mars mixing metric and US units.
>> 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.
What happens if one uses m instead of mm? This:
example/raffi.gcmc:106:17: error: ']' expected
example/raffi.gcmc:106:17: error: ',' expected
Good, you prevent
>
>
>> 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
My expectation was that move 0 is no move. Are you saying this are
coordinates not a relative move? Learning curve .../
>
> 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.
It's my belief that there is no need for redundancy. While it's easy to
see new lines, what happens if you forget ";"?
>
> If you do not like it, use another language.
that's always an option isn't it.
>
>
>> 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.
>
unction erode(srcpath, width)
{
local n, i, pp, pc, pn, v1, v2, bisect, newpoint, crossp, res;
n = count(srcpath);
res = {};
for(i = 0; i < n; i++) {
pp = srcpath[(i-1+n)%n]; /* Previous point */
pc = srcpath[i]; /* Current point */
pn = srcpath[(i+1+n)%n]; /* Next point */
v1 = normalize(pp - pc);
v2 = normalize(pn - pc);
bisect = width * normalize(v1 + v2);
newpoint = bisect + pc;
if(i > 0) {
/* Check convex polygon interior angle */
crossp = v1[0] * v2[1] - v1[1] * v2[0];
if(crossp < 0.0) {
newpoint = -bisect + pc;
}
}
res += { newpoint };
}
return res;
}
It was "local n, i, ..." and "res = {};" that led me to believe you need
to initialize variables or arrays.
> 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.
It must be the git version I have used I guess.
>
> Gcmc is not an interactive program and it will never be interactive. If
Sure. And it won't need more than 1MB of memory ;-)
Don't be modest, think big. Based on previous experience we know that
programs evolve into ever more productive tools.
My favorite is ipython, a CLI which was expanded with notebook to handle
graphics etc.
> 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.
>
That's fine. What I'm concerned about is users that need to run
repetitive tasks but don't understand CLI at all.
>
>> 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
not necessarily true.
> can add your own wrapper with configuration files if you want, but the
true.
> 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.
exactly. But when you start sharing it, expect comments or suggestions
to come in ;-)
>
> The second target is every person who writes G-code manually.
>
> The third target is every one else.
That's what I was wondering and suspected. When you are dealing with
people without any programing experience, they'll wonder why this or
that is so complicated. I've seen many command line mistakes that turned
into big problems like bring a large cluster of systems down which makes
me believe that it's better to run program from a menu for most users.
You prepare config files in advance before you run anything.
In addition, not everybody understands English commands and I was hoping
that this could help such users create relatively simple CNC tasks quickly.
As is, GCMC is most suitable for advanced users.
>
> 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.
>
>
I was not aware of the fact that this is less than a month old project.
That's really impressive. As you can see, some people take time to look
into code ;-)
Keep up the good work.
--
Rafael
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
