I use G92 to set the XY and Z on my plasma cutter like so... Touch off by probing down in a subroutine then set the Z by the amount of hysteresis my switch has. G92 Z 0.070
In the main cutting program I set the X Y to 0 G92 X0 Y0 lots of cut moves... then clear the G92 values stored. G92.1 You could take a look at the parameters 5211 - 5219 after doing a G92 to see what is changed. I would but for some strange reason all my 2.4.7 sim configs are broken now.... John On 2/5/2012 9:54 PM, gene heskett wrote: > Greetings Guys; > > 2 questions actually: > > 1. What is the schedule saying about the renaming of this list to > linuxcnc-users@etc? > > 2. I apparently am having trouble understanding the G92 family docs, which > state: > ------------------------ > G92 makes the current point have the coordinates you want (without motion), > where the axis words contain the axis numbers you want. All axis words are > optional, except that at least one must be used. If an axis word is not > used for a given axis, the coordinate on that axis of the current point is > not changed. > > When G92 is executed, the origins of all coordinate systems move. They move > such that the value of the current controlled point, in the currently > active coordinate system, becomes the specified value. All coordinate > system’s origins are offset this same distance. > > For example, suppose the current point is at X=4 and there is currently no > G92 offset active. Then G92 x7 is programmed. This moves all origins -3 in > X, which causes the current point to become X=7. This -3 is saved in > parameter 5211. > > Being in incremental distance mode has no effect on the action of G92. > > G92 offsets may be already be in effect when the G92 is called. If this is > the case, the offset is replaced with a new offset that makes the current > point become the specified value. > > It is an error if: > > all axis words are omitted. > > LinuxCNC stores the G92 offsets and reuses them on the next run of a > program. To prevent this, one can program a G92.1 (to erase them), or > program a G92.2 (to remove them - they are still stored). > ---------------- > Ok > Then: > ------------------------ > G92.1 - reset axis offsets to zero and set parameters 5211 - 5219 to > zero. > > G92.2 - reset axis offsets to zero. > > G93.3 Restore Axis Offsets > > G93.3 - set the axis offset to the values saved in parameters 5211 to > 5219 > > You can set axis offsets in one program and use the same offsets in another > program. Program G92 in the first program. This will set parameters 5211 to > 5219. Do not use G92.1 in the remainder of the first program. The parameter > values will be saved when the first program exits and restored when the > second one starts up. Use G92.3 near the beginning of the second program. > That will restore the offsets saved in the first program. > ------------------------ > > That seems to intimate that using a G92 axis number not only stores the > desired position in the axis named, but also stores the rest of the axis > positions in 5211-5219. > > What I am trying to do is add some position offsets on a per axis basis, > but if a G92 actually updates all axis's to the current location except the > one named in the G92 command, then the subsequent execution of a g92.1 it > seems is restoring bogus numbers, as is evidenced when a new home operation > is done, the z reading of 4.0681 doesn't revert to 0.0000. > > So, assuming the machine is sitting about .040" above my little brass tube > I set in the pallet, nominally at X-0.3 Y+0.2, where I run holefinder.ngc > in order to locate the precise location that brass contact within half a > thou both ways. This routine uses G38.2 a total of five times, and sets > #100 to the real X location, and #101 to the real Y location. I then use > those #vars to move the machine to a position that is X-0.100, y0.000 from > what should be the boards left front corner, and home x and y there. > > Then I raise it far enough to change out the drill chuck holding the > conical tipped metal probe out for a collet and a 1/8" shank engraving bit, > which raises the effective tool tip by about 4" since the collet is that > much shorter than the drill chuck when its mounted,about 0.1" and run it > down slowly with the down key until the bit contacts the pcb triggering the > stop during a jog function. At that point, I home the Z. Its a bit > abitrary as I do that same G38.2 once in the o<tedautoz> call and use G92 Z > to install a very small offset, a thou or less, in Z so I can fine tune the > depth of the engraving done in the top.etch file. > > Now, in the remainder of the files, 4 more to complete the board, and at > the present I am using the holefinder to locate a hole drilled in the > board, which when the board is turned end for end, is used to install the > offset value into the x so that the etch and bot.drill will result in the > drill bit tips exactly meeting in the center of each hole. I know I will > have to break this holefinder into 2 files since I don't want to muck with > the Y location when running it the second time. > > Obviously I have to use G92 to install the Z offset that compensates for > the drill length, that is unavoidable from my reading. I have no lengths > in my tool table since I'm using a drill chuck, making those lengths > arbitrary and requiring I G38.2 to find this out after every tool change. > > So what is the sequence of G9X's I must use in the remaining 5 files it > takes to complete a board?, and which will not result in the machine moving > its Z zero up in the air, both in axis display, and visually, about 4" for > every tool change after the 2nd one. It seems to me that I need to restore > its reference such that if I ran it to X0.0Y0.0Z0.4, it should be sitting > exactly over the corner of the board and not very high above it since that > was located by a probe of similar length as one of the smaller drill bits > originally. That would seem to need a G92.3 at some point in each tool > probe. > > At that point I seem to be lost and can't find the tree I want in all this > forest. > > Thanks for any clues, or cluebats as the case may be, that will help solve > my apparent loss of Z references problem. Ideally, I would like to put all > this stuff in the callable autoz function as that simplifies the editing of > the pcb-gcode outputs to just adding the o<(ted/bed)autoz> call after each > M6 T# in the rest of them, and adding a spindle speed in the top of each > file since pcb-gcode, while asking how long it takes for the spindle to > spin up, doesn't ask for, or issue an S command. Duh... > > I'll be reading that doc some more, but it all hinges on: Does a G92 Z# > diddle the other 8 vars in the 5211-5219 group, or just the Z offset? > It seems that what I want to do is restore the whole snapshot exactly is it > was when last HOME'd, so that axis displays where it is in reference to > this original HOME'd position. Perhaps there is such a command and I'm not > recognizing it? > > Thanks again guys. > > Cheers, Gene ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
