Drip Feeding Setup - Fanuc 20FA Makino KE-55

Hi all,

I'm working on a new-to-me Makino KE-55 with Fanuc 20FA controller (circa 1996). I've figured out how to load programs via RS232 from laptop using Cimco Edit. Due to only having I think 32kb RAM, I'm looking to run a drip feed to run bigger programs. I've tried a few configuration with no success yet, trying so far:

Fanuc settings:
#0020 =0 (I/O Channel =0)
#0100
Bit 1 = 0
#0101
Bit 0 = 1
Bit 3 = 0
Bit 7 = 1
#0102 = 0 (Use DC1 to DC4) DC1 and DC3 are Xon Xoff respectively
#0103 = 11 (9600)(Baud rate)

PC Software settings are as follows:
Handshake Method = X0n Xoff (tried hardware and software)
Data Bits = 7
Stop Bits = 2
Parity Bit = Even
Baud Rate = 9600

Beings I can load programs, I'm hoping it is something easy that I'm missing for the drip feed.

Anyone running drip feed on a Fanuc 20FA that can shed some light?

Thanks much!!

What happens when you try to drip feed? Without telling us what is going wrong it makes it tough to give advice.

I've seen a couple different results, but the one time it actually started working at the cnc, it only went a few lines, and then error code "087 Buffer Overflow".

TooHighPSI said:

I've seen a couple different results, but the one time it actually started working at the cnc, it only went a few lines, and then error code "087 Buffer Overflow".

Click to expand...

Hello TooHighPSI,
The big difference between Uploading a Program to the Control's memory and DNC (Drip Feed), is that with Uploading a program, the control is retrieving and storing the data from the Input Buffer as soon as it arrives, whereas, with DNC, the data will remain in the Buffer until its been used by the control to do as the incoming program data commands. If the command is for a long, time consuming move, then there is a far greater chance of the Input Buffer becoming full to the extent that an Xoff (Software Handshaking - DC3 - Ascii 19) is sent by the control to stop the flow of data, than when a program is simply being Uploaded to Memory.

There is a lot of fudging employed by many of the Comms Applications on offer. One such fudge is the option of setting a Dwell Period at the end of each Block. Make this Dwell long enough and with all the other ducks being in line, you can just about send a program to memory without any Handshaking.

The p/s 087 error you're getting indicates that the External Device has not responded at all, or too slowly to a DC3 character being sent by the control. Xon/Xoff control characters are interpreted by the External Device's Uart, not the program itself. Accordingly, if all settings at the Control and External Device are correct, it could be a fault with the Serial Port of the PC, or one that just isn't reacting quickly enough. One thing that sometimes helps is to modify the setting, or turn off completely the FIFO Buffer of the Serial Port being used.

If this doesn't resolve the problem, try another computer, although, just dumb luck has kicked in if that works (you may have to try a few). A better plan would be to purchase a good quality Serial Adapter for the computer.

If none of the above helps, changing to Hardware Handshaking is liable to work. Hardware Handshaking is always more reliable than Software Handshaking.

Regards,

Bill

angelw said:

.......A better plan would be to purchase a good quality Serial Adapter for the computer.

If none of the above helps, changing to Hardware Handshaking is liable to work. Hardware Handshaking is always more reliable than Software Handshaking.

Click to expand...

Solid advice.

If you are using a USB to RS232 converter it is very possible it is the culprit. I had to try 3 before finding Moxa brand unit that would work 100% of the time. I have heard good things about Keyspan but have not tried one.

Make a cable up that does hardware handshaking and switch your settings to use it.

Hey guys, thanks for the replies!!

I did end up getting it to work last night. I ended up changing two things, 1) changing baud rate from 9600 to 2400, 2) Getting the correct stop bits matching between cnc and laptop, it looks like I had one of them at one stop bit, and the other at two stop bits, so that was a dumb rookie mistake, and maybe that means I didn't have to lower the baud rate.

Thanks again!!

TooHighPSI said:

Hey guys, thanks for the replies!!

I did end up getting it to work last night. I ended up changing two things, 1) changing baud rate from 9600 to 2400, 2) Getting the correct stop bits matching between cnc and laptop, it looks like I had one of them at one stop bit, and the other at two stop bits, so that was a dumb rookie mistake, and maybe that means I didn't have to lower the baud rate.

Thanks again!!

Click to expand...

Hello TooHighPSI,
Stop Bits are actually periods of time equal to the number of Stop Bits set, at the current baud rate. Accordingly, 2 Stop bits at 9600 Baud will equal 2/9600th of a second. Having the Stop Bit settings mismatched between the two devices is more likely to result in a Framing Error, rather than a Buffer Overflow; therefore, its more likely that the change in Baud Rate to 2400 is what has helped. Given that you have experienced Buffer Overflow at 9600 Baud, I suspect that you will also get the same error with 2400 Baud, if the clearing of the Input Buffer is held up due to a long, time consuming move such as:

G01 X500.0 F250.0 (when the start point is, say X0.0)

TooHighPSI said:

Handshake Method = X0n Xoff (tried hardware and software)

Click to expand...

Rereading your first Post, I see that you have tried both Hardware and Software Handshaking. Either method will only work if the cable being used is configured correctly for the respective Handshake Method being used. In a Software Handshake Cable (Loop-back Null Modem Cable) CTS/RTS pins are bridged. In a Hardware Handshake cable, these control lines need to be crossed, end for end, that is RTS to CTS and CTS to RTS respectively. Accordingly, to use Hardware Handshaking, you need to do as Kevin suggests and "make a cable up that does hardware handshaking and switch your settings to use it".


Regards,

Bill