HAAS Program Restart & macros

[krausean]

Hi everyone,
I'm new here so I guess I'll start by introducing myself. My name is Andreas, I'm 30 y/o and have been machining for about 11 years. I run a 2014 VF4SS at a shop in Edmonton, Alberta, where I've been employed for about 7 years.

I'm in the process of learning macro programming and have a question regarding Haas's Program Restart function. When restarting a program past a G65 macro call, the control will read, compute and change variables/offsets etc, because it pre-reads everything before the restart point. This can cause some strange/dangerous things to happen. Is there any way to skip the macro completely? Like,"IF [PROGRAM RESTART] GOTOn"? I would prefer not to use block delete with the G65; The post I use places block deletes before all M08's in order to avoid a face-full of coolant when setting up a part. And the fact that it's possible to forget to use block delete every time I restart a program is enough to deter me from using it.

Hope that make sense!

TIA!

 

[Matt@RFR]

Why do you need to restart a program so often that it's an issue? If it's to change inserts in a tool or whatever, you need to get your process dialed in so you can put M0's wherever they are needed.

Or put /M0 in several places if you can't forsee when a program pause will need to be and turn block delete off when you need it to stop. With this, you can use setting 32 set to "ignore" for setup.

More details about your situation would help. As far as I know, there is no way to customize program restart.

 

[mkd]

Sounds like u answered your own question.
Just put said GOTO in beginning of program to jump below g65

 

[mkd]

You could have a goto for every tool change.
Might want the first goto to jump all the other gotos, to the first tool. Lol

 

[thesidetalker]

Might be helpful for a little more info on what you're doing with the macros or features you're milling.

Sounds like you might be able to do it with some GOTO's like others suggested.

Or, I think you might be on the right track with an IF statement. Maybe use a variable here and put an if statement before your G65 -
IF [#100 EQ 1] GOTO 20

and put an N20 after your G65. I think that could work? Although I've never tried it.

You could use a couple different sets of these for each G65 probably. Then if you need to restart, set program restart to on, and change your variables in current commands to skip your desired G65's.

I'm not sure if the look ahead would read into those G65s or not though. Might need to adjust the setting for that?

 

[RTM]

Have you tried setting 36? From the onboard Help:

"When it is off the program will start without checking the conditions of the machine. Having this setting off may save time when running a proven program."

With this setting off, you must be very careful where you start. With the setting "ON" the control scans the entire file reading offsets, G and M codes, etc.

Oops, see that suggestion was already put forth. I use block delete to skip the probe cycles built into the programs. I know that's not desirable to you but it was the best I came up with.

 

[krausean]

Thanks for the suggestions everyone!
Maybe I'll give you an example of a part I'm working on. I'm currently working on a program that has a macro built for timing a 6-start thread on a part to features I will be milling into the part. The tolerance on timing is +/-0.1 deg. I'm using G68 X0 Y0 R#120 (where #120 is the angle of rotation) to rotate the program. The thread is probed, math is done with several variables and I get an angle for my G68 R-value. I then go on to machine the part. The problem comes in if I have to skip the probing cycle due to having to re-run the part for one reason or another. When the machine re-reads the macro code, the calculated R-value (variable #120) changes, due to the way the macro running through all its calculations again. So, placing a block delete before an M97 Pnnn sub routine call is fine, as long as I don't forget to use block delete. The one time I do forget, my #120 variable is changed. The worst of it is that if this happens after I have machined much the part, the probing faces I had to begin with are no longer there and I'm royally screwed! The reason I thought there was a relatively simple way to do this is because the probing cycles that came with the machine are somehow able to be skipped without affecting the offsets. I've looked at the macros for these probing cycles but can't make sense of much of what's going on in them. #overmyhead lol

 

[mkd]

Well in hopes.of simplicity change the post output to remove block skips on m8. There is no need for that on a Haas. It has a coolant ignore setting.
Then obviously use block skip on ur macro

 

[krausean]

After re-reading the probing macros in my controller, I found the solution I've been looking for! It's very clever, actually!

This is at the beginning of every probing sub-program:

G103 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
#3001= 0
G04 P250
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
IF [ #3001 LT 200 ] GOTO999

Makes perfect sense and works flawlessly!

Thanks for your time everyone!

 

[ihateu3]

After re-reading the probing macros in my controller, I found the solution I've been looking for! It's very clever, actually!

This is at the beginning of every probing sub-program:

G103 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
#3001= 0
G04 P250
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
IF [ #3001 LT 200 ] GOTO999

Makes perfect sense and works flawlessly!

Thanks for your time everyone!

I also have the same dillemma as the OP. When I use program restart and it re-reads the probing routine and recalculates, it loses its probing offsets. For example, if I touch the Z face 4 times (#101=#192, #102=#192, #103=#192, #104=#192) and then average it for the Z offset, it works fine the first time through, but when program restart reads this line it no longer works since 192 has no value in it at that time, or if it retains the last value, then it is going to set 101-104 all the same number.

Anyways, can someone explain how the above code worked for the OP? When I read it, all I am seeing is that it is setting the timebase to zero, and then dwelling 256 milliseconds and then stating if #3001 is less than 200ms do a GOTO. But if you are making it dwell 256 ms it will always be more than 200ms, what am I missing here?

 

[Denim]

I also have the same dillemma as the OP. When I use program restart and it re-reads the probing routine and recalculates, it loses its probing offsets. For example, if I touch the Z face 4 times (#101=#192, #102=#192, #103=#192, #104=#192) and then average it for the Z offset, it works fine the first time through, but when program restart reads this line it no longer works since 192 has no value in it at that time, or if it retains the last value, then it is going to set 101-104 all the same number.

Anyways, can someone explain how the above code worked for the OP? When I read it, all I am seeing is that it is setting the timebase to zero, and then dwelling 256 milliseconds and then stating if #3001 is less than 200ms do a GOTO. But if you are making it dwell 256 ms it will always be more than 200ms, what am I missing here?

The dwells are not executed when the code is read by the restart function. So if #3001 is less than 200ms at the end then you know that the code is read by the restart function.

 

[ihateu3]

The dwells are not executed when the code is read by the restart function. So if #3001 is less than 200ms at the end then you know that the code is read by the restart function.

Thank you, that makes sense!

 

[Snoopy-16]

After re-reading the probing macros in my controller, I found the solution I've been looking for! It's very clever, actually!

This is at the beginning of every probing sub-program:

G103 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
#3001= 0
G04 P250
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
G04 P1
IF [ #3001 LT 200 ] GOTO999

Makes perfect sense and works flawlessly!

Thanks for your time everyone!

Hi,
I had a very similar issue to you, and after a bit of googling, I found this post. I copy/pasted it your macro dwell test (above) and it worked just as I hoped!
It has also got me out of a jam.
Can you explain to me though, why G04 P1 is called multiple times, rather than adding up the millisecond count to make one entry line?

Cheers!