Hi Bertho,
On 11/17/2013 02:23 AM, Bertho Stultiens wrote:
> On 11/16/2013 11:37 PM, Tony Zampini wrote:
>> The way I have been using GCMC is to not use any unit specifiers after
>> numbers.
>> This way, all I have to do is make sure I include G20 (program in inches) at
>> the top, and everything is
>> treated as inches, since GCMC will not do any conversions when no explicit
>> units are
>> specified (am I correct, Bertho?)
>>
>> In my example, I failed to mention that I used G20 at the beginning of the
>> program.
>
> Yes, specifying no units at all will treat all measures as "none" and
> translate the values "as is" to the output.
>
First, I'm not familiar with the program details. However, I wonder why
unit of measure throughout the program matters at all?
> However, you must take extreme caution because some built-in functions
> will add units due to implicit conversions. I do not think that it is
> wise not to specify units because future versions of gcmc may interpret
> things differently (see below).
>
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.
If I understand this correctly, default units are metric. Why not
convert everything to metric? Don't all CNC machines understand it?
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.).
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]
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
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.
[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);
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!
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.
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.
Looking at "Gcmc example" on the website I see need to declare the
variables. Python for example takes care of variables by itself.
[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.
>> To clarify my previous email, I use the "literal" statement to
>> include the G20. I don't use the "-i" switch. So GCMC thinks its
>> working in mm, and by not using any explicit unit specifiers, no
>> conversions are done. Then when I run the gcode, all values are
>> treated as inches.
>
> Adding "literal" to the code is like specifying assembly-code in a
> C-program. It is non-portable as hell. It works fine for your use in a
> specific case, but may have side-effects as things evolve.
>
Agree! Don't do it. Unit of measure should be the same in all functions
in the same program to be safe.
> The "-i" option was introduced to enable change of metric/imperial
> defaults. That was not implemented at first, but the new version *will*
> implement complete and throughout change of default. That change also
> covers the implicit conversions in built-in functions and therefore will
> no longre require you to insert a literal change of units.
>
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.
Adding default configuration file is also a good thing IMO.
> The reason for this change is that I want metric/imperial conversions to
> work transparant and correctly under all circumstances. Part of the
> reason for gcmc's existance is the automatic unit conversions and that
> should simply work.
>
> [if I rant to much here just ignore me :-]
> Not using explicit units in the source will result in interpretation
> differences, depending how you compile. This is a consequence of the
> grammar and design. However, it does not follow that you should exploit
> this exeptional case. At least not when you want something to be portable.
>
> It is fine to use/abuse for your own projects, but you should be careful
> and painfully aware that you are on thinner and thinner ice as gcmc
> evolves and time progresses.
>
> All that said, making "-i" work on the global default improves
> predictablility of the generated code and does not worsen the situation
> (until I get a brainfart that has burning side-effects).
>
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.
--
Rafael
------------------------------------------------------------------------------
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
