We have a VF2 with ver.13.11 software. The part we are trying to run will run complete in graphics but stops at a certain point when milling the part. Has anyone experienced this? TIA

The best thing you can do is post a "small" section of the program that covers the area where the machine stops. From that information likely someone will be able to help you.

Best regards,
Sean

Thanx for replying. I don't think the program is the problem. This is a ProE part that was ran through ProManufacturing. We are suspecting it has to do with bad memory.

i have had a similar problem on an older machine. I had to repost the file and then re-send to the machine. It turns out that the data was corupted somehow (maybe when transfered to floppy) the program looked perfect and the code was good, but the program would still hang at the same point every time.

hope that helps.

On my vf3 there is a limit to how many sequence numbers you can have in your lines of code. I could run for a while andd the mill would stop at the same point every time. When I removed sequence numbers and just had g code in there ir would cut forever with any size file and would not stop any more. Hope this helps. Dave

we aren't using sequence numbers so doubtful that is the problem. Strange thing is that the program runs fine in graphics. We're leaning more towards corrupted memory.

we aren't using sequence numbers so doubtful that is the problem. Strange thing is that the program runs fine in graphics. We're leaning more towards corrupted memory.

Questions:
1. Has this program ever made parts before?
2. What type of milling is active when the machine bombs (i.e. dia comp on? 3D point to point? 2D PointA to PointB cut)?
3. Is the program stopping in the same spot everytime?


Suggestions:
1. Repost, resend, re-run.
2. Try running a similar but different program of larger size. This should determine if it's program or machine.

Best regards,
Sean

050721-0935 EST USA

donj1:

I doubt that you have a main memory problem where the program is stored because the program executes from this same area whether to the graphics display or the machine.

There are several good questions already posted to you.

Not that this applies to your problem, but HAAS has problems with comments. For example you can not put the % character in a comment. This is very poor software design. Anything should be allowed in a comment, including the ending delimiter.

Taking a subsection of the program where the problem occurs and loading that alone is a very useful suggestion.

If the program always fails at exactly the same point, then add some additional code ahead of the failure point and see if the failure moves, or delete code before the failure point. If the failure point does not move, then it is not a main memory problem.

If you have the capability to compare files at your computer, or some other computer ( we have an old DOS program called CDIFF that shows any differences in files ), then send the program from HAAS back to the computer for comparison. The files should be identical except for very minor differences at the beginning and ending %s. Also if you have IBM DEBUG capability then look at the HEX and ASCII data in the the area of the failure. Basically look for unwanted non-printing characters.

There are Windows programs available that do file comparisons and will display non-printing characters.

Another trick is to remove code in the area of the problem and see if the program will complete.

At one time I may have encountered a similar problem, but not necessarily that it worked in graphics. I do not remember the details, but was probably from a non-printing character.

.

Does the machine give an alarm, or just pause, sitting there running or what?

I've had a the exact problem. Let me guess, no alarm and machine status says running, but the machine has stopped axis motion. The code looks good and ran fine in graphics. I ran the identical program on another machine and the program stalled out in exactly the same spot in the program. I believe this to be some sort of software math bug which forsure effects M13.09N and up. I have the applications guys at Haas looking at it. I'll post what I find out.

I do recall situations when using tool radius compensation, where the lead in or lead out to the profile seemed to cause the Haas to hesitate for a couple of seconds before it would continue. I did not investigate thoroughly, but skipped the problem by modifying the lead in / lead out, so as to allow more "room" for the comp offset to occur.

Of course, I've had outright alarms that are caught in graphics mode indicating tool comp interference. But, I don't really understand why the control would pause as if the move were "almost illegal".

On a Super Mini Mill with version 13 something ( do not remember which and have had the machine reprogrammed with a later release) I had a program stop running in a similar manner because I had not cancelled Tool Comp before starting a G82 canned cycle. No alarms, no axis motion just the spindle running. The same machine also had a bug related to block deletes in a program. Trying to do a restart with Setting 36 Program Restart turned on had the machine run through to the start point and get everything correct but it did not change to the correct tool. Version 13.... had (has) bugs in various forms. A VF2 with version 13 something (another reload) had a G70 bug which took the tool back to the center after the final hole WITHOUT retracting the Z clear.

050723-1631 EST USA

donj1:

It is very important to know if the program fails at exactly the same point if you remove part of the program preceeding the failure point.

Can you run this experiment?

.

The code fragment where the machine froze up is as follows:

N5661 X16.6424Y12.3676
N5662 X16.6437Y12.3679
N5663 X16.6761Y12.3755
N5664 G3X16.6784Y12.3791I-.0006J.0029
N5665 G1X16.6782Y12.3801
N5666 G0Z.1
N5667 X17.0729
N5668 Z-.2124
N5669 G1Z-.3324F10.
N5670 X17.0727Y12.3791F30.
N5671 G3X17.0749Y12.3755I.0029J-.0007

The program would consistanty stop at line N5665. If you to remove the N5665 line from the program, the program would run properly with no stop in motion. I got an email from Haas on Fri. that they are still testing the problem.

As for the problems Geof mentioned: The potential crash using G70 only occured between M12.09 and M13.02. Using the wrong tool when performing a program restart with block deletes has been fixed from M13.08 and up.

just to point something that someone else mentioned out.

You said you werent using line numbers and here they are?????

is this just for our benefit?

you should at least try it with no line numbers

I never said anything about not using line numbers. The origional program that the problem occured in had line numbers.
Of corse, when I was troubleshooting the problem I removed the line numbers, but it made no differance. Haas has tested this in serveral different software versions and processor configurations, and found the bug occurs in some software versions but not in others. Its been submitted to the programming dept. and will be looked at to be fixed for the next version.

I've had a similar issue with my '04 vf2ss - was machining an outside radius curve say r=1" with a .375 endmill, the coolant shut off, the alarm light came on and the feed kept moving right along. I caught it (was on a finish pass) The error message said I was trying to cut too tight an inside radius (like a .125") with the .375 mill. reset the program and ran that toolpath again - same issue - rebooted the mill, problem was gone. It sounds like memory corruption to me - makes me wonder what kind of ram/flash is used and what the physical layout of the controller board looks like, but thats the EE in me...