[gar]

051026-0618 EST USA

1strokedrs:

When I tried your program with the Z0.125 on the G43 line I got erroneous positioning results in Z on the following lines of code.

When you do multiple operations on the same hole locations the subroutine is useful to prevent making a mistake in one of the operations relative to others. Often times on a hole we will spot drill, tap drill, shallow clearance, and tap. This is four different operations on the same location.

I do not have time to discuss tool setting at this moment.

.

[1strokedrs]

Gar
On this particular program all we are doing is drilling a bolt hole circle in a bolt on end cap for our valves and one cap has a locating pin hole for a locating pin that locates the spool inside the valve. I have moved most of our drill and tap operations to our lathes that have rotary tools or a C axis so it can be done while the turning,facing and boring is done. This makes the lathes cycle time a little longer but it keeps us from having to do another set up on the mill and it eliminates a whole other process.
The only other process we do alot on the mills is drilling side holes in our valve bodies with inserted drills and inlarging the holes a little with a inserted end mill or K-tool using circular interpolation. We use sub routines alot on these programs because there is usually at least three holes that are the same size and depth and then all we have to do is tell the A axis to rotate to the desired spot then pick up the sub again.

[gar]

051026-2002 EST USA

1strokedrs:

The question in the first paragraph of your post of yesterday identified with a #20 was not directly answered. Why the program ran fine previously and then failed is not easily answered.

What you need to do is probe the machine with instruction sequences like I suggested to see if you can duplicate the malfunction in a way that will identify the cause.

More on tool offsets in the Z axis. I believe in the HAAS machine that the content of the following items are added to determine the position of the machine, excluding the complex calculation for cutter comp.
G52 + G5X + TOOL LENGTH + TOOL WEAR + Z command. This sum then equals the machine absolute position in Z.

The only item that changes very often is the Z command.

Within some constraints, I do not not know the limits, all the different components can be given any value you want such that the result is to put the tool where you want it. What this means is that I could make G52, G5X, and TOOL WEAR all 0 and then define my Z=0 plane with TOOL LENGTH. Obviously different tools have to have different values in their TOOL LENGTHs. Suppose tool 1 has a length of -14.1 to put us at working Z=0.

Instead lets make tool 1 length 0 for working Z=0. Next make G52 = 1.0. Now G54 must equal -15.1 to put the tool in the same position as in the previous paragraph. You can juggle these all over the map so long as the unknown constraints are not exceeded and the tool is placed where you want it to be.

Obviously once you define the length offset for one tool, then all the other tools have to have their length offsets defined to that reference tool.

Note G52 is a different type of command, than are the G5Xs. G52 is used with arguments for X, Y, Z, etc to set values into the G52 memory locations. G52 with no arguments does nothing. Any unspecified argument makes no change in the current value for G52.

The G5Xs are a modal command that uses no arguments. It simply says to the program to use the values at its associated memory locations in the above calculation until further notice. Further notice could be the issue of a different G5X command, or some other reseting function.

Have I made any mistakes and does anybody understand what I am trying to say?

.

[HuFlungDung]

/me timidly raises hand for understanding

I'm with you Gar. There's got to be a systematic way to prove that the machine is losing position in a way that it cannot recover from, or else a programming or settings error.

[gar]

051027-0948 EST USA

A note on setting 33. From the HAAS manual:

HAAS and Fanuc modes use G52 differently then Yasnac. "In a Yasnac control, the G52 stands on its own as another work offset." Thus in Yasnac mode G52 would be removed from the equation I specified last night.

A note on setting 64 (T. OFS MEAS USES WORK). If this is OFF (our normal useage), then TOOL OFFSETS set with the TOOL OFFSET MEAS button are the machine absolute position at whatever position the tool is at. This is also the value displayed at the bottom of the offsets screen for Z. If I turn setting 64 ON, then according to the HAAS manual the entered TOOL OFFSET will be relative to the currently selected work coordinate Z offset.

This is somewhat incomplete because no direct reference is made to the effect of G52 (non-Yasnac). In actuality it is the combination of G52 and G5X. As an example: I set setting 64 to ON and tool 2 to have a machine absolute position of -14.3790. This is 1" above our vise jaw, thus the reason for the strange number. Also set G52 Z=1.0050, and G54 Z=2.0000. Hu the Z value at the bottom of the OFFSET screen is still -14.3790 after turning setting 64 ON. After pushing the TOOL OFFSET MEAS button the value entered into the tool 2 offset (cursor is on tool 2) is -11.374. This is derived from -14.3790 +1.0050 +2.0000 = -11.374.

Hu. Going to the POSITION page and making work the default did not change the value displayed at the bottom of the OFFSET page. Thus, it appears that what is displayed at the bottom for Z is always the machine absolute position.

Next I made G55 Z=14.0000 and changed the current work offsets to G55 usingt MDI. Still with setting 64 ON the measured tool offset is 0.6260. This derives from -14.3790 +14.0000 +1.005 = 0.6260.

.

[Geof]

051027-0948 EST USA...Thus, it appears that what is displayed at the bottom for Z is always the machine absolute position...

This is what I was trying to get at in my post further above. If there is an entry in G54 Z this is subtracted so the automatically entered tool offset, when combined with the Z entry, puts the tool in the correct place. I wondered if it was possible that there was a glitch somewhere in the operating software such that this type of subtraction was being performed even though there was no entry visible in the G54 Z column.

[gar]

051027-1523 EST USA

Geof and others:

Whatever is happening in 1strokedrs's machine appears to be strange. That is why I would like to know exactly what happens to the absolute machine Z position as his program goes from one line of code to the next. Then knowing the positions that the machine takes on it might be possible to determine the cause.

Fundamentally the machine is operating in the absolute machine position. This means there are up-down counters on each axis that keep track of the machine absolute position. Any command to go somewhere takes the various offsets and the relative motion commanded value and combines these to create the absolute machine position to go to. Then the control moves the machine until its absolute position corresponds to the commanded absolute position.

There appears to be no indication that there is any error in the machine knowing its correct absolute position.

Thus, any problem has to relate to how the commanded position is generated. If the machine will always do exactly the same thing when the same sequence of instructions is executed, then the process is deterministic, and it should be easier to isolate the cause. If the results are random, then the solution can be much more difficult.

In either case an understanding of the logic of the generation of the command is important.

If we disregard how tool length offset values are generated, but simply note the values stored on the offset page, and these do not change from before to after our test, then we can reasonably assume these do not change during the test. With these known values and changing G5X from one selection to another G5X selection, and both of these are known, then the change in absolute machine position for a commanded Z=0 for both G5Xs should produce a machine position difference equal to the difference between the two G5Xs.

.

[1strokedrs]

Geof,
I think what you are saying about the subtraction thing might be something,because if there is a zero in the G54 Z column the first tool stops about six inches above the part when it is told to go to .125 above the part. This still does not explain why it does not pick up the Z column in G55-G59 it only picks up the Z in G54.I have determined this by leaving the Z column on G54 zeroed out then touched the tool off using the tool offset length page then told it to go to Z 0.0 on G54 and it stopped six inches above the part then touched the tool off on G55 Z column and left that tool # zero on the tool length offset page and told it to go to G55 Z0.0 all while Z column on G54 is still zero and got the same result.

Gar,
The machine seems to repeat even if the position desired is right or wrong.It will go to the same place every time. We do use the yasnac mode with setting 64 on and we never change G52 from being zeroed out.

I have not had a chance to try your test program yet but I will as soon as I get enough time.I have had a tough time this week with a tuneable boring bar on our Okuma lathe.It is wanting to chatter no matter what I do and our Kennametal rep thinks something has gone wrong with it and this is the only bar we have that is long enough to do the job we need until we get another one tomorrow.

Thanks for all the info and replies

[gar]

051027-2025 EST USA

1strokedrs:

Since you are in Yasnac mode G52 values have no effect unless you use a command of G52 (no parameters). In Yasnac this G52 is just another G5X.

.

[HuFlungDung]

Gar,

So as I understood from a brief study of G52 a while ago, that to cancel a G52 you actually had to enter a G52 X0 Y0 Z0. In effect, calling a G52 is equivalent to running the subsequent portion of the program only as a subroutine (but remaining in absolute mode), where a temporary origin for the sub coordinates is located at whatever position the original G52 did call.

So, if a person had a G52 active, and had some values in the G52 offset table, but then went and set those values to zeros, without a proper cancellation of G52 by calling G52 X0Y0Z0, could this cause a corruption of the offset table?

[gar]

051028-0831 EST USA

Hu:

I use the word "G52" to mean the instruction sometimes, and other times to the group of variables associated with G52. The instruction G52 is different depending upon the mode setting 33. The variables associated with G52 are always at the same locations.

The contents in the G52 offset memory locations (X #5201, Y #5202, Z #5203, ....) are always active in HAAS and Fanuc modes. These memory locations are what are displayed for G52 on the OFFSET page. So if these contain something other than 0, then they affect your position.

In HAAS mode the G52 values remain at whatever they were last set to even thru a power off and on reset.

Remember I use G5X to represent all the work offsets except G52 and G53 in HAAS and Fanuc modes, but would include G52 in the G5X group in Yasnac mode.

Important to note that the last G5X used by the machine is the default value at the beginning of the same or another program. However, after power off and a power on reset the default is G54. Therefore at the beginning of every program you must specify one of the G5Xs to guarantee you are using the work offset that you expect to use.

The answer to your first sentence is yes if you are in HAAS mode. Or you have to use another method to change the values in #5201. In Fanuc mode there are various conditions, such as M30, see HAAS manual under description of the three G52 modes, that reset G52 to all zeros.

I do not understand the second sentence of your first paragraph. In HAAS or Fanuc mode the plain instruction G52 with no parameters does nothing. In Yasnac G52 (no parameters) is the same as any other G5X. These have nothing to do with or without subroutines. I think HAAS's use of the term "local (child) coordinate system" is sort of confusing. I think it is much clearer to think of whatever is in G52 as a modifier (add to) to the active G5X.

In your second paragraph. I would prefer to say that the contents of G52 are always active in HAAS or Fanuc mode. If the contents of the G52 memory locations are zero, then G52 has no effect.

Continuing on the second paragraph. The memory locations #5201-#5205 are modifiable directly, #5201 = 1.005, or thru the OFFSET page, or thru G52 X1.005, or via RS232. In HAAS mode, once set, they remain set until changed. So G52 X0 Y0 Z0 is not the only way to change these values.

.

[Geof]

...Important to note that the last G5X used by the machine is the default value at the beginning of the same or another program...

I just checked on my Haas simulator using both Fanuc and Haas mode: If you run a program with only G55 the Work Offset is G54 until the command G55 is read, naturally it remains at G55 through all succeeding blocks but RESET or M30 reinstates the G54 default. In other words if you only use G54 it is not necessary to command this at the start of a program; for any other Gnn the command must be present.

[HuFlungDung]

Gar,

I'm not pretending to have experience using G52 as you do, but this is the article on which I base my thinking at present:
http://www.mmsonline.com/articles/0100cnc.html

So I don't see a valid use for G52 as you seem to be applying it. You seem to be applying it before your G5x calls, whereas it would seem as though it is meant to be called inside of a G5x program for temporary execution of a subroutine. The only advantage is that the subroutine can be written in absolute coordinates. When done in that position, then the G52 must be cancelled properly with a G52 X0 Y0 Z0.

It would be highly irregular to actually program any change in Z via G52, since the tools are working at the same heights in both coordinate system, but anything is possible, even if it was attempted by a programming mistake.

So that is why I am postulating a possible error scenario, where lets say a G52 X6. Y6. Z6. is called, but the way the program was written (incorrectly), a call to cancel that with a G52 X0 Y0 Z0 never arrives. Then, the operator enters new values into the G52 offset register which makes all offsets zero. Is it possible that the control software might not deal with this sort of cancellation properly?

[gar]

051028-1051 EST USA

Geof:

We are both correct. The tests in my previous post were run on a HAAS 1998 VF3, and G54 is not defaulted on a RESET, etc. I loaded the test program on our 2000 VF-0 and a RESET did set the default G5X to G54 on RESET.

So the real problem becomes what vintage machine is being used. One probably should write programs to be compatible with older machines when possible. There are some areas that we have encountered where this is not possible and it creates major problems. HAAS does not tell you about internal software mistakes and about changes to correct them.

Hu:

Your use of G52 per the referenced article is a good use for G52. Yes you do need to be careful to reset G52 to zeros in this type of application, or any application, especially in HAAS mode. This is like balancing parens in equations. In Fanuc mode G52 is automatically RESET to zeros on RESET, M30, or G92 per HAAS manual. I have not tested all these conditions.

The major point I want to make is that in HAAS and Fanuc modes that no matter where you are in a program the contents of G52 are added to the contents of G5X. The contents of G52 or for that matter G5X can be changed at any point in a program, at least if you have MACRO capability.

I view the G52 values as a means to modify a base coordinate system, G5X, on a temporary basis. Temporary is a relative term here, it could be days.

The same result could be achieved by saving the values in G5X to temporary locations such as #501- #505, then modify the G5X values to the new temporary coordinate position, do your work, then at the end restore the values from #501-#505 to the G5X locations.

The use of G52 is simpler and does not require MACROS.

.

[Geof]

GAR;

Okay, we should all preface things with: "Using a 19nn or 20nn machine in Fanuc/Haas/Yasnac mode" this is what happens. I agree with you about Haas being coy about software mistakes/corrections; this is annoying because I have had several with my new machines ranging from a Bolt Circle canned cycle trying to go back to the center of the pattern after the last hole but before it retracted the drill and a machine doing restarts without picking up the correct tool. Ouch!

Back to this thread:

Hu;

That is a good article you linked. Clearly according to the author I am non-traditional because I rarely use incremental subroutines. Regarding your idea that incorrect cancelling of G52 could cause funny things if it was not cancelled then values would be visible in the G52 line on the work offset page so this should be obvious.

[HuFlungDung]

Geof,
Perhaps the values should be visible, unless there is a software glitch. However, I do not believe that one can safely assume that calling G52 X0Y0Z0 is the same as entering zeros in the offset table, because cancelling the offset does not actually put zeros in the table. The values are being retained elsewhere in memory. If they persist somehow (get stored in some other variables somewhere) then, the problem would not fix itself by restarting the machine, nor by putting zeros in the offset table.

[gar]

051028-1244 EST USA

Hu:

The G52 contents are stored at the previously said #5201 ... locations. These can be loaded via #5201 = something, or G52 something, or on the OFFSET page by entering something. The values on the OFFSET page are derived from said #5201 ... locations. When you write a value into G52 on the offset page it is entered into #520x, and then displayed on the OFFSET page, or at least the equivalent of this. All of this you can experimentally determine.

Machine position excluding cutter comp is determined from #5201 + #5221 + #2001 + #2201 + X command, #5202 + #5222 + #2002 + #2202 + Y command, #5203 + #5223 + #2003 + #2203 + Z command, etc. These generate the desired absolute machine position. You can also check the values at #5201 .... via the following technique:
#101 = #5201
#102 = #5202
#103 = #5203
then go view #101 ....

If I do G52 X2.0 Y1.3 Z-2.7 in a program in HAAS mode, single step thru this instruction, then switch to the OFFSETS page I will see these programmed values at G52. If I follow this with G52 X0 Y0 Z0, and after executing this instruction and I check G52 OFFSETS, then G52 XYZ will all be zero.

I did not test this at this point in time, but I have previously done the equivalent.

.

[HuFlungDung]

Oh, ok, I think I get it now
I was thinking that I would have to enter values directly into the offset page at G52, but of course, that would not be handy in real life, and I suppose it is actually impossible to enter any values into G52 "manually". Now I get it!!

[Geof]

Hu:

I just checked and it is possible to enter values into the G52 page and because the Haas mode does not zero them at RESET or M30 they stay there. This could prove interesting if you did something like this accidentally.

[gar]

051028-1351 EST USA

Hu:

You can enter values manually into G52 in the OFFSET page. But here is how it gets confusing.

If you are in HAAS mode the values you enter manually thru the OFFSET page, or thru the other means will stick. This is because G52 in HAAS mode is not cleared on RESET or other ways to get to your program.

However, in Fanuc mode G52 is cleared as specified in the HAAS manual under G52 Fanuc. Also cleared in going from the OFFSET page to the program via PROGRAMS, MEMORY.

.