Work offset misbehaving.

[metalmayhem]

Someone may read this who needs information. , the G43 Z1. is a safe height that we can visually verify before a crash

thats my preferred g43 height to , better to be safe than sorry .

Still, after all these years it's a fun job, isn't it?

it has it's moments and doing what I do now is fun since I'm my own boss . I've been in and out of a number of shops through the years , some good some bad , and the bad had me thinking I should have became a plumber , electrician , anything other than

[HayreAss]

Yeah, my original code, from post #9 in this thread is still running.
Including the code that apparently CAN'T be used like we use it...
It's made close to 100 more parts since I was told it wouldn't work...

I too use a safe height line in these programs.
In that one, it's G43 H14 Z.716
That gets me 1/2" above the .432" diameter part in the 4th axis.
Also a handy place to check with a gage pin if I feel the need.
On most programs, it's 1"
I use the same base program on close to 60 of these parts, so I have optimized it for our work flow.
1/2" is handy.

[mactec54]

No, they don't call that a glitch they call that an error, or a crash if it crashes.
A glitch is when it is NOT behaving as expected. Differently than it is presenting itself, etc...
As happened with my machine.
Like it or not.

An example would be when a machine corrects itself after clearing a work table, and re entering the exact same numbers.

And reentering the correct Tool offset has a habit of correcting things

[HayreAss]

And reentering the correct Tool offset has a habit of correcting things

Yeah, well if you could get over yourself, and read, you would know that the offset was correct.
It was probed.
Then it was re-probed.
Then everything was calibrated.
Then it was probed again.
Still glitched.
It didn't behave right until the offset table was wiped.
The exact same numbers are in the table now, as when it was acting up.
Photos of the offset table are here, in this thread, for all to see.

It's really not that challenging of a concept to grasp.

[HayreAss]

Ahh, you specified tool offset...
Same story though.
As I mentioned earlier, the tool cut fine on other work offsets, and is still the same value that it was before.
My machine is also set up so that H and T have to match. So it can't be reading a different H value.
Unless it's glitching...

[mactec54]

...Burs, please just close this thread and Mactec you need to see a Doctor.

DJ

What you still don't remember how a G49 actually works here is a reminder, it must be used with the 0ffset you are wanting to cancel placing it in the safety Block it will do absolutely nothing, it is completely redundant at that point in all modern controls, the only way it can work is if it's placed below the tool 0ffset you want to cancel like this wiki enjoy your visit

https://wiki.cnc.xyz/G49

[mactec54]

Yeah, well if you could get over yourself, and read, you would know that the offset was correct.
It was probed.
Then it was re-probed.
Then everything was calibrated.
Then it was probed again.
Still glitched.
It didn't behave right until the offset table was wiped.
The exact same numbers are in the table now, as when it was acting up.
Photos of the offset table are here, in this thread, for all to see.

It's really not that challenging of a concept to grasp.

You only showed the 0ffset Table you did not show the Tool 0ffsetTable if you had it would have been easy to calculate where the problem was

[mactec54]

Ahh, you specified tool offset...
Same story though.
As I mentioned earlier, the tool cut fine on other work offsets, and is still the same value that it was before.
My machine is also set up so that H and T have to match. So it can't be reading a different H value.
Unless it's glitching...

No, it's not the same story

Thats how the Haas control is by Default it is not something that you have to setup, I have a number of Haas machines nothing older than 2008 so know how they work, mechanically and electrically, I service any part of these machines and others as well

[HayreAss]

No, it's not the same story

Thats how the Haas control is by Default it is not something that you have to setup, I have a number of Haas machines nothing older than 2008 so know how they work, mechanically and electrically, I service any part of these machines and others as well

It is the same story though.
Well, with reading comprehension it is.
I specified that the tool cut fine on multiple offsets, just not G56.
The tool offset table is irrelevant, really. And the work offsets were all the same.

If you program the same tool, to do the same thing, on 3 different work offsets (That are really all set exactly the same) and it cuts air at one of the work offsets, there's a problem.
One that looking at the offset tables won't solve.
Or we would have solved it before there was even a thread here.

How is the default value in the control relevant?
It's a variable, that can be changed.
I specified how mine is set, so we can rule that out.
It's part of troubleshooting. (Control and eliminate variables.)
Unless of course, there's a glitch, and it isn't working...

Do you earn a commission or something for being a glitch denier?
I find it difficult to accept that a grown man (I presume, apologies if I am mistaken) is unable to accept that modern electronics glitch on occasion.
Especially one who can service the electronics.

If you'd like, I can post a shot of the tool table.
I'm kind of morbidly fascinated to see where that leads.
I can't imagine how knowing that tool 14's length offset is 4.6091 will lead us anywhere fruitful.

[mactec54]

If you'd like, I can post a shot of the tool table. I'm kind of morbidly fascinated to see where those leads.
I can't imagine how knowing that tool 14's length offset is 4.6091 will lead us anywhere fruitful.

After the fact does not count

If you had of at the time before you reset everything posted the Tool Table and the work 0ffset Table at the same time that would have been easy to calculate to see if all the Tools matched giving the correct 0ffset for each.

Our machines run 24 / 7 and they don't have 0ffset Glitch's, only input errors by the setup machinist, which is very rare, we have the same electronics same hardware same software as you do, if there was a Glitch in (1) machine control it would be the same for every control out there that has the same spec software

Electronics don't Glitch, if they did, that part would fail, or would show a fault of some kind, Software can Glitch, so try and understand what makes your machine do what it does

[HayreAss]

Yeah, mine run a lot too.
Not 24/7, but 50 -70 hours a week.
And in 10 years, this is my first glitch of this type.

We are talking 1 tool here. Not tools.
A
Single
Tool

Misbehaving in
A
Single
Work Offset

