Hello everyone

We have a Fanuc control connected with a 486 class PC for sending g-code over to the control.
Recently I swapped out the 486 class PC with a newer and much faster Pentium class PC. Ever since then I can not transmit from the newer PC to the control, I get an rs232 communications error each time. The PC can receive just fine. I've double checked my setup and all is the same. I've tried other PC's as well with no luck either. Things work great as long as I use any old 486 class or lower PC. It seems as if a Pentium class PC is to fast for the control. I've tried slowing down the com port and that does not help either.

Does anyone have any experiences with this type of issue? If so I would sure appreciate any advice for the next best thing to try.

Regards,

Jeff Norby

What Fanuc control and what software are you using? also are you using hardware handshake or software HS?
Usually it is not a problem with pentium, although you could get hold of a Null modem cable and try that, that is if you have the Hardware HS jumpered out.
You can also try uploading using Hyperterminal (comes with windows) if the PC is windows based, if you can get a copy of Terminal that came with Win3.1 that works even better, it will also run under Later windows versions.
Al

What are you using to DNC to the machine?

Also make sure that FIFO is turned off for the port.
What is the OS (oparating system)?

If you can receive there is some thing else going on.

We have a Fanuc 6M CNC control, 1984. A hardware handshake is being used, always using the same cable that works with the 486 class PC.
We have a 1 to 1 setup..... 1 PC to 1 CNC using a program called EDI to create and send the gcode over to the control.

I've taken into consideration your previous suggestions and hope to test those ideas out.

Thanks again.

Jeff Norby

Mmm.... I thought the 6M came with a paper tape reader and had to be converted with a BTR (Behind the Tape reader) for RS232?
If you get stuck, try using a three wire cable with Rx, Tx, and Gnd and the 4-5 and 6-8-20 ( 25D pin) jumpered out at each end, none of the jumpered wires connected between ends, and enable software handshake, the 9 pin equivalent is jumper 7-8 & 6-1-4, use 4800 baud max.
Try the other programs first. One of the problems I have seen with using some software on the later PC's is some of the Transfer programs do not initialize/set up the port right away.
Al

The problem can be relationed to operating System. You have a CNC that comunicated with a older PC. This PC has got a older OS and then new PC has got a new OS, for instance: XP from microsoft. These news PC can't support some older versions of software so that causing the comunication problem. What is the description of the error in CNC? I had a such problem, the PC was has got a DOS system and the CNC has got XP system. When we tried to establish comunication then the error happened. Check if the software is suitalble to new PC.

Alex S.A

Sys Man;

Your computer speed is not the problem with the Fanuc serial errors.
Go to control panel, then system properties, hardware, device manager, ports, com1, port settings, advanced set the receive buffer to low (1) and the transmit biffer to 1/4 (6) press OK. The FIFO buffers are the problem.
This is for Windows XP. 89/ME/2K/ NT4 have a similar type of set up.

William Timm

Greg If for sure right I have seen this issue many times over with Fifo.


I have seen many people use Hyper Terminal and some were and alwas does fails and People will some were move to a more reliable DNC software.

Like what greg Has.

Hi Jeff;
Go to the Refresh Your Memory web site and download the Trial PCEditor. Also download the Manual. In the troubleshooting section the Fanuc and Serial port problems
are listed.
William Timm
This will run for 30 days free rym.com

You can also get 6M info from the cadem site http://www.cadem.com/ncnet/ncnet_dncdetails-41.htm
Also a freebee DNC program for one machine.
Al

I have a mill with a 6M-b (Burgmaster) my pc to/from cnc via rs-232 works great(3 wire software handshake) with the cadem NCNet 30 day trial software with remote call the lite/free version I tried gave me a DLL error and never ran. Make sure your parameters are set right most use #311 set DC codes 'on' stop bits to 1 or 2 and baud rate. PC is PenII233 OS is Win98se ,RS-232 uses 7-even. Cadem website has very good info on cable and settings. Try the free ver. cant hurt I never tried to get support or help with the lite as I allways wanted the ver with remote program call.

Hi Drew; The DLL error is a PC problem with a dynamic link library file. This is normaly caused by a incomplete or bad program installation.
Bill

