087 Alarm on Wasino Lathe

[Smrtman5]

Trying to download a program from a dos based program onto a Wasino lathe with a 21i-T fanuc control, but I keep getting a 087 buffer overflow alarm. I dont know what that means or how to troubleshoot it. (And i dont have the manuals)

Using:
Windows XP computer with dos based NC program
USB to 9pin to 25pin cable
bit rate: 4800
bit length:7
parity: E
stop bit: 1

i dont know much about connecting to CNC machines, so any information would be useful.

[dcoupar]

When the Fanuc buffer gets close to full, it sends out a DC code to tell the PC to pause sending. If the PC sends more than 10 characters, you'll get a "buffer overflow".

I would go into Windows Control Panel in the System - Device Manager - Hardware tab, click Device Manager and expand Ports (COM & LPT). Right click on the COM port that you are using, and click Properties. On the Port Settings tab, click on Advanced. There should be sliders for Receive Buffer and Transmit Buffer. Slide them both to the left and then check the Do Not use Fifo Buffers radio button. Click OK all the way back to the Control Panel, then you'll have to restart the PC.

[angelw]

Also look at parameter #102 to see what Input/Output device is set. Set to 0 will use DC1 to DC4 characters;these characters are used in software handshaking (Xon Xoff). If your PC software is set for Xon Xoff and the Input/Output device is set to 4 (do not use DC1 to DC4) then you will have the problem you describe. Similarly, if 0 is set at #102, your PC software needs to be set to Xon Xoff if your data cable is only configured for software handshaking. If the PC software is set to None for handshaking, the PC's Uart will ignore all control characters being sent by the machine and you will suffer Buffer Overflow. Similarly, if the cable is configured for software handshaking with the hardware pins bridged, and with the software using RTS/CTS as handshaking, the software will see the condition as always clear to send and again you will get a Buffer Overflow at the machine.

Regards,

Bill

[Smrtman5]

Got some new information on the problem.

I tried slowing down the send/receive buffer, but it didnt help.

Parameter #102 is set to 1 (cassette reader), which i dont understand. I changed it to 0 (RS 232), with no result, then changed it back to 1.

I can transfer programs out of the machine with no issues, which leads me to think the machines are communicating correctly.
I can transfer the same program out of them machine then back into it successfully, however it does give me the same 087 alarm.

The transfer always alarms out at the same point in the program. The line read "(t0505 #32 drill)" I deleted the "#" and the program stopped at "3"

There are 82,000 characters left, plenty for the new program. However, i tried deleting an existing program to make room. Still, same alarm.

At this point, i think im out of ideas.

[dcoupar]

It's not memory you're out of, it's buffer space, so don't delete any more programs.

Change #102 back to 0.

What software are you using to send/receive? How is your cable wired?

I've had problems with some USB to Serial adapters with XON/XOFF. Does your PC have a serial port you could try instead? If not, you can get a PCI serial board (SIIG makes them) to eliminate the USB-Serial adapter.

[Smrtman5]

Its working now.

The USB adapter was eliminated. And added to the beginning of the program was:
%
O1234

Parameter 102 is still at 1. I cant explain why that works.

We are uploading a .txt file, not an .nc file. Again idk why, it doesnt make sense to me. Maybe if it were an .nc file the "% O1234" wouldnt be needed? But it works.

The program is a simple dos program, i think its called usecom.exe. Looks kinda homemade.

Not sure about the cable type.

[angelw]

Originally Posted by Smrtman5 Got some new information on the problem. I tried slowing down the send/receive buffer, but it didnt help. Parameter #102 is set to 1 (cassette reader), which i dont understand. I changed it to 0 (RS 232), with no result, then changed it back to 1. I can transfer programs out of the machine with no issues, which leads me to think the machines are communicating correctly. I can transfer the same program out of them machine then back into it successfully, however it does give me the same 087 alarm. The transfer always alarms out at the same point in the program. The line read "(t0505 #32 drill)" I deleted the "#" and the program stopped at "3" There are 82,000 characters left, plenty for the new program. However, i tried deleting an existing program to make room. Still, same alarm. At this point, i think im out of ideas.

Check and set the following parameters:
#0 bit 1=1 (second right most bit)
#20 = 0
#101 bit 0=0 (right most bit) bit 7=1 (left most bit)
#102 =0
#103 =10 for 4800 baud rate

1. Your software needs to be set to match the setup on the machine side. You need to set the handshaking method to Xon Xoff, or software handshaking; depending on what term the software uses to define the handshake method.

2. If the software is set for to software (Xon Xoff) handshaking, then the cable pin out should be as follows:

Machine End-----------------------PC End
DB25 Male Connector---------------DB9 Female Connector
2----------------------------------2
3----------------------------------3
4
| bridged
5

7----------------------------------5

6
|
8 bridged
|
20

If your software does not support software handshaking (unusual), use the following cable configuration and set the software to RTS/CTS, hardware handshaking. The parameters at the machine end will work with RTS/CTS handshaking. The Xon Xoff character sent by the machine will be ignored, or you could set #102 to 4 so as not to use DC1 to DC4 characters.

Machine End-----------------------PC End
DB25 Male Connector---------------DB9 Female Connector
2----------------------------------2
3----------------------------------3
4----------------------------------8
5----------------------------------7
6----------------------------------4
7----------------------------------5
20---------------------------------6

Regards,

Bill

[dcoupar]

Fanuc doesn't care what the file extension is. It does, however have to be an ascii text file. You can open these in Notepad or any "text" editor. You can open them in Word, but be -sure that when you save them use File - Save As - File type = .txt file.

The % is not required when READing into the CNC. When PUNCHing out the program, the % will be added automatically to the start and the end of the program.

If you include the Onnnn (i.e. O1234) at the top of the program, when READing into the CNC, it will be stored as program number O1234 on the control. If there's already a program number O1234 you'll usually get an alarm (there's a parameter to select whether to issue an alarm or overwrite the existing program).

[angelw]

Originally Posted by Smrtman5 Parameter 102 is still at 1. I cant explain why that works. We are uploading a .txt file, not an .nc file. Again idk why, it doesnt make sense to me. Maybe if it were an .nc file the "% O1234" wouldnt be needed? But it works.

If #102 is set to 1 and the transfer works, you will find that #20 is set to a number other than "0". If #20 is set to "1" then the setting of #112 will be used instead of #102. If #20 is set to "2" then the setting of #122 will be used. You will find that the parameter that is associated with the setting of #20 will be set to "0"

A .nc file is a text file, the file extension makes no difference. I think the USB adapter was the reason for the problem, although having a program number at the start of a program for a Fanuc control is good practice, but omitting it would not cause a buffer overflow.

I suggest that you still check out the parameters and the cable pin out so that you have a handle on things should you have problems communicating with the machine in the future. I helps to know this stuff just for the sake of being able to supply information to someone trying to help.

Regards,

Bill

[Smrtman5]

If #102 is set to 1 and the transfer works, you will find that #20 is set to a number other than "0". If #20 is set to "1" then the setting of #112 will be used instead of #102. If #20 is set to "2" then the setting of #122 will be used. You will find that the parameter that is associated with the setting of #20 will be set to "0"

Now its obvious changing the settings for the wrong channel wont do anything.

I helps to know this stuff just for the sake of being able to supply information to someone trying to help

I quite agree.

Thanks for all the help!