Major problem when sending G Code via RS 232 to Haas

[jcorrigan]

I am having major problem with data transfer from a pc to our Haas VF3. In some instances. the G-code that arrives into the machine memory is different to what is being sent from the PC. This is a big problem because it can cause the table to suddenly move to an unspecified point while taking a cut. This has happened a handful of times but I need to get to the bottom of it now.

Some information on our setup:
1999 Haas VF-3
Data being sent from a Windows 10 Laptop via USB to RS-232 converter, cable length is less than 6 feet. I've tried changing the converter, the cable, and even tried changing to a PC with direct RS-232 output to remove the adapter, none of which corrects the problem.
I get the same error when I delete the code from memory and re-send the code.
Data transfer is via XModem at 38400 Baud Rate. I've tried reducing to 4800 Baud with no difference. Also tried XOn/XOff instead of XModem, again no difference.
The file that I'm sending is around 2.4Mb in size.

There looks to be around 10 lines of code that has all changed. An example of the code.
Original sent code:
N17325 X-113.842 Y-78.813 I21.773 J43.609
Incorrect code that arrives in the memory:
N17325 X-113.842 Y-4273.117 I21.773 J43.545

Luckily the machine errors out for an over travel of Y-4273, but if the code changed to something else within range of travels it would be a disaster.
Strangely, if I change the value of the Y in the code before sending from Y-78.813 to Y-79.0 then the code sends without a problem.

I can't imagine this is a common problem because I can't find any information online at all.
Has anybody got and ideas what could be causing this? It has made my confidence in sending code very low and running the risk of a bad crash now.

 

[Milland]

Two "shot in the dark" suggestions:

1) If the second computer also had W10 on it, can you load W7 Pro and use that OS instead?
2) Search for a dedicated RD232 transfer utility (or multiple) and try them to check for errors. Simulate the paths on the mill to see if they execute correctly, and do multiple transfers/checks to confirm no faults.

If you find a working combo of OS/Xfer, let us know.

 

[tc227]

I am having major problem with data transfer from a pc to our Haas VF3. In some instances. the G-code that arrives into the machine memory is different to what is being sent from the PC. This is a big problem because it can cause the table to suddenly move to an unspecified point while taking a cut. This has happened a handful of times but I need to get to the bottom of it now.

Some information on our setup:
1999 Haas VF-3
Data being sent from a Windows 10 Laptop via USB to RS-232 converter, cable length is less than 6 feet. I've tried changing the converter, the cable, and even tried changing to a PC with direct RS-232 output to remove the adapter, none of which corrects the problem.
I get the same error when I delete the code from memory and re-send the code.
Data transfer is via XModem at 38400 Baud Rate. I've tried reducing to 4800 Baud with no difference. Also tried XOn/XOff instead of XModem, again no difference.
The file that I'm sending is around 2.4Mb in size.

There looks to be around 10 lines of code that has all changed. An example of the code.
Original sent code:
N17325 X-113.842 Y-78.813 I21.773 J43.609
Incorrect code that arrives in the memory:
N17325 X-113.842 Y-4273.117 I21.773 J43.545

Luckily the machine errors out for an over travel of Y-4273, but if the code changed to something else within range of travels it would be a disaster.
Strangely, if I change the value of the Y in the code before sending from Y-78.813 to Y-79.0 then the code sends without a problem.

I can't imagine this is a common problem because I can't find any information online at all.
Has anybody got and ideas what could be causing this? It has made my confidence in sending code very low and running the risk of a bad crash now.

You using a good shielded cable?
The AC servo motor machines are a lot noisier than the good old DC machines.
What are you using for communications software?

 

[jcorrigan]

Two "shot in the dark" suggestions:

1) If the second computer also had W10 on it, can you load W7 Pro and use that OS instead?
2) Search for a dedicated RD232 transfer utility (or multiple) and try them to check for errors. Simulate the paths on the mill to see if they execute correctly, and do multiple transfers/checks to confirm no faults.

If you find a working combo of OS/Xfer, let us know.

Thanks for the reply.
The Laptop is W7 Pro, and the desktop is W10 Pro already.
I'll try and take a look for a utility for error checking and feed back if I find anything wrong.

Thanks,
JC

 

[jcorrigan]

You using a good shielded cable?
The AC servo motor machines are a lot noisier than the good old DC machines.
What are you using for communications software?

Hi, the cable is A Belden 8723 'Equivalent' shielded cable. I've tried 3 cables now.
I use DNC4U and have also tried KwikDNC on the software side of things.
I find it strange that using XModem protocol that the Haas does not see an error in the checksum when receiving data.

Thanks,
JC

 

[magno_grail]

On the PC with RS232 output, try changing the output buffer to 1. On my '91 machine the input buffer is not big enough and the machine not fast enough to tell the PC to stop sending when the buffer gets full.
If that works then see if you can change the output buffer on the USB-RS232 converter to 1.

 

