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.
Sub drill_em_there (123.456, 789.012) {
Rel Drill X#1 Y#2 Z1.5 Retract 2.8 Repeat 3 // Drills 3 holes.
}
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.
[...]
> 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 Percherons 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?)
Erik
P.S. Question: Are those squiggly brackets on the Sub better eye candy
than an Endsub instead?
--
The assessment by UN-Habitat said that the world's cities were
responsible for about 70% of [greenhouse gas] emissions, yet only
occupied 2% of the planet's land cover.
- http://www.bbc.co.uk/news/science-environment-12881779
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
