Multiple probe related alarms in Haas graphic preview

[GiroDyno]

We had been using probing routines generated by Haas WIPS which look something like G65 P9995 ABCXYZ
These turn the probe on and off each cycle. We run 5 cycles in a sequence so that wastes time. They also can't be modified directly like the Renishaw macros (like changing a Q value).
I changed all the cycles to use the Renishaw macros and the cycle will run in memory mode, but in the graphic preview it fails. And it fails at different points. And then maybe 10% of the time it runs to completion just to keep me guessing.

I tried this on two different machines (08 VF3SS and 14 VF2SS) with the same result.
I get probe startup failure and no skip in sim alarms.
I was considering adding block delete to the probe lines for the preview but that seems sketchy as the operator may not remember to turn it off when they go to run an actual part...

Has anybody else every experienced this or a similar issue?

I just ran the preview 4 times back to back and got 3 different results.
Complete cycle, startup failure alarm, complete cycle and the skip alarm.

 

[GiroDyno]

Haas response was to use block delete for any cycle with a skip function...
So I put a block delete character on every line with a probe function, but left the positioning lines so operators can still see the probe positioning moves in the program with block delete on.
To minimize the damage done when (not if) an operator forgets to turn block delete off I stuck this in the beginning of the program:

IF [#3032 EQ 0] GOTO1 (CHECK BLOCK DELETE)
M00 (BLOCK DELETE IS ON)
(BLOCK DELETE INTENDED FOR GRAPHIC PREVIEW ONLY)
(RESTART AND DEACTIVATE BLOCK DELETE BEFORE MACHINING)
N1

Hopefully this can help somebody down the line!

 

[GENERALDISARRAY]

put an m30 before N1.

that way when they hit cycle start without reading the message it will loop.

edit
i guess that wont work with your preview

 

[thesidetalker]

If you have parameter 315 bit 0 set to 0, graphics will ignore aliased M-codes. Useful for your purposes here, but not useful if you are using a toolchange macro to do something, as you will get T&H agreement alarms in graphics, unless set to 1.

If you have it set to 0....

Simply alias an M-code to a program that only turns off block delete

#3032=0
M99

Call that M-code at the start of your program. Running in graphics it will ignore your aliased M-code and block delete will stay on. Run in memory and that M-code will turn off block delete.

 

[GiroDyno]

If you have parameter 315 bit 0 set to 0, graphics will ignore aliased M-codes. Useful for your purposes here, but not useful if you are using a toolchange macro to do something, as you will get T&H agreement alarms in graphics, unless set to 1.

If you have it set to 0....

Simply alias an M-code to a program that only turns off block delete

#3032=0
M99

Call that M-code at the start of your program. Running in graphics it will ignore your aliased M-code and block delete will stay on. Run in memory and that M-code will turn off block delete.

Thats a pretty slick solution, had no idea there was a setting for that!

 

[rstpe]

You could also do this at the header of any program that you won't want graphics running on. It sets the internal millisecond timer to zero, runs a G04 dwell and checks the new content of the timer. Since the graphics runs so fast the program never actually gets to the programmed dwell amount, checking it will allow you to skip anything that would cause the graphics to fail. This works on a NGC, haven't tested on an older machine.

G103 P1
#3001=0
G4 P300
IF [ #3001 LT 200 ] GOTO1234

your program here
....

N1234
G103
M99 or M30