On Thursday, March 22, 2012 09:59:01 AM Erik Christiansen did opine:

[a little snippage because I can't comment from an expert POV]

> But LinuxCNC doesn't know its current state in an exportable way, so has
> nothing to put on a stack, AIUI. And we don't have gcode interrupts. For
> the moment, we seem to only have the recommended good practice of
> starting each file with explicit modality settings.

When axis is in the MDI (F5) mode, it does display the machine and LinuxCNC 
state.  To me that says either axis is tracking it in real time, or 
LinuxCNC does have the ability to export that state.

> Each file can then explicitly reassert anything non-standard that it
> needs. It might be good practice to only break programs between
> self-contained processes. If that is done, then including a common file
> may be a workable solution.

It sounds good to me. But might turn into a bookkeeping problem for the 
operator who is assembling all these bit & pieces.  He would probably like 
to have each #nextfile have the ability to #include a header file that sets 
up the machine state to properly do the code in #nextfile.  But would that 
not lead back to the open file limit?  Maybe by closing all files before 
opening #nextfile this scenario could be avoided?
 
[...]
 
> > I think Dave's comment about being able to queue and run g-code files
> > would be part of the solution and could be a feature that could stand
> > on its own merit.

So do I where there is a tool changer that can be automated better than me. 
My ready on queue status can leave a lot to be desired. ;-)

> Well it already exists, if you're amenable to using more words and less
> "M50 P1" or "G33.1 K 0.05". I'll add a "#nextfile" command to extend the
> second method of file chaining without limit.
> 
> There's 6 pages of elementary doco so far, a couple of test files to
> further demonstrate syntax, and an executable which runs fine on ubuntu
> and debian. There are still some gcodes to be done, but most of the
> basic ones are there. Subroutines and looping are next on the list, but
> If-Else-Endif are implemented and tested. It's just rather "alpha",
> given that not everything is there yet.
> 
> > Gene's concern over subroutines makes it more "interesting". I'm not a
> > big fan of subroutines, but they aren't going away, so they need to be
> > addressed. The Tormach manual (good reading)
> > http://www.tormach.com/uploads/398/PCNC1100-3-3-UM-C1-2-1-pdf.html

Well, in the instant case, I could have inserted it with an editor, 
removing that bit of fussbudgetry, but I was trying to do the massaging of 
the pcb-gcode output by the least invasive method.  Were I more familiar 
with the likes of sed and awk, I imagine it would have been possible to 
automate it and reduce the likelyhood of one of my infamous typu's.  But 
that is not a LinuxCNC problem, it is 100% a Gene and his ancient fingers 
problem. ;)

> > has some insights on using subroutines and tool radius compensation
> > and suggests not using them or using them with restrictions. The
> > preprocessor could look for and react to these issues, such as fault
> > out if it sees a subroutine that spans a tool change, maybe.

That is a feature I haven't really tried to use, I do it in my code 
instead.  The time or 2 that I tried it, the machine had several tool 
diameters available for the move but refused to accept the command, 
obviously I wasn't grokking it at all well.

> I'll read that, once I've done tonight's stint on subroutine
> translation. (It needs a symbol table if I'm to replace those 'orrible
> 0-numbers with proper function names. So it won't be done in one
> evening.)
> 
> If we follow that advice, and use no LinuxCNC subroutines, we could
> instead use #include to the same end, just by placing call parameters in
> #1 to #30, and then using "#include ../routines/hexagonal_pocket.hr" to
> invoke the chunk of code that is our subroutine-in-a-file.

Sounds good.
 
> Since no o-guff is used, there is then none of the invisibility which
> troubles Gene, AFAICT.
> 
> I'm not saying that we won't have to whack a molehill or two with a
> shovel, to get this thing onto the tarmac, but I don't see anything
> which needs the old Cat D6 from out on the farm.

We didn't even have one of those, just King & Colonel, 4100 lbs of 
Percheron between them.  Best team of horses ever AFAIWK.  I'd buried a 
Case LA while plowing the south 80, near a windmill that was never 
disabled, so it was a bit muddy.  Those two horses, pulling on about 75 
feet of 1/2" log chain between them and the buried LA, picked the middle of 
that chain clear of the mud by about a foot, and that LA came out of the 
hole.  Daddy gave them 15 minutes to get their wind again & we went back to 
get the 4 x 16" plow I'd pulled the pins on and left in the sinkhole.  A 
well cared for team of horses will kill themselves for you with nothing 
more than a couple tsk tsk's from whomever has the reigns.  They, needless 
to say got an extra can of oats each & split the rest of a pound of WW-II 
rationed sugar cubes that night.  By 'the rest', they'd already sampled 
about 6 cubes each before being asked to lean into the chain the first 
time.

Memories, of times long past...

> Erik

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
'Tis the dream of each programmer,
Before his life is done,
To write three lines of APL,
And make the damn things run.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to