070718-1146 EST USA
A little over a year ago we sold several of our I232 systems to a customer.
This customer has three HAAS machines. One is a VF2 with high speed machining, but a standard spindle. The VF2 is used to machine a part from a solid block of aluminum. Total time including a number of separate setups is currently about 8 hours.
When we sold them our isolator systems they had very great difficulty in sending programs to the VF2 because these are large programs requiring DNC (drip feed). Great difficulty means the program would crash many times during a run.
The VF2 is sufficiently new as to be using vector drives. We know these vector drive machines generate a substantial amount of electrical noise.
After installing our I232 Isolators their problem was solved, and I understood that they were able to operate at 115.2 kbaud. Today it is not clear that they did operate at 115.2 kbaud, but I believe it was the case. All communication was by phone.
However, a short time after the year ago installation I was called and told that transfer failed about half way thru their program. The failure point was quite consistent, probably precisely at exactly the same program point. They sent a copy of the program and I could reproduce the problem on our machines. The problem was related to program line numbers. If you exceed a line number somewhere around 100,000, then HAAS crashes. Removing line numbers from their programs eliminated the problem. Somewhere else I believe I described this. The precise number of line numbers where this failure occurs is not clear in my mind.
At the year ago time and up until yesterday my only contact with the customer was via telephone.
About 2 months ago I received a call saying that they had communication problems. I was unfamiliar with the communication program they were using, so I suggested they try a 30 day free trial of Cimco Edit. There was no indication that our Isolators were the problem, but one never knows. However, we do have a general knowledge of the reliability of our system.
They tried Cimco Edit and it either did not work at all or did not solve the problem. I have experience of extremely high reliability with Cimco Edit for communication at 115.2 kbaud. We use it for final testing of our Isolators at 115.2 kbaud.
About this time the customer had HAAS service come in. Any information about what happened is foggy. Somewhat after this I got a call telling me that the maximum operational baud rate was 9600 without error. But above that speed there were data errors. This did not correlate with our knowledge of what to expect with the I232 System.
They were not interested in paying for a service call. I told them I would stop in sometime when I was in the area. yesterday I stopped by.
So the question is does the I232 System have some problem in itself (virtually impossible based on the error free operation at 9600), or in the interface between either the VF2 or the computer?
I know what the interface voltage levels are at the VF2, but I did not know at their computer. A check at the computer showed -9 V at rest, and 0 V with data transferring. Thus, no problem.
Their setting were:
At the computer 7 data bits, 1 stop bit, even parity, XON/XOFF, 9600 baud.
At HAAS 7 data bits, 2 stop bits, even parity, XON/XOFF, 9600 baud. Note the disparity in stop bits. Later I proved this was not the problem.
The HAAS memory size is 1 megabyte. I changed the HAAS stop bits to 1. Then, ran a send test to HAAS memory (not drip mode) at 115.2 kbaud. This loaded error free. The file size was 1.4 megabytes, and used 95% of HAAS memory after loading. Note there is compression on loading a file. Probably because values are stored as binary in HAAS memory vs ASCII decimal in the RS232 data stream, however, this is a function of internal word size. And the reduction of commands to a simpler storage. For example G codes might be stored in 8 bits internally, but use 32 bits in the input stream (three 8 bit characters plus space).
Reloaded a copy of Cimco Edit and it provided successful transfer at 115.2 kbaud.
Next I changed HAAS back to 2 stop bits. No problem. This means in receive mode the UART in HAAS does not require 2 stops and will work with only 1 stop bit in received even though you have programmed HAAS for 2 stop bits.
Note: the above tests were a direct loading to HAAS memory and not during drip feeding. No indication of the previously described error problem above 9600 baud. The errors they had were corruption of data in HAAS and no errors in the source file in the computer.
To save time because they needed to make parts I disabled FIFO at at the computer. This is done in Device Manager. This is because it could be a problem in drip mode, but i have not tested for this.
Next I had them use Cimco at 115.2 kbaud and drip feed to the machine and make a part. I went to a long lunch. An hour and a half later I went back to the plant and the machine was still running, by now all the the program had transferred into HAAS memory and there were no transfer errors. Note: once transfer is complete you can use the computer again. You might be able to before transfer is done, but this will probably slow down data transfer because of timesharing.
More information:
Anytime they were having problems with corrupted data there was never a time when there was a parity error. This means there were no errors in the communication channel including the UARTS at both ends. The problems were inside either the computer or the CNC excluding the UARTs. There has to be a parity error if data is corrupted between the sending UART and the receiving UART. There are rare cases where this is not correct, but extremely rare. In both HAAS and the computer the parity is generated in and checked in the respective UARTs. In an Okuma I believe the parity check is done after the UART.
When HAAS came in about 2 months ago they reloaded something in the HAAS machine. Whether, high baud rate and/or Cimco was tried after this is unknown. Was the problem causing data errors in the HAAS I do not know, but I suspect this was the error location.
Why is using a parity check useful? Suppose I send the ASCII character numeral 2 which is 32h or 00110010b and there is a 1 bit error such that the binary value becomes 00110110b or 36h or 6 decimal, and the number is in the inch position, then the commanded move is 6 inches instead of 2. With parity check enabled this will be detected and the program can not be executed.
.