VF2 keeps stopping

[donj1]

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

[MR_NC]

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

[donj1]

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.

[miljnor]

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.

[lapuser]

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

[donj1]

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.

[MR_NC]

Originally Posted by donj1 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

[gar]

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.

.

[HuFlungDung]

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

[jwarren]

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.

[HuFlungDung]

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".

[Geof]

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.