On 26.02.12 09:04, dave wrote:
[... Description of some APT possibilities snipped ]
> The only reason to do this is to make reasonable CAM available to
> those that don't have the $$ or are just philosophically resistant to
> using non-GPL software.
Yes, a popular FOSS CAM tool, well loved by its users, would be
something to try out, at some stage. But we're still looking, AIUI.
> I'm not resistant to the idea of making g-code more user friendly and
> more powerful simultaneously. If I follow your reasoning correctly
> your additions would be supported by the C pre-processor to use
> #define, include, etc.
My choice of the familiar #include and #define syntax can easily lead to
that conclusion. ;-) But I'm just using flex and bison, with a bit of C
code, to do both jobs within the translator. OK, the symbol table for
#define is more than a couple of lines, but for now I'm just using an
array and linear search, to handle the modest quantities of symbols that
we use. Linked-list hash buckets can wait till someone says it's too
slow, or we need very big tables. #define is not finished yet. Last
night I relaxed by adding some G64 translation:
Toolpath => Exact becomes G61
Toolpath => Exact Stop becomes G61.1
Toolpath => Fastest becomes G64
Toolpath => Flatten 0.005 Merge 0.003 becomes G64 P 0.005 Q 0.003
Where "Flatten" is intended to be mnemonic for the "G64 P" behaviour of
converting a flattish arc to two straight (flat) lines meeting at the
arc apex, and "Merge" should describe the alignment of several almost
colinear line segments into a single straight line. If better words are
found, then it only takes a moment to make the improvement.
I just refuse to remember what P and Q might mean in different contexts,
when I have a computer for that purpose. (It's already remembering 320
pages of fine techo detail that I've learnt the hard way, but it can
access faster now.)
> Is it reasonable to then go a step further and add a 'for' loop? Just
> dreaming, sorry.
It's doable, but it's also just an alternative idiom for a while loop,
with initialisation, test, and incrementation on one line, rather than
spread all over the while loop. So all we'd do is that translation,
since LinuxCNC gcode has while loops. Handling nested for loops would
involve a bit more work, because then we'd need a stack for the pending
lines of gcode.
> Hang in there, this kind of discussion is needed to formulate a
> logical design and push forward.
There are enough positive noises to indicate that it's well worth seeing
if we can get something useful out of it. Each gcode group being spat
out by the translator in response to mnemonic input gives a small buzz,
and adding file inclusion was fun. Getting rid of the need to remember
parameter numbers for read-only parameters such as tool diameter, will
be good. And the list of gcodes still to do is a reminder of how
powerful LinuxCNC gcode is.
Erik
--
It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that.
-J.H. Hardy
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