[dandrummerman21]

I'm curious. You say it doesn't happen if you change the value of Y. But if you send the same code from pc to cnc over and over again, do the same ~10 lines all convert to wrong values?

If it does change the same values over and over again, then I have something to try.

If you delete some other programs from machine memory, does it still happen? I assume you might have a few programs in memory that you could take out.

I have no experience with haas, but I've had a fanuc 0m control with bad memory issues. Not exactly what you have going on, but when the memory in said machine would get to a certain threshold (like 75% memory usage), any code after a certain point would get input into program O0000, which the machine wouldn't let you delete unless you deleted some other programs. So sending program o1234 would result in 2 programs, with 1234 being incomplete and 0000 with most of the rest of the code. Some code would drop.

Basically wondering if your memory is failing.

 

[jcorrigan]

On the PC with RS232 output, try changing the output buffer to 1. On my '91 machine the input buffer is not big enough and the machine not fast enough to tell the PC to stop sending when the buffer gets full.
If that works then see if you can change the output buffer on the USB-RS232 converter to 1.

I changed the buffer to 1 (down from 14). It still sends the same incorrect code unfortunately.

 

[jcorrigan]

I'm curious. You say it doesn't happen if you change the value of Y. But if you send the same code from pc to cnc over and over again, do the same ~10 lines all convert to wrong values?

If it does change the same values over and over again, then I have something to try.

If you delete some other programs from machine memory, does it still happen? I assume you might have a few programs in memory that you could take out.

I have no experience with haas, but I've had a fanuc 0m control with bad memory issues. Not exactly what you have going on, but when the memory in said machine would get to a certain threshold (like 75% memory usage), any code after a certain point would get input into program O0000, which the machine wouldn't let you delete unless you deleted some other programs. So sending program o1234 would result in 2 programs, with 1234 being incomplete and 0000 with most of the rest of the code. Some code would drop.

Basically wondering if your memory is failing.

When I send the code it changes the same 10ish lines to the same wrong values almost every time. I've probably tried sending the code 15 times so far, each time changing something, hoping that it would solve the problem. Only on 1 of the 15 attempts it changed the X value to a -4000ish value as well as the Y value.

The machine has a 16Mb memory, and there is only 1 other file on there at the moment (Which is around 2Mb), so still plenty of memory space left. I am a little reluctant to delete that file from the memory because I need to run a few more jobs from that code and am worried that it may start giving the error if I try and reload it on again after deleting.

Something that might back up your theory; I took the rogue file and cut it down to around 150 lines, ie 70ish lines before the first error line, and 70ish lines after the last known error line, and saved that as a new file. I sent it to the Haas and it all arrived correctly, no errors that I can see.

Thanks,
John

 

[gustafson]

I know nuthin bout this control, but
slower baud rate?
Is it possible the post is throwing some control characters in those lines that the control cannot accept?
sometimes you can see those if you setup notepad right
just reaching, but maybe use a different post that that is broadly compatible and see if it still errors [not saying to use the program]

 

[Scottl]

Basically RS-232 sucks, and some hardware configurations are notorious for errors.

However, the fact that the shorter file arrives ok makes me suspect buffer overrun, bad chip in a memory bank or similar issues in your machine.

I agree with gustafson that a slower baud rate may work better. Older equipment can be very finicky with large files and higher transfer rates.

Just as food for thought, we once had data transfer issues (it would run to a point and then stop transferring) with an older industrial controller that only worked with certain PCs no matter what we tried. Eventually we determined that only PCs with a certain chipset would work because the person who wrote the program apparently fiddled with it until it worked with the PC they were using and never tested it with others.

 

[rklopp]

I cannot transmit RS232 faster than 2400 baud on my old 1986-vintage Deckel FP2NC without getting errors.

 

[gustafson]

Basically RS-232 sucks, and some hardware configurations are notorious for errors.

Eventually we determined that only PCs with a certain chipset would work because the person who wrote the program apparently fiddled with it until it worked with the PC they were using and never tested it with others.

having worked adjacent to the team doing early PC add on cards, I can attest to this, the actual procedure was to drag the card to different pcs around the building and see if it worked. True story

 

[tc227]

I am having major problem with data transfer from a pc to our Haas VF3. In some instances. the G-code that arrives into the machine memory is different to what is being sent from the PC. This is a big problem because it can cause the table to suddenly move to an unspecified point while taking a cut. This has happened a handful of times but I need to get to the bottom of it now.

