Results 1 to 20 of 25
Thread: RS232 to Fanuc 6T
04-26-2006, 01:52 PM #1
We have just had to replace the PC we use to create Gcode and send it to three CNC lathes.
the hard disk was fine (the power supply failed) and we have moved the hard disk to a "new" computer, as a slave.
we use GibbsCAM v4.22, and the computer is running Windows Me. the Gibbs software runs fine, creates the NCF file but we are having problems downloading some files tothe Yam CNC machine (Fanuc 6T controller).
we use a manual switch box to direct the PC to connect to each CNC as required.
the communication settings, for the YAM, are 9600/even/7 data/1.5 stop/xon-xoff/LF at end of block, BOF is blank, EOF is blank/line and chamber delay spec are both 0.
our problem is that NCF files under about 2000 bytes download successfully but larger files give a "086" alarm error.
as far as i know, the communication to the two other CNC lathes works fine (at least for the file sizes we use with them).
i have only recently joined the company and have no experience on making the settings so i would appreciate any advice on what i should do.
i think the problem must be an incompatablility between the PC communication settings and the Fanuc communication settings - but i don't know how to check the Fanuc settings.
do i need to ensure that the Windows COM port settings match the GibbsCAM communication settings or the GibbsCAM ones override the Windows ones?
04-26-2006, 02:48 PM #2
How much memory is free in the 6T? And what is the status of you flow control. Make sure that is on hardware.
04-26-2006, 03:02 PM #3
would love to give this nformation but i don't know how to find out.
i have seen the use of the DGNOS button followed by using the up and down arrow keys t scroll through the five (or six?) digit settings but they don;t seem to make much sense.
apologies for the ignorance but i'm a CNC virgin.
04-26-2006, 03:02 PM #4
060426-1426 EDT USA
I know nothing about your particular machines.
Microsoft ME is something you want to avoid, but is probably not directly your problem. XP is a much more solid program and you should upgrade to XP Pro. If you buy a hard disk or something else (somethimes some type of adapter) this will allow you to buy the OEM version of XP Pro for somewhat over $100. It is generally advisable to start with a clean hard disk, load the new operating system, and then the other programs and data. This avoids having lingering junk on the hardisk.
You did not specify your RS232 settings at both ends of the communication path. They must be exactly matched at both ends. 1.5 stop bits is not usually used.
At important point is to make sure your RS232 UART FIFO is disabled at the PC end. This you do by going to System, Hardware, Device Manager, Ports, select the COM you are using, Advanced, uncheck FIFO. You could change buffer length to minimum, but I truely have no idea what Microsaoft means by this because within the UART chip, 16550, you can only enable or disable the FIFO.
You might find some useful information at my web site www.beta-a2.com
04-26-2006, 03:08 PM #5
Are you using a USB or 232 adapter somewhere in your cabling? I ask because I had this same problem and it turned out to be the USB to 232 adapter coming off the new PC. I replaced the adapter and all was well. I still get the occassional transmit error on large files but it's always just a matter of powering down/up the adapter.
04-26-2006, 03:16 PM #6
gar and anvil,
i tried all the UART FIFO settings to no avail, and FIFO is currently turned off.
as for the adapter, we appear to have a serial cable connected to the PC -connected to a manual switch (like a parallel printer switch) which sems to work fine - except on "long" files. no USB in the communications run.
04-26-2006, 03:57 PM #7
Do you have a manual for your control? if not I have some info I could scan then E-mail to you. About a dozen or pages of everything you ever wanted to know about how to set up comms on the 6T control. I have not used for a few years but I recall it was very useful and for asome reason the info is hard to find.
Anyway, if you want the info. let me know and get it to ya.
04-26-2006, 04:07 PM #8
i can look up error 086 if you like...
we have a 6t and we send files 3,000 + bytes all the time...
i will be right back
OK IM BACK...
our hitachi cnc lathe with 6t controller does not have error 086...
must be a machine error, not controller error...
We have error 070 ( memory full )
So you probably have enough memory...
Problem is something else...
And i dont have the Hitachi manual, only the 6t manual... Darn...
04-26-2006, 04:57 PM #9
It sounds like software handshake problem, the CNC send a DC3 to halt the PC from sending, I usually use a 3 wire cable with all the hardware handshake jumpered out, this avoids alot of problems, see this site for details for the 6T/M http://www.cadem.com/ncnet/dnc-detai...1/fanuc-6t.pdf
04-26-2006, 05:09 PM #10
060426-1641 EDT USA
"the communication settings, for the YAM, are 9600/even/7 data/1.5 stop/xon-xoff/LF at end of block, BOF is blank, EOF is blank/line and chamber delay spec are both 0."
Let us assume that these are the actual settings on the YAM CNC. Also that for the present you will only send files to the CNC, then set the parameters on the PC to
9600, 7 data, EVEN, 2 Stop, XON/XOFF
The number of stop bits sent must always be greater than or equal to the number of stops bits the receiver is set to. In most equipment where sending is in both directions this means the number of stop bits must be identical.
In software handshake if only one character is used for an XOFF or XON, then one can cheat relative to this setting for the handshake signal being sent back to the sender.
The FIFO disable has to be done in Windows. The other parameters are done in Gibbs unless Gibbs provides no means to set them.
Does your sending program always stop at exactly the same point?
At the CNC pins 4 and 5 must be jumpered together, and separately 6, 8, and 20 must be jumpered together.
Your problem appears to be a handshake/buffer overflow type. As previously stated make sure there is enough room for the program you are loading.
04-26-2006, 05:20 PM #11
1. Has this machine ever worked correctly, or did it just start acting up lately. 2. How far away is your machine from the computer? Baud maybe to high if the distance is too far. Also, 1.5 stop bits does sound wrong. Lastly, make sure you haven't filled up the memory! I have gotten 86 alarms during communications because the memory was full. (on a 6T)
04-27-2006, 08:56 AM #12
the Fanuc 6T has worked fine all the time. it is the PC whose power supply failed.
the machine is approx 18ft from the PC.
i'll check to make sure we have freed up all the memory we can.
04-27-2006, 04:19 PM #13
The Fanuc 6t 086 error is an i/o error either an data switch problem or com port setting error
Check your port settings in your device manager for correct settings sometime XP overrides your commuicater settins
04-27-2006, 06:43 PM #14
You got mail.
Shows pin-outs, schematics, settings and lots of other stuff.
Hope it helps.
04-27-2006, 07:09 PM #15086 error is an i/o error
085 is error in tranmission (wrong parity/baud rate incorrect)
087 is the usual buffer overrun error(Xon/Xoff)
Check the wiring and look for faults, also dig into the windows commport settings and set them to your transmission values, just in case windows is playing silly buggers. :mad:
<Uses Win 98 for everything... much better for running DNC applications
04-27-2006, 08:50 PM #16
060427-1903 EST USA
Your reference that the YAM is set to 7 data bits and 1.5 stop bits is very unlikely if standard UARTs are used.
I pulled up the 16550 datasheet for a closer look. This also largely applies to the 16450.
The receiver is always looking for only 1 stop bit, see National datasheet for 16550 p15 bit 2. This means that the sender to this receiver should be able to use 1, 1.5, 2 or more stop bits. I believe most recent PCs have a UART based on the 16450 or 16550.
If your YAM has some sort of UART that requires a minimum input stop bit length of 1.5, highly unlikely, then you would need to send data with 2 stop bits. This would not be a 16450, 16550 type. Since you can send files up to about 2000 bytes to the YAM it means that these settings are not the problem.
The 2000 byte failure point seems to imply a buffer size and handshake problem.
Boris comment that 086 is related to DTR may mean you need pins 6, 8, 20 connected together at the Fanuc RS232, or it might imply some settings in Fanuc need to be changed. But it really doesn't make sense because the DTR signal is an output from the UART, and not an input. An output at the RS232 level from the UART and will be either + or - and greater than +3 or less than -3 Volts.
Further comments on the 16550 UART. This UART in the FIFO mode has a threshold detector of one of 1, 4, 8, or 14 bytes in the receive buffer. No such thing in the transmit buffer. If Microsoft detects an XOFF immeadiately, and the transmit buffer is full with 16 bytes, then it is not possible to stop this tranmission. The only fuction you could perform is to force empty the transmit FIFO. But, you would not know what was dumped, and therefore could not restart on an XON without data errors.
What Microsoft might be doing in their transmit buffer setting is to meter in X bytes to the FIFO, then wait until the FIFO is empty, this is detectable. When the FIFO is empty, then send another X bytes. With this technique you could keep the value of X small, like 4, and thus this would probably prevent overflowing the Fanuc input buffer of 10 bytes. The number of interrupts to Windows vs no FIFO would be somewhat reduced.
Check on what pins are connected where in the 25 pin connector to Fanuc.
04-28-2006, 05:34 PM #17
Any luck? Got an update?
05-02-2006, 05:30 PM #18
Sorry, for the delay in responding, been a little busy on other projects.
just spent an hour and founsd the following...
1. parameter 340 is 00001101 (?input device #1)
(it changed during the hour to another code which ended 10?!)
2. parameter 310 is 00000010; parameter 311 is 00111000, parameter 312 is 10000001, parameter 313 is 10110101
3. tried to run through all the variation of baud/parity/data and stop bits .....
4. can send a 109 line ncf text file (approx 1kb) with 9600/even parity/7 data/1.5 stop bits/XON_XOFF but cannot send 260 line/2kb file - we get a "085" error with the long file.
5. to confirm, we have made no changes to the Fanuc controller (as far as we are aware) since before the Windows 95 computer failed and we are "just" trying to get the Windows ME computer to talk the way the 95 one did. the serial cable is the same, through the same hardware.
6. we did a backup of the Windows 95 computer back in November (when the large file downloaded successfully), and i have checked the protocol.txt file (in the Gibbs folder) and the line entry seems to read identically (yam,6,1,0,1,0,1,1,1,0,,,,0,0).
is there a way to determine how much memory the fanuc can read? might the memory have become corrupted, beyond "109" line capacity?
many thanks for all your help, advice and patience.
05-02-2006, 05:53 PM #194. can send a 109 line ncf text file (approx 1kb) with 9600/even parity/7 data/1.5 stop bits/XON_XOFF but cannot send 260 line/2kb file - we get a "085" error with the long file.
The only settings for fanuc stop bits I've seen is a parameter choice between 1 and 2 stop bits, so maybe try 1 stop bit in your PC setting then try it,or 2 stop bits and then try the send again
05-02-2006, 06:04 PM #20
For the record, my 6M comms is even/7/2 and it works fine with a 232. I'd think that the 6T would be the same.