VF2 will no longer take a program!

Quite suddenly our VF2 will no longer take programs over an rs232 cable. Worked fine yesterday and hundreds of times last year, today all I get is 416 rs232 parity error and 411 rs232 empty program. Baud rate 9600 data bits 7 parity even stop bits 1 handshake - hardware xon/xoff 100msec line delay first line % last line %. Using Predetor CNC Editor to send the programs. Settings match on both machine and PC. I'm the only one who uses them and no one could of changed anything overnight. I can receive from machine but can no longer send to it. Tested cable by sending program to a different machine and had no problems. Can anyone give me some ideas on what to try cause I've been at this since 5am and my next step is to take a 50# sledge to this POS machine!!!

Peroni said:

Tested cable by sending program to a different machine and had no problems.

Click to expand...

You unplugged the cable from the Haas and plugged it into another machine? Just making sure.

Do you typically unplug the cable from the machine for use on others, or do you have a switchbox?

You may need a new cable. I have to replace my cable every 2 years. It gets shorted or damaged.

Is the memory full?

Peroni:

It is hard to troubleshoot RS232 problems where HAAS fails to receive data. This is because unless what is sent is sufficiently correctly received you get little or no information.

From the information you supplied I will suggest the following:

Change your settings at both ends to no parity, 1 stop bit, 7 data bits. Change handshake to XON/XOFF. 9600 baud is probably OK.

Create a simple file

%
O0100
M30
%

Send this and see if it will load.

How long is your cable? Where are you located? Were there any electrical storms or other electrical faults that occurred overnight? What year is the VF-2? What is your ambient air temperature near the machine?

What do you mean by handshake - hardware XON/XOFF? That does not exist on any of our HAAS machines.

What machine did you use to check the cable instead of the VF-2?

That you got a parity error message means something got thru to HAAS.

(edit) Unplug the RS232 connector from the HAAS. On the HAAS connector measure the resistance from pin 7 to pin 1. Should not matter if the machine is powered or not.(end edit)

.

Thank you to everyone who posted. I did as gar suggested and set parity to none and haven't had any problems all week. Still perplexed as to why I suddenly had a problem after things worked fine for just over a year. Then again with the way this poor machine was abused by the previous owner I'm really not surprised......

Peroni:

I do not suggest that you run with no parity for normal operation.

Make sure that both your PC and VF are set at the same baud rate, 7 data bits, even parity, one stop bit, and the same handshake type. There should be no need for a 100 MS delay. That is just a waste of time unless Predator has some problem. At your 9600 baud HAAS should have absolutely no problem receiving the data with no handshake. I send a 120,000 byte test file to HAAS at 115.2 kbaud with no errors, and no time delays. If you are drip feeding handshake is mandatory, but no need for time delay. I use CimcoEdit for the sending program, or one of our own programs.

If correctly using parity causes an error, then the cause needs to be found.

.

I've had the same issues before, and noted the frustration and in every case there was some minor flaw in the file I sent to the machine, which essentially confused the conrol when it couldn't interpret the data string. Try sending a file you no will work, rather than a new file. If that works send pieces of the file youn are having problems with and I'll bet you'll isolate the issue.

This program did work fine on the machine 3 months ago, no issues at all. So I know the program is good.

Gar what is wrong with having no parity? So far I have not had any more troubles at all. I did try with parity set to odd and it worked but was very slow. I set it back to even and have all the same problems over again. The other machine I use has exact same settings as the HAAS. It still works fine with parity set to even, which leads me to believe something is wrong with the HAAS.

Peroni:

It is unlikely that you have errors generated in the circuitry from the output of the sending UART to the input of the receiving UART. This includes some integrated circuits that translate the UART output voltage level to RS232 levels, the reverse at the receiving end, the connectors at both ends and the interconnecting cable, because these are all processing only serial data.

When you tell the RS232 setup to use parity, the creation of the parity bit is done in the sending UART and checking of parity at the receiving end is done in the receiving UART. UART is short for Universial Asynchronous Receiver and Transmitter. This integrated circuit converts parallel data to serial and vice versa.

My guess is that there is a problem in correct processing of parity at the CNC end or the interpertation of the parity check.

Only single bit parity checking is used in a normal RS232 communication. This is an extra bit included in the data being sent whose 0 or 1 value is determined by the modulo 2 addition of the other bits being sent. Even parity means that the sum of all the bits including the parity bit must = 0. This same check is done at the receiving end. If it is not zero at the receiver, then there are an odd number of bits in error.

When a parity error is detected the receiving end should just stop and indicate a parity error, or mark the bad character and continue and at the end flag that one or more parity errors exist.

Why is parity error detection useful? Suppose the number 1 is transmitted, but a 1 bit error occurs that changes 1 to 5. Decimal 1 = 0001 in binary, and 5 is 0101 a 1 bit error. Your CNC will have no way of knowing that this error occurred without some error detection means. A single bit parity check is one such means. It is quite obvious why you would want to detect such an error.

I can discuss this more if need be.

.