fanuc controls offer the current state of the controller modes via their current parameter values, including the current values of the various axes.
so, for example, a g28 x0 command could equivalantly be g#2002 x-#5030, where parameter 5030 is the axis position, and parameter 2002 is 0, 1, 2, or 3, reflecting the presiding state of the modal group for axis interpolation. maybe this is not the best example, but machine mode condition being registered in program accessible space comes in handy in many places, like in a tool change routine. another controller feature that is nice is the ability to overwrite controller words with customized subroutines. for example, commanding T6 will invoke a subroutine (number defined by the T overwrite parameter setting) that will move the machine to the toolchange position, set up the spindle, change to the called tool number (T's input value), and maybe even set up the appropriate offset from the tool height offset table (which is another section of the controller's parameter space). i seem to remember linuxcnc looking like it had alot of those type of things analogously accessible through parameter space. i'm sure i saw stuff about the work coord params, and tool offsets i think. ..sections 12.5 and 12.13 of emc2 user manual talk about parameters and machine modes, but i dont see any comprehensive listing of numbered params. " 12.5 Numbered Parameters A numbered parameter is the pound character # followed by an integer between 1 and 5399. The parameter is referred to by this integer, and its value is whatever number is stored in the parameter. " then it says something about a few params that are read only based on current tool number. i'm guessing the other several thousand should logically have all the other relevant info in them, but there is no documentation. no documentation = might as well guess the cost of a fully specified device. or bust out your fishing gear and all of your spare time, and maybe you'll get luckey. --- On Fri, 3/23/12, gene heskett <[email protected]> wrote: > From: gene heskett <[email protected]> > Subject: Re: [Emc-users] Tool change question > To: [email protected] > Date: Friday, March 23, 2012, 7:59 AM > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
