Major problem when sending G Code via RS 232 to Haas

[jcorrigan]

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?

I changed both the Rx and Tx down to 1.
I have not checked the wiring, but can check it today. The cables that I have are just labelled 'Null Modem'.
I've currently got a tower PC connected to the Haas. The PC has a DB9 serial output, so the conversion from 9 to 25 pin is via the cable wiring.
If I upload this 1 file into the machine it always arrives into the machine the same. The Y and J values on that specific line are incorrect, then the following 10 lines all have rogue values, some X, some Y, some J changes. I tried changing the values to whole numbers on the first wrong line and sent it to the Haas, then all of the following lines were correct. It's bizarre.

 

[magno_grail]

I use a DB9-RJ45 connector at the PC and a DB25-RJ45 at the mill with about 30 feet of CAT5 cable in between. That way I do not have to worry whether the cable is null modem and I can configure the handshake at the mill end.
What if you add another line before the line where the error starts, does it still error on that line or on the new line? Maybe that will tell you something about where the error is coming from.

 

[jcorrigan]

I use a DB9-RJ45 connector at the PC and a DB25-RJ45 at the mill with about 30 feet of CAT5 cable in between. That way I do not have to worry whether the cable is null modem and I can configure the handshake at the mill end.
What if you add another line before the line where the error starts, does it still error on that line or on the new line? Maybe that will tell you something about where the error is coming from.

One of my cables is exactly as you describe, except its cat 7 and only 6 feet long. Could you elaborate a little bit about what you mean when you say that you configure the handshake at the mill end?
I'll try and add another line of code before the error this evening and see what happens.
Thanks

Edit:
I've added a line of code before where the error starts. The new piece of code now becomes the first line that has an error.

 

[SeeFair]

In my opinion, it is very unlikely that an rs232 communication problem would result in "coherent" wrong data being sent, especially in a repeatable manner. I would expect weird characters, dropped characters, faults. I think you are looking in the wrong place. The memory chip suggestion is more plausible to me, but I really don't have a good suggestion. Dumb question: have you cycled power on the machine?

 

[dandrummerman21]

Edit:
I've added a line of code before where the error starts. The new piece of code now becomes the first line that has an error.

Yeah, totally seems memory related to me now.

Here's a thing to do for shits n giggles. Make a large file, all 1's or something.

If you need a 2mb file, take the following code:


X1111.1111Y1111.1111Z1111.1111

That's 30 bytes. Copy paste it 10 times, 300 bytes. Then copypaste that 10 times, that's 3000 bytes. Copy paste that 10 times, 30KB, paste that 10 times, 300KB, paste that 7 times and you've got a file a little over 2MB. Or however you would like to do the pasting.

Search for a number other than 1111.1111. Should confirm the machine doing something screwy (like you really need more confirmation)


Edit: changed my pasting math above, should be better now.

 

[magno_grail]

If you have programs in the machine, note the free space, subtract that from the total memory. Load the ones in as suggested by dand..21 and that should be about where you will see the errors occurring.
I can post the wiring for the different handshakes but it sounds as though it is a memory problem. Let me know.
By the way, I added RAM memory to my '91. You should be able to swap out the chips if it is a memory problem.

 

[rklopp]

On my old Deckel FP2NC if I send a file to it with even one bad character or missing return (for example, it needs exactly 5 returns after the tool table), the control freezes and crashes and has to be reset, sometimes to the point of having to open the console and pull the power jumper between circuit boards. Of course that erases all stored programs.

 

[jcorrigan]

In my opinion, it is very unlikely that an rs232 communication problem would result in "coherent" wrong data being sent, especially in a repeatable manner. I would expect weird characters, dropped characters, faults. I think you are looking in the wrong place. The memory chip suggestion is more plausible to me, but I really don't have a good suggestion. Dumb question: have you cycled power on the machine?

Yes, I power cycled when it first happened. I'm 99% convinced it's a memory chip problem now.

 

[jcorrigan]

Yeah, totally seems memory related to me now.

Here's a thing to do for shits n giggles. Make a large file, all 1's or something.

If you need a 2mb file, take the following code:


X1111.1111Y1111.1111Z1111.1111

That's 30 bytes. Copy paste it 10 times, 300 bytes. Then copypaste that 10 times, that's 3000 bytes. Copy paste that 10 times, 30KB, paste that 10 times, 300KB, paste that 7 times and you've got a file a little over 2MB. Or however you would like to do the pasting.

Search for a number other than 1111.1111. Should confirm the machine doing something screwy (like you really need more confirmation)


Edit: changed my pasting math above, should be better now.

I'll give this a try. I'm fairly sure it's a memory problem, I bit the bullet and deleted the old programs off the machine and re-sent the problem program.. It's now loaded on correctly

 

[jcorrigan]

If you have programs in the machine, note the free space, subtract that from the total memory. Load the ones in as suggested by dand..21 and that should be about where you will see the errors occurring.
I can post the wiring for the different handshakes but it sounds as though it is a memory problem. Let me know.
By the way, I added RAM memory to my '91. You should be able to swap out the chips if it is a memory problem.

I had 90% free space in the machine before deleting the old programs. I tried completely clearing out and re-sending the new program and it now transfers fine.
Thanks for the offer of the wiring diagram, seems like I won't need it now though.
I've never looked at the board before, is it as simple as replacing ram in a pc? Or is there anything to watch out for?
Thanks to everybody for the comments and suggestions btw.

 

[SeymourDumore]

In my opinion, it is very unlikely that an rs232 communication problem would result in "coherent" wrong data being sent, especially in a repeatable manner. I would expect weird characters, dropped characters, faults. I think you are looking in the wrong place. The memory chip suggestion is more plausible to me, but I really don't have a good suggestion. Dumb question: have you cycled power on the machine?

This, in red! ^^^
In a previous life, I have spent way too much time in the medical field using RS232 and 422 comms, and never saw a repeatable transmission error that was not related to a hardware/software issue, typically explainable hardware/software issue.

Is there a way for you to not use a USB to Serial adapter, rather a true serial port with a real, honest-to-god UART chip on-board?
Again, in that previous life we've used RS232 not only for simple communication, but also to send massive amounts of data, often on a BIOS level where error checking was very basic.
Back then very few USB adapters passed the reliability test, and yet, real serial ports never failed.

What is rather curious is that when sending the large file, the block of code gets corrupted, but when the same code is stripped and sent as a smaller file, it is received properly.
Something somewhere ( send side or receive side ) gets lost due to interpretation is my guess, but I kind of doubt the Haas is the culprit, certainly not the old faithful controls ( NGC is a different story ). The firmware of the USB adapter or the windows driver might be more likely.

Also, just to eliminate one more item, I've been using TeraTerm for the last 20+ years to talk to 4 different Haas controls ( one is actually 2 x 100' long cable away ), never ever a corruption that went undetected.
Here is a link, dead simple to install and use: https://ttssh2.osdn.jp/index.html.en

 

[magno_grail]

The original RAM is soldered in. You will need one of those U shaped soldering tools that heats all the pins at once. You have to keep power to the ROM at all times, either battery or power supply.
I added sockets to the row above to increase the memory.
Have you noticed if the program is correct after a certain point? Maybe block off some lower section of memory with a spacer file?