On 11/19/2013 06:59 AM, Rafael Skodlar wrote:
>> 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 does not assume, programmers do. Writing (good) code is hard,
regardless of language. Some languages may be "easier", but that is
always a very subjective view. Any programmer needs to get familiar with
the tools he/she uses before a full synergy can unfold.
A programming language is a static set of rules by which you can model a
problem. You need to learn to model correctly before you can get the
best out of things.
>> 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?
I think you misunderstand the reason for units i gcmc.
Units are there to have 1) ability to mix units without interference and
2) consistent output.
The first part is that you want to be able to work in any units you like
and have the machine take care of the conversions for you.
The second part is that what /matters/ is the output. The output is
either metric /or/ imperial, subject to the -i option.
> 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.
And therefore you should use units /correctly/ on all values. Then using
gcmc will not result in wrong interpretations.
BTW, the unit confusion of the Mars probe was in the software radar
range interpretation iirc. Had the protocol included units, then it
would have been spotted...
>> 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 .../
All gcmc coordinates are in the absolute XYZ/ABC/UVW space.
You can move relative using move_r(), goto_r() and arcXX_r() functions.
You *still* have a difference between undef values and explicit values.
The conversion to G-code omits the coordinate only if you specify undef
as value:
move([0,0,1]);
move_r([0,0,1]);
becomes
G1 X0 Y0 Z1
G1 X0 Y0 Z2
move([-,-,1]);
move_r([-,-,1]);
becomes
G1 Z1
G1 Z2
Gcmc keeps track of the absolute position internally while executing the
script, which can be retrieved at any point using the position() function.
You can instruct gcmc to output relative movements (-r option), in which
case all G-code uses turtle moves.
>> 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 ";"?
It is not redundant in my view.
If you forget a semi-colon, you get an error from the compiler.
>> Not at all. All variables are instantiated at the spot where you write
>> them. There is no need to declare anything.
[snip function]
> It was "local n, i, ..." and "res = {};" that led me to believe you need
> to initialize variables or arrays.
The "local" keyword is to force variables in the local scope of the
function.
The reason is that you need a way to prevent variable-name collisions
when you write a function. You often use "i", "n", "x",... as variable
names, which would collide on execution if not forced to be local to the
function.
Gcmc has no way of detecting whether the programmer wants to access a
global variable or intends to instantiate a local variable. Therefore
you use the local keyword to force the issue.
You still need to initialize a variable before it can be used as an
rvalue. Gcmc needs to know the value/content of a variable before you
can use that value/content.
>> Gcmc is not an interactive program and it will never be interactive.
> 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.
There is a difference between what is good for a program and what could
be done with a program.
If you take the extreme view, Zawinski's Law, then you would suggest
that gcmc will eventually read email.
I do not agree and resist that view with every fiber in my body.
A program should do _one_ simple thing and should excel at it. The Unix
philosophy of software development.
> My favorite is ipython, a CLI which was expanded with notebook to handle
> graphics etc.
I do not think it is fair or even valid to compare gcmc to python.
Python is a generic programming language whereas gcmc is a very targeted
language.
I actually do not subscribe to the liking of python at all.
>> 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.
> That's fine. What I'm concerned about is users that need to run
> repetitive tasks but don't understand CLI at all.
Well, when the time is ripe, then someone will write an IDE or integrate
it into an existing IDE.
That somebody will not be me for a very long time. My interest is not in
creating IDEs as I am a "low-level" man myself. However, I do welcome
anybody who wants to expand the horizons.
>> 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 ;-)
Actually, it is a different perspective. If I have a problem, then there
is a high probability that someone else has or has had the same problem.
If I can solve the problem for me, then I can solve the same problem for
others as well.
Sharing it is in the finest tradition of open and free software (you did
notice that gcmc is GPLv3+ licensed?). And in that tradition, release
early and release often...
More eyes make a better tool.
>> 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.
Everything has a learning curve, some are steeper than others.
There are things a user simply has to learn before using the tools. You
do not use a mill if you have no clue where the milling-bit needs to be
mounted...
As said before, wrappers can be made at a later stage to make execution
easier. However, you still need to /know/ the language in order to use
it. That is regardless. You need to know your tools before using them
(effectively).
> 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.
English is not my native tongue either, but I learned it.
The workings of gcmc are heavily based on vector mathematics, so you
need to know your math. When you are able to understand vector math, you
should be able to figure it out, I guess.
As for being for advanced users, well, that depends. The user-base and
the documentation are in the early stages. Only time will tell.
FWIW, I am not an advanced user with respect to milling, but I still use
it to a satisfactory result.
>> 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 ;-)
And I appreciate the time people take to look into it.
> Keep up the good work.
Always trying.
--
Greetings Bertho
(disclaimers are disclaimed)
------------------------------------------------------------------------------
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
