Haas VM3 pre-NGC - random arc movements - corrupt files

[ISL33P]

2005 Haas VM3

I have done some searching on these forums with some hints but this is a little different.
Run this program 6 seperate times, and with 4 different outcomes.
Producues random arc movements damaging parts and breaking tools. Run simulations and mno hint of errors. Looked at gcode, I am no expert, and no issues compared to output toolpath from cam.
Happens regardless of USB

1st time - error in pic 1
2nd time - removed USB from machine. Run it on same part, no issues
3rd time - removed USB from machine. Run it on same part, no issues
5th time - as per pic 1 on new part but I was there watching it and catched it before it did any damage
4th time - pic 2 & 3

No changes, same program, different outcomes.

File is 1.16MB in size
Copied from USB to hard drive. Too big for memory.

 

[mhajicek]

My first guess is that you have a loose connection or other issue in the communication between where the program is being stored, and where the program is being interpreted. Maybe try re-seating boards and connectors? Look for cracked solder joints or bad capacitors?

 

[marccongdon]

I know this doesn't fix the problem but maybe try breaking the program down into two separate files at a tool change?
Does the machine run other programs just fine?
Copy the file on the hard drive now to a usb drive and compare it to the output file from the software. If there are errors in the copy they may be found here.
I'm pretty sure visual studio comes with windows or is at least free but here's a nice way of doing it.
How to compare contents of two files in Visual Studio Code? | My Tec Bits

 

[PegroProX440]

I had something similar happen to me and I had to edit my post. It was super infrequent so it took a wile to figure out what the problem was. It had something to do with the tool planes g17, g18, and g19 not updating to the next tool. So we forced a call out at the end of the line of code.

 

[friesen]

Kind of random, but you could check the power supply voltage. Also, have you tried a reboot? What about internal memory? I have had some oddities myself with USB on these machines, like it's not quite as integrated.

 

[MaxPrairie]

I had something similar happen to me and I had to edit my post. It was super infrequent so it took a wile to figure out what the problem was. It had something to do with the tool planes g17, g18, and g19 not updating to the next tool. So we forced a call out at the end of the line of code.

This would be the first thing I would look for, IJK arcs with a G18 plane called out. Do a search in your program for G17 and G18. Top safety line should have a G17 in it.

 

[ISL33P]

My first guess is that you have a loose connection or other issue in the communication between where the program is being stored, and where the program is being interpreted. Maybe try re-seating boards and connectors? Look for cracked solder joints or bad capacitors?

I will look into that, thank you.

 

[ISL33P]

I know this doesn't fix the problem but maybe try breaking the program down into two separate files at a tool change?
Does the machine run other programs just fine?
Copy the file on the hard drive now to a usb drive and compare it to the output file from the software. If there are errors in the copy they may be found here.
I'm pretty sure visual studio comes with windows or is at least free but here's a nice way of doing it.
How to compare contents of two files in Visual Studio Code? | My Tec Bits

I have considered it. But I have had the problem with both small and large files. It is very intermittent so I can't pin point any particular thing at the moment which would casue it on the program side of things.

 

[ISL33P]

This would be the first thing I would look for, IJK arcs with a G18 plane called out. Do a search in your program for G17 and G18. Top safety line should have a G17 in it.

There are no G18's in the code, only G17's and the G17's are on the same line as the I & J code both none of them correlate to the issues I have seen

 

[ISL33P]

In addition, I am currently running it in my 2004 Haas VF2 and as long as I don't jinx myself, it shouldnt have a problem. I have never seen this issue on that machine.

 

[ISL33P]

I know this may sound ridiculous, but do you think my feed rates could have anything to do with it? For whatever reason the VM3 is a lot slower than the VF2. May it have something to do with the look ahead vs the amount of code it is trying to read all while processing moves? I know they are old machines and I am very happy with the products they produce, just need to eliminate all the little gremlins.

Or maybe even the fact that I remove spaces to keep the file size as small as possible?

I know I am grasping at straws, but desperate times call for desperate measures.

I have also picked up that it may be during G2, G3 movements when changing between roughing stepover, for eg contour +3mm to contour +2mm.

Just trying to pin point it is the hard part.

 

[ISL33P]

I had something similar happen to me and I had to edit my post. It was super infrequent so it took a wile to figure out what the problem was. It had something to do with the tool planes g17, g18, and g19 not updating to the next tool. So we forced a call out at the end of the line of code.

The first pic is also the first tool called in the program, 2nd tool path.

 

[Mustang Jack]

the VM series use finer ball screws than the VF series because they mold makers they also have a more solid casting

 

[ISL33P]

Makes sense, thank you

 

[MaxPrairie]

the VM series use finer ball screws than the VF series because they mold makers they also have a more solid casting

Yes they do, I also believe the SS machines use a double start ballscrew to achieve more speed with the downfall on accuracy.