On 19.02.12 00:29, Kent A. Reed wrote:
> I see that I last participated on the first of February. I was diagnosed
> with pneumonia the next day and have been out of it since.
And the antibiotics leave you like a wrung-out dishrag too, ISTR. It's
great to hear that you have most of that behind you now.
...
> After reading all the messages in this thread and its companion "Do CAM
> instead?" thread in rapid succession, I confess my brain hurts:-) In a
> way I'm glad I was out of the loop for so long. It prevented me from
> firing off spur-of-the-moment replies that probably would not have
> advanced the cause.
The recent quiet patch on the thread has allowed some progress. Today,
when adding Tomaz's probing routine to the test input, only the
subroutine call and G38.2 remain to be added to the grammar, to handle
it. (Hope to knock over one or both tonight.)
> We seem to be the proverbial blind men trying to agree a description of
> an elephant when each is touching a different part.
True, though some participants just seem to have different uses for the
elephant, and can't see why it should be circus-trained, when there's
nothing wrong with a good old plough elephant.
> One of my personality traits is to encourage academic exercises. Even
> when their result has no practical merit they usually help illuminate
> the subject; however, often they lead to practical improvements, and
> occasionally they lead to entirely new ways of doing things.
Ah, there's too little of that in the world which is replacing the one
we knew. Especially the young need to know that a good dollop of active
intellectual curiosity is a rewarding attribute.
My goal is to see what's there when we get a bit further down the track,
and then spy out where we could go from there. (Also whether we can bring
the elephant on that track.)
> I see no reason why the present speculative line of inquiry can't
> proceed alongside the continued maintenance and extension of our
> existing LinuxCNC program. As long as there are LinuxCNC users who
> depend on CAM-system post-processors or use multiple commercial machine
> controllers or employ other software tools that interoperate in the same
> environment there will be a need for a LinuxCNC RS274/NGC interpreter.
> So be it. Even if RS274/NGC were the only game in town, I'd still like
> to see work done to describe the interpretation process more formally.
Once or twice I've pointed out that the current work is only to produce
a 100% optional input filter. While LinuxCNC supports gcode filters, the
work is at little risk.
> At the same time, I see no reason why this speculative line of inquiry
> about our command language can't consider alternative methods of telling
> CNC machines what to do. Market acceptance doesn't seem to me to be a
> useful metric here. The "market" has a funny way of making up its
> collective mind---I won't bore with a recitation of successes and
> failures in technology-driven markets---but it can only accept or reject
> technologies that have been reduced to practice.
"We don't need that." is a normal response, I find, until someone asks
"Does it really do that?" Then interest gradually accumulates. With
luck, we might reach that stage, after a while, and beating the grammar
about a bit.
> Besides, what market are we talking about? I'm a LinuxCNC user who
> doesn't use commercial CAM software. Granted, the command language we
> use is reasonably well described and I've been able to write files
> myself, using text editors or various G-code wizards, but I'd be happy
> also to have more facile ways available to create a part. I suspect but
> can't prove this is true for a number of LinuxCNC users. As well, some
> LinuxCNC users are working with machines whose behaviors lie well
> outside the envelope of traditional CNC machining centers. I suspect
> they also would not be unhappy to see new ways of commanding LinuxCNC.
> Even among hardcore industrial users of traditional CNC machining
> centers there is an embryonic market for alternatives to the status quo.
> As only one external example, there is the long-running STEP-NC project
> that includes some very big global players who clearly wish for
> something better.
A more facile way to write gcode is my goal. Improved clarity of the
finished program is even more important, I believe, because I can't
believe that every gcode programmer can always remember 100% error-free,
whether to plug in a G90.1 or a G91.1 for Absolute, whether that weird
hiccup in coordinate system (i.e. workspace) numbering: G54 G55 ... G59.1
occurs at coordinate system 6 or 7? And there's no consistency with the
numbering for setting the same workspace (coordinate system). The G2 L10
command uses sane numbers from 1 to 9. Consider this test input to the
translator:
Workspace 1 = R0.20 X 87.00 Y 12.00 Z 42.00
Workspace => 1
Workspace => 7
Workspace => 9
Workspace => 10
The corresponding output is:
G2 L10 P 1 R 0.20 X 87.00 Y 12.00 Z 42.00
G54
G59.1
G59.3
Source line 22: Illegal Workspace:
Workspace => 10
###^
In the source, "=>" is used for setting modalities. Distinguishing them
from assignments to variables which take arbitrary values, and don't
have modal significance, is that we can more quickly and easily scan the
program for the most recent setting of a modality which we need to know
tha state of, to understand what we're dealing with subsequently.
Some other are:
Plane => XY
Arc Offset => Rel
Compensation => Radius Off , Length Off
A very well made point was that a tool is of limited use if its error
messages are useless. An early start has been made to fill in that hole,
with some of the more easily implemented error messages being added as we go.
The error cursor above, pointing at or close to the offending character(s),
supplements the text of the error message, to make life that bit easier.
> The bottom line is, I hope we continue our inquiries.
At this end, it's a relaxing alternative to sudoku or crossword puzzles,
providing amusement each evening, while reading several mail lists in
between. Each session, only one or two gcodes are studied in the docs,
HR syntax formulated and test cases written, grammar rules composed, and
the result debugged. But the incremental progress is leading to a
satisfying whole, and it is the opportunity to fiddle the grammar to
make that whole a more coherent and natural experience which appeals
most.
For the "clerically challenged", and lazy typists like myself, I'm also
setting up some keyboard mappings for my favourite text editor,
activated automatically when editing a .hrgc file, so that typing "W= "
will expand to "Workspace => ", as you're typing. It's just a hack,
but a convenient one. A collection of them can save a lot of keystrokes.
Now, if '=>' is abhorrent, and it should be '->' instead, it takes about
20 seconds to change. But this setting of state is a very specific form
of assignment, so a similarity in symbols seems attractive. (It "talks"
to me. I hope it does to others too, after a while at least.)
So, yes Kent, onward and ever .... onward, at the very least.
We don't know what we may find, but so long as it's fun exploring,
there's a will to go on.
Erik
--
Good judgement comes from experience.
Experience comes from bad judgement. - Jim Horning
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