For shops that have a PC's out in the shop used for nothing else but upload/download to thier CNC machines, (or some shops wheel one around on a dolly).
Windows is a major overkill, I have set up quite a few of my customers with one of the old DOS programs that are still around today, Telix being one, it is still shareware.
Now ver 3.51, if you use this you also need to search for the tlxmdm351.zip file to load in the same directory.
Al

The PC is TOO fast for the control. You need to see if your software has a setting to dwell after each line. I had this problem and my software (WIN-CNC) allowed for this setting. I use this on Citizen(Mitsubishi), Wasino(Fanuc) and Eurotech(Fanuc).

http://www.marucit.com/products/software/wincnc.html

you need to look for an option for charitaor delay on the send option.

050610-2025 EST USA

I find this thread somewhat confusing.

Also my comments are from a basic and generalist point of view.

First, For information on some aspects of how a UART works I would suggest that you goto www.freebsd.org/doc/en_US.ISO8859-1/articles/serial-uart/ and at least read paragraphs 1 and 1.2, also look at my thread --- stop bits, parity.

When I do a preview of this post the freebsd address is displayed incorrectly, yet when picked it gets me to the location. Use MSN.COM search if necessary, no double quotes on my search words.

By the way, a search using Google did not produce useful results in the top few (these were mostly superficial). MSN was much better and produced the freebsd location. In both cases I seached using the words, something like --- how does a uart work .

Years ago how a UART works (may have had a different name circa 1970) was described in the datasheet for the device. Today the National Semiconductor datsheet for the 16550 basically assumes you know the general operation of a UART. To get to the National datasheet use www.national.com then enter 16550 in their search box. Next select .pdf datasheet and print it out.

Repeating what I have said many times --- the destination receiver stop bit setting must be less than or equal to the source transmitter stop bit setting. In practice with standard UARTs this means both source and destination must be set to exacaty the same number of stop bits.

Unless the system designers of the computers and/or the CNCs have done a poor job, then the flow rate should be controlled by your selection of a handshake protocol, rather than slowing the character rate by lowering baud rate or some other means. You should use the maximum possible baud rate controlled by other factors than buffer overflow.

However, there may be some hardware problems in non-licensed 16550 or equivalent devices. There is some discussion in the freebsd article.

In the use of standard UARTs (today meaning National Semiconductor 16550 or other legally licensed suppliers) it is possible to use a FIFO buffer in the UART or not depending upon a setting to the UART. The UART itself does not perform the handshake funtion, although the handshake signals are transferred thru the UART. This means at the receiving end there is no way to know that the receiving FIFO is getting full (you only know there is at least one byte in the receiving FIFO), and signal the transmitter to stop sending, and furthermore that would not stop anything already in the send FIFO buffer.

Apparently Fanuc and maybe others have too small of an input buffer following the UART or other processing problems to absorb the typical 16 bytes from a full UART FIFO transmitting buffer. Thus, you must set your UARTs to no FIFO, which really means a 1 byte FIFO. Inhibiting the source FIFO has apparenetly cured overflow problems for a number of CNC shops.

If you were to lower your baud rate, or add a delay between characters simply to avoid using a handshake, or finding out how to use it, then you are unnecessarily lowering your average data transfer rate and possibly slowing your CNC machine. And you may not solve the problem, especially in a DNC application.

The way any correctly working handshake works follows:

At the destination there is some buffer which is N bytes long. Usually this will be a circular buffer mod N.

There is a put and get pointer to this buffer and the difference indicates how full is the buffer (each pointer being mod N). The designer will set some criteria of fullness where the handshake stop signal is generated. This has to take into account expected handshaking delays.

At some lesser value of fullness the start signal is generated.

Hardware handshake will be very slightly faster than software, but if the N byte buffer is sufficiently larger than the source buffer, then you can operate at maximum baud rate and the flow is modulated by the rate the destination can receive and use data rather than by some arbitrary slow sending rate.

Note: delay between characters is the same as adding stop bits.

Now I have probably added further confusion, but that is not my goal. Rather I want you to get the most production from your machines. Recently I increased a customer's machine thruput by about 2 to 1 on a HAAS VF2 machining carbon electrodes in DNC mode by a combination of things including increased baud rate.

beta-a2.com

.