Ray Henry wrote: > Hi Jon > > I've never seen a case where changing the value of a g54 offset would > affect any of the other offset systems. No, I wasn't meaning that, but that the other systems would be relative to the G54 system at the time the G55, etc. system was set up. Tom Kramer's description of > these ten was clear that they were all independent from each other > because each of them referenced absolute machine zero. I remember this > behavior on a RedHat 5.0 compiled with Fred's 09j patch because I wrote > it into the original, now long gone "cookbook." > > Now when Fred and Matt cobbled together g92 they referenced all ten > offset systems from its offset value rather than absolute machine home. > This made all offset systems move based on revised g92 settings. > > Is it possible that what you were seeing was the result of a right click > on TkEMC's position display and a set to zero in the widget that click > raised. If so, that setting was a g92. I believe that behavior, which > I deliberately left out of the mini GUI, is different from any of the > offsets set when using the AXIS interface. Default "touch off" in AXIS > is to move g54 to the current location. I don't believe that AXIS has > an easy way to manipulate g92. (a good thing IMO) > Well, I do remember some of that TkEMC behavior, foggily, but I was looking at some G-code files from about 3 years ago, and they had this sequence in them :
G10 L2 P2 X3 Y4 G55 and the intent was clearly to set the G55 offset to (3,4) from the G54 coord system. Hmmm, well, 3 years would mean that was EMC1, for me. > I can see by your suggested use of g10 that you are creating a > relationship between g54 and the others by referencing their numerical > names and thus their current values. It is a fascinating use of g10. > Nothing inherently wrong with doing it. > > Be careful though because a running EMC could be made to have a dual > personality with respect to the numbered variables read from the var > file. Changing 5211 with a g10 immediately changes its value in the > status structure and makes obsolete the current var file. It does not > immediately change the value in the var file. That happens whenever EMC > or the GUI decides it needs/wants to. For this reason, I wouldn't try > to restart in the middle of a file that used it because we would need to > find out when the g10 values are written to the var file and whether > emc_task_plan_ini had been issued by the abort, restart, or menu > commands. Oh, no, CHANGING parameter 52xx on the fly would be a VERY bad idea! Yes, it would be VERY good to put a G54 in the beginning of such a file to get back to the original part coordinate system, and using a line like : G10 L2 P1 X#5211+1.0 would destroy the original coord. alignment so you would have to reset that with edgefinder or whatever. But, I want to get around having to do manual calculations based on absolute machine position, and make the new coord system relative to the entire part's coord system which has already been set up. Once I get this figured out, I can put it into the G-code, and know that no matter where on the table I put the part, the feature to be machined with the offset coords will be in the right relation to the rest of the part, without calculating any new offsets. But, are you saying above that the effect of a G10 L2 Px doesn't immediately update the value read when you name a variable like #5211 in the G-code? In the above case I describe, it wouldn't matter, but I could imagine repeatedly using it where it might. One could use a user variable to accumulate the offset so that wouldn't be a concern. Jon ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