Some information on our setup:
1999 Haas VF-3
Data being sent from a Windows 10 Laptop via USB to RS-232 converter, cable length is less than 6 feet. I've tried changing the converter, the cable, and even tried changing to a PC with direct RS-232 output to remove the adapter, none of which corrects the problem.
I get the same error when I delete the code from memory and re-send the code.
Data transfer is via XModem at 38400 Baud Rate. I've tried reducing to 4800 Baud with no difference. Also tried XOn/XOff instead of XModem, again no difference.
The file that I'm sending is around 2.4Mb in size.

There looks to be around 10 lines of code that has all changed. An example of the code.
Original sent code:
N17325 X-113.842 Y-78.813 I21.773 J43.609
Incorrect code that arrives in the memory:
N17325 X-113.842 Y-4273.117 I21.773 J43.545

Luckily the machine errors out for an over travel of Y-4273, but if the code changed to something else within range of travels it would be a disaster.
Strangely, if I change the value of the Y in the code before sending from Y-78.813 to Y-79.0 then the code sends without a problem.

I can't imagine this is a common problem because I can't find any information online at all.
Has anybody got and ideas what could be causing this? It has made my confidence in sending code very low and running the risk of a bad crash now.

Maybe it's time to look at a 3.5 floppy drive conversion to usb stick.
My 2002 TM-1 had no floppy disk but behind the screen there was a plug to put in a 3.5 floppy disk in (you might have this cable and plug).
Their are lots of HAAS's out there where I think for a couple of hundred dollars you could add this on and have gigs of memory.
In the good old day's they called them BTR boards.

 

[Tyler337]

Maybe it's time to look at a 3.5 floppy drive conversion to usb stick.
My 2002 TM-1 had no floppy disk but behind the screen there was a plug to put in a 3.5 floppy disk in (you might have this cable and plug).
Their are lots of HAAS's out there where I think for a couple of hundred dollars you could add this on and have gigs of memory.
In the good old day's they called them BTR boards.

Sry to ask this here but I’ve been searching for answers for about a month. I run a 550m slant nexus matrix Mazak and I’m all out of ideas to figure out why my tail stock will not rapid towards my work piece when I have it taught and programmed. It just feeds towards the part really slow when it reads the m31. It doesn’t register the m741.

 

[Vancbiker]

Why on earth are you asking a Mazak question in a Haas thread???????

 

[magno_grail]

I plugged in an Airlink 101 USB-RS232 converter to my Windoz 7 PC. Looking at the advanced settings, the transmit port it goes from 1 to16. The receive port goes from 1 to 14. Maybe you changed the Rx instead of Tx?
Can you wire the RS232 side for hardware handshake (RTS/CTS)? It is the most reliable.
Presume you have a 9 pin to 25 pin converter to plug into the Haas. Have you checked the wiring in it? The wiring is different for no handshake, partial handshake and full handshake.
I notice the J value also changed from 43.609 to 43.545. Are the changed values always the same? Are they the same if another line of code is added before that line?

 

[jcorrigan]

I know nuthin bout this control, but
slower baud rate?
Is it possible the post is throwing some control characters in those lines that the control cannot accept?
sometimes you can see those if you setup notepad right
just reaching, but maybe use a different post that that is broadly compatible and see if it still errors [not saying to use the program]

Hi, I've tried lowering the Baud rate down as far as 2400 but it does not make a difference for the transfer unfortunately.
I only have one post processor so can't post from a different source.
I don't think it's a character problem because if I shorten the program the rogue lines of code transfer okay.

 

[jcorrigan]

Basically RS-232 sucks, and some hardware configurations are notorious for errors.

However, the fact that the shorter file arrives ok makes me suspect buffer overrun, bad chip in a memory bank or similar issues in your machine.

I agree with gustafson that a slower baud rate may work better. Older equipment can be very finicky with large files and higher transfer rates.

Just as food for thought, we once had data transfer issues (it would run to a point and then stop transferring) with an older industrial controller that only worked with certain PCs no matter what we tried. Eventually we determined that only PCs with a certain chipset would work because the person who wrote the program apparently fiddled with it until it worked with the PC they were using and never tested it with others.

I'm leaning towards a bad chip in the memory.
I've found an ex Haas tech who is looking into this for me, if we get to the bottom of it I'll write up the results here.
Thanks

 

[jcorrigan]

Maybe it's time to look at a 3.5 floppy drive conversion to usb stick.
My 2002 TM-1 had no floppy disk but behind the screen there was a plug to put in a 3.5 floppy disk in (you might have this cable and plug).
Their are lots of HAAS's out there where I think for a couple of hundred dollars you could add this on and have gigs of memory.
In the good old day's they called them BTR boards.

This could be an option. The setup that I have now was working well until these hiccups. I do the cam programming in an office and post the file into a cloud storage location, I have an older laptop right beside the Haas that has access to the cloud storage, which then sends via rs232 to the machine. I guess adding to a USB and going back and forwards isn't too bad of compromise if it fixes my problems.
Thanks