G54, 55, and 56 are the same in X, Y, Z, and A, as can be seen.
T14 is 4.6091 (it's the same now, as it was then, as I ONLY reset the work offsets.
I still have the picture I sent Haas, real time.

If I run
T14 M06
G54
G0 G90 X.1 Y.1
G43 H14 Z1.

Then
T14 M06
G55
G0 G90 X.1 Y.1
G43 H14 Z1.

and finally
T14 M06
G56
G0 G90 X.1 Y.1
G43 H14 Z1.

And 2 of them go to the same place, but the third one doesn't, where is the operator error?
It's the same code, the same tool, the same tool offset, the same EVERYTHING except the work offset. (and they are all set the same)
That is the equivalent of what was happening.

I sure hope they give you a good bonus for sticking to the "Haas machines CAN'T GLITCH" party line.
It's impressive.
Really.

And yes, it's likely the actual software that glitches in electronics.
Result? Your electronics glitched.
Colloquially many Americans refer to things with electronics in them, often times run by software, as electronics...
No need to be uppity over semantics.

Good lord, you mind would likely pop if I showed you video of the last glitch.
Haas actually sent an engineer out to witness it, and troubleshoot, because it was 'impossible'.
No solution was found, so it was blamed on a 'power surge'.

[HayreAss]

....

[mactec54]

[QUOTE=HayreAss;2530150]Yeah, mine run a lot too.
Not 24/7, but 50 -70 hours a week.
And in 10 years, this is my first glitch of this type.

We are talking 1 tool here. Not tools.
A
Single
Tool

Misbehaving in
A
Single
Work Offset

G54, 55, and 56 are the same in X, Y, Z, and A, as can be seen.
T14 is 4.6091 (it's the same now, as it was then, as I ONLY reset the work offsets.
I still have the picture I sent Haas, real time.

If I run
T14 M06
G54
G0 G90 X.1 Y.1
G43 H14 Z1.

Then
T14 M06
G55
G0 G90 X.1 Y.1
G43 H14 Z1.

and finally
T14 M06
G56
G0 G90 X.1 Y.1
G43 H14 Z1.

And 2 of them go to the same place, but the third one doesn't, where is the operator error?
It's the same code, the same tool, the same tool offset, the same EVERYTHING except the work offset. (and they are all set the same)
That is the equivalent of what was happening.

And the Program you have just posted here is using a very different format from the program you first posted why the change.
It will never Glitch an 0ffset again if you use the Format, you have just posted

So, this is on a small machine Mini-Mill or similar size Haas machine you are using??

And yes, it's likely the actual software that glitches in electronics.
Result? Your electronics glitched.
Colloquially many Americans refer to things with electronics in them, often times run by software, as electronics...
No need to be uppity over semantics..

Only because they don't know any better, and pretend to know something

Good lord, you mind would likely pop if I showed you video of the last glitch.
Haas actually sent an engineer out to witness it, and troubleshoot, because it was 'impossible'.
No solution was found, so it was blamed on a 'power surge'.

So, it was not repeatable, it would be easy to see if it was a power surge as there would be a fault that would have been shown on the screen

[metalmayhem]

the format between the original code posted and the above would have zero effect on the issue . There is no benefit or disadvantage to having the g54 on a line of it's own . Also m6 does not turn on the spindle after a tool change , if it does then thats a problem that should be looked into

HayreAss , did the haas tech witness the issue or did he take a shot in the dark as to what may have caused the issue . I have very little faith in haas techs

[HayreAss]

And the Program you have just posted here is using a very different format from the program you first posted why the change.
It will never Glitch an 0ffset again if you use the Format, you have just posted

So, this is on a small machine Mini-Mill or similar size Haas machine you are using??

Because that info is already here, and it can't be explained.
I tried to simplify the issue, for the simple minded.

It's a VF2-SS

And it was repeatable.

Engineer sat here dumbfounded.

Lost a day on the machine while he poked, prodded, downloaded data, talked to other engineers, scratched his balls, rubbed his eyes and finally said hmm, musta been a power surge.
We can't figure it out.

Yeah, that's why Z is repeatedy dropping .020 in the middle of a G1 feed move in X like it was spot drilling.
In the same spot.
Every time.
But only when the program is run from this folder in memory, not when it is copied elsewhere in the memory.
Must have been a power spike...

[HayreAss]

the format between the original code posted and the above would have zero effect on the issue . There is no benefit or disadvantage to having the g54 on a line of it's own . Also m6 does not turn on the spindle after a tool change , if it does then thats a problem that should be looked into

HayreAss , did the haas tech witness the issue or did he take a shot in the dark as to what may have caused the issue . I have very little faith in haas techs

Right, it would have zero effect.
That was the point I was trying to make to mactec, but he can't seem to grasp it.

And in this instance, the engineers in Oxnard and the tech got pictures, video, and the program.
This tech in particular is actually SHARP.
They asked for an error file of some sort, but unfortunately, I had already nuked the work offset table by then and resolved the problem.


When they lose him, they are screwed.

[metalmayhem]

seems unlikely that a power surge could repeat a problem like that . I'm sure somewhere in between you powered down the machine to see if that would help ? If you did then it's not going to be a power surge

[HayreAss]

seems unlikely that a power surge could repeat a problem like that . I'm sure somewhere in between you powered down the machine to see if that would help ? If you did then it's not going to be a power surge

Right?
It was like that for weeks while waiting on Haas to come take a look.
I think the program may actually still be there, but I am leaving for the weekend.

MANY power cycles, etc...
There is still no explanation for the behavior.

Kind of like this
G1 X1.0 F12. (from X0)
And somewhere around X.720, x stopped, dropped about .020, moved back up, and carried on with the X move.
No g code on the screen showing it, though the readout did show the Z move.

Copy the file to any of the other folders on the machine, and it didn't do it.
Just in that one folder.

I laughed when they went with 'power surge"

[mactec54]

the format between the original code posted and the above would have zero effect on the issue . There is no benefit or disadvantage to having the g54 on a line of it's own . Also m6 does not turn on the spindle after a tool change , if it does then thats a problem that should be looked into

HayreAss , did the haas tech witness the issue or did he take a shot in the dark as to what may have caused the issue . I have very little faith in haas techs

The M6 turns off the Spindle and the Coolant before a Tool Change so other code for this is not needed as programed by Haas

[extanker59]

mactec54 you threw me for a loop. I read what you first wrote and began feverishly looking for documentation. I thought I was missing some setting.
Then you edited.
Oh well. I learn til I die (hopefully).