'squiggly' brackets are technically "braces". "["=left bracket, "{"=left brace,
and "("=left paren for anyone tempted to call it a curvey bracket.
--- On Thu, 3/22/12, Erik Christiansen <dva...@internode.on.net> wrote:
> From: Erik Christiansen <dva...@internode.on.net>
> Subject: Re: [Emc-users] Tool change question
> To: emc-users@lists.sourceforge.net
> Date: Thursday, March 22, 2012, 10:47 PM
> 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
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
------------------------------------------------------------------------------
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
