On 10.02.12 13:13, craig wrote:
> In considering progrmming languages it is worth noting that there are a
> fair number of people, like me, who are clerically challenged. 80% to
> 90% of my errors are typographical. The number of such errors is highly
> correlated to the number of key strokes.
Tell me about it. ;-)
Even though 30 years of programming have taught me to type carefully¹,
my fingers don't spell as well as they used to. Upthread, someone posted
that redundancy can help here, if used to still get the meaning.
> For the most part I find G-code nicely concise. Verbose languages
> although more readable by some novices also have some disadvantages
> for others.
If this thing gets finished, then I'm going to have to address that
issue, or it'll just gather dust. Advanced users are unlikely to bother,
but just keep trucking with what works for them, going by responses so
far. I'd do the same.
> If considering such changes it might be good to have short commands
> where additional keystrokes making them more novice understandable are
> optional. For example for G3 one allow CCA or CCArc.
I'll adopt your suggestion. While reading earlier paragraphs, I thought
of another example. For G1, we could allow "Rapid" or any "Rap..." word.
Now we have the right result, even if there's a typo. We'll see how it
goes, because there are costs. The parser should generate a warning, to
allow later clean-up. Also, now all words starting with "Rap" are
keywords, and cannot be used as variable names. If users are content
with just lowercase variable names, then they can still use "rap..."
Gcode is concise, but the lack of redundancy means that missing by one
on the keyboard turns G3 into G2, there is no error detection, and the
arc goes south instead of north. (My other problem is that I can't read
the darn program a month later, even when that's fixed. :-(
> Note: About 80% of the g-code I use is generated by Java software
> tools that make it easy to do the ( mostly 2.5D) kinds of designs I
> do.
Then you're probably stuck with editing raw gcode, because that's what
the tools deliver. And after a time, it all becomes natural, if you do
enough of it.
One question, from someone who hasn't used CAM. The CAM package would
provide a way to specify the number of tool passes, to reach the final
depth of a machining operation?
> my $.02
There's a good exchange rate, going from experienced practitioners to
enthusiastic theorists, so it's worth more here.
Incidentally, the difficulty we have in typing error-free input means
great care is needed in lining up the "Onnn" labels on nested
"if-else-endif" constructions in the LinuxCNC dialect. (See LinuxCNC
gcode below) Compare the label-free "if-else-endif" syntax now handled
by the experimental parser. It was easy to make the parser handle nested
ifs, without labels: (OK, the fill in the "ifs" could be more interesting.)
if (fred == 2)
Spindle Mode=CSS Revs<3000 Speed=500 ; Just setting the mode
here.
if (jim < 4)
Spindle On ; Defaults to CW.
Spindle CCW Mode=CSS Speed=500
endif
Spindle ACW Mode=CSS Revs<3000 Speed = 500
else
Spindle CW Mode=CSS Speed = 500 Revs < 3000
N00006 Spindle Stop
if (jim >= 4)
Spindle Off
Spindle Mode = RPM ; Just setting the mode
here.
endif
endif
It took only 5 lines of grammar to handle these label-free nesting ifs,
generating:
O100 if [ fred EQ 2 ]
G96 D3000 S500 ; Just setting the mode here.
O101 if [ jim LT 4 ]
M3 ; Defaults to CW.
M4 G96 S500
O101 endif
M4 G96 D3000 S500
O100 else
M3 G96 S500 D3000
N00006 M5
O102 if [ jim GE 4 ]
M5
G97 ; Just setting the mode here.
O102 endif
O100 endif
However, because the LinuxCNC parser needs O-labels, it was necessary
for the input-filter parser to generate and remember these across nested
ifs. That was more effort than handling nested ifs without labels.
Even with coffee, I need hardcopy and a highlighter to untangle those
O-labels, if checking it by hand. Now I have a tool which puts them in
for me, accurately, so I can forget that low-level manual hassle.
Erik
¹ Admittedly, gcc is so good at picking up typos, and gives such good
error messages, that even an engineer can use it. (We're renowned for
being clerically challenged too.)
--
Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?"
- A. P. J.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
