On Friday, March 23, 2012 10:23:48 AM Erik Christiansen did opine:

> On 22.03.12 11:24, gene heskett wrote:
> > On Thursday, March 22, 2012 09:59:01 AM Erik Christiansen did opine:
> > > 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.
> 
> Ah, but does it follow that just because AXIS knows its state, we can
> export it for Kirk's checking (if we still want to do that), or even
> test modalities directly in gcode?
> 
> If there is a way, then I could simplify the gcode generated for the
> following HR subroutine. The gcode needs to use relative distance mode
> for the three-hole G81 to work, but the sub might be invoked in a run of
> absolute code. BANG! Things go crunch if we don't restore whatever was
> the distance mode before the sub was called.

Valid point, and one that has bitten me in one form or another several 
times.
> 
>        Sub drill_em_there (123.456, 789.012) {
>           Rel Drill X#1 Y#2 Z1.5 Retract 2.8 Repeat 3     // Drills 3
> holes. }

I just got lost, 3 holes but only one XY specified?  I came into this scene 
after it was outlined obviously.  :)
 
> That currently translates to gcode which tests for the previous distance
> mode, and conditionally restores it before returning:
> 
> O105   sub  [123.456] [789.012]
>        G91 G81 X#1 Y#2 Z1.5 R2.8 L3                               ;
> Drills 3 holes. O106   if [#<abs_modality> EQ 1]
>           G90
> O106   endif
> O105   endsub
> 
> Which in turn relies on the HR mode settings:
> 
>        Motion => Absolute
>        Motion => Relative
> 
> generating this gcode, to make the current state known in gcode:
> 
>        G90 #<abs_modality>=1
>        G91 #<abs_modality>=0
> 
> If there's a way to know current modes at any program point, using only
> existing gcode capability, then I'd be quite keen to know, because
> there's no point doing extra stuff if there's a simpler way.
> 
> > > 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.
> 
> Yes. Alternatively, we could let the user put as many #includes as he
> needs at the start of each file. Then #nextfile only needs to close the
> previous file, and the includes are together with the code which relies
> on them.
> 
> > But would that not lead back to the open file limit?  Maybe by closing
> > all files before opening #nextfile this scenario could be avoided?
> 
> Ah, my previous post was long, and it didn't say clearly in one place
> that the purpose of adding #nextfile is to close the unneeded descriptor
> for the previous file.
> 
> But I hadn't checked whether the flex infrastructure used to manage
> multiple input files for #include, closes the file as well as freeing
> the buffer ... and it doesn't. So I'll go in now and fix that one too.
> Thanks for sending me off to check.

Glad I could help, even if it wasn't my intention.  Serendipity ;-)
 
> [...]
> 
> > We didn't even have one of those, just King & Colonel, 4100 lbs of
> > Percheron between them.  Best team of horses ever AFAIWK.
> 
> And now we're down to burning 30% of the world's tar sands, to make oil
> of the rest, and fraccing under our farmlands to grab a bit of gas, and
> never mind whether you'll ever again be able to use the water from your
> well to slake the thirst of the Percheron's when we're back to them in a
> couple of generations. (This week's farming paper reveals that our farm
> is in the largest region in the state opened for fraccing. Ah well, the
> water table is already declining a meter per year, due to the offshore
> oil extraction, according to the local water authority. What's next?)

Maybe, and maybe they are just passing the buck & blaming it on the current 
whipping boy.  The Morrison Aquifer, runs ISTR from SD to Texas, has been 
sucked down to about 10% of its former volume by all those center pivot 
rigs, which are in turn being shut down now, either because the cost of 
deepening the well to reach water is too high, or the energy cost to push 
it up a 1000' pipe takes all the profit.  I could see that coming when they 
drilled one such well on the property adjacent to KXNE in the 70's.  That 
rig was pulled in, drilled a 36" hole 370' deep, cased & installed a 500 hp 
Western Roller pump in 36 hours, 20 of that poking thru a layer of blue 
clay about 20 feet thick.  It is estimated that if every well were plugged 
today, it will be 50,000 years before that water is back to the level it 
was in 1920.  But without it, our ability to feed 2/3rds of the planet goes 
away, and bread will be $20 a loaf at Kroger.

That is the 18,000 lb elephant no one wants to talk about here folks.

> Erik
> 
> P.S. Question: Are those squiggly brackets on the Sub better eye candy
>      than an Endsub instead?

I have no official opinion as I have carved some C, many years ago now.  I 
suspect we would use it if it was available, but we are used to the 
endwhile/endsub syntax too, so it's a shrug.  Whatever works.  But I would 
add that if too much "C" creeps in there will be a net loss of the "feel" 
of gcode, and a tendency to write in C instead, then sit and stare at it 
for hours because it didn't do what you wrote.  Languages have 
personalities that keep them separated, usually for a reason.  ;-)

OTOH Erik, I can just as easily be ignored. ;-)

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>
Anyone who imagines that all fruits ripen at the same time
as the strawberries, knows nothing about grapes.
                -- Philippus Paracelsus

------------------------------------------------------------------------------
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