What's new
What's new

Data Transfer Problem from PC to CNC (FANUC O-MD)

cuki110

Plastic
Joined
Oct 10, 2020
Hello there, please help me,
Problem is
Data Transfer Problem from PC to CNC (FANUC O-MD)

Previously the machine was fine, it could transfer NC code in DNC mode, or Transfer to memory, then one day there was a problem with the cable, the cable burned (for some reason it came out of smoke, (the DB9pin cable was burned up), here I use (DB25Pin Male connector for CNC-DB9 for PC), now I replaced all the cables with new ones, and there the problems started.
When it burned, an alarm came out as I remember alarm 100 and the control could not be pressed at all, then I searched the forum and was asked to press (DELETE KEY) while pressing power on (when the machine was turned off) the reason was to format the storage memory. And as a result the alarm is successful, and all previous programs stored in memory are erased, the alarm disappears.

well after a few days the RS232 cable came (where I bought from local store ), then I started to hook it up (without changing the previous parameters) and -as usual for me, I went to the EDIT key-> PROGRAM-> I / O-> READ and LSK started blinking then the DNC software was already OK, the transmission file runs to completion, but the LSK still blinks and the data is not stored at all on the machine.
If I stop the transmission, Alarm 86. The parameter settings in the CNC match the same in the DNC software.

But when receive data (nc code) from the CNC to the PC it can be up and running well.

here the CNC setting uses
ISO = 1 I / O = 0
Par 0002 = 00000001 (for stop bit2 in soft DNC)
Par 0552 = 10 (for 4800 baud rate)

For settings at DNC ​​(CIMCO DNC MAX)
COM PORT = COM5 (because I set it to use COM PORT 5)
BAUD RATE = 4800 (As per Par 0552 in CNC)
STOP BIT = 2 (fits in Par 0002 on CNC)
· DATA BIT = 7
· PARITY = EVEN
· PORT MODE = ASCII
FLOW CONTROL = SOFTWARE (for handshaking)

My thanks and appreciation

Dan.

Sent from my CPH1819 using Tapatalk
 
Did you ever figure out the cause of the cable burning up? Try a different PC. If it still does not work then the RS-232 receiver chip in the control is probably damaged.

Some models of older Fanuc controls used an SN75189 chip for the RS-232 receiving, but I do not recall if the 0M-D used that.
 
Also, a standard RS232 cable won't work. The pinout for an RS232 cable on a Fanuc is different than a standard cable. A store bought cable probably won't work.


RS232 Cable.jpg
 
The pic in my previous message may be wrong. The below is the correct one for no handshake communication, which is what we usually used.

RS232 No Handshake Cable.jpg
 

Attachments

  • RS232 Cable.jpg
    RS232 Cable.jpg
    90 KB · Views: 33
The pic in my previous message may be wrong. The below is the correct one for no handshake communication, which is what we usually used.

View attachment 303109

Hello LockNut,
I doubt that you use no handshaking; unless the baud rate you're using is so slow that data flow control is not required and then only for file transfer and certainly not DNC control.

The picture above is of the pin-out for a Loop Back Null Modem cable; the cable pin-out shown in your first Post is that of a Full Hardware Handshaking Null Modem cable. Both will work with a Fanuc control provided that parameters are set at the control to either use, or not, DC characters for Software, or Hardware Handshaking respectively. The comms software of the external device must match the Handshake method set at the control.

cuki110 said:
I went to the EDIT key-> PROGRAM-> I / O-> READ and LSK started blinking then the DNC software was already OK,

Hello Dan,
What do you mean by "then the DNC software was already OK"? Do you mean that you get the DNC Software ready to send and wait for the CNC control to start the transfer, or, do you mean that the program to send via the DNC Software is loaded and ready to send, but you get the CNC control ready then command send at the PC to start the transfer?


Regards,

Bill
 
then one day there was a problem with the cable, the cable burned (for some reason it came out of smoke,

Dan.

Hello Dan,
If your control had been wired by Lucas, you would have been in luck, as Lucas wiring smoke is available to replace that which may escape from time to time.:D

Lucas Smoke1.JPG

Regards,

Bill
 
Hello Dan,
If your control had been wired by Lucas, you would have been in luck, as Lucas wiring smoke is available to replace that which may escape from time to time.:D

View attachment 303241

Regards,

Bill


I agree Bill but the OP essentially only changed the cable after proper operation both ways previously. Usually, when that happens, the cable is wrong. Store bought cables are usually the full null modem cables. It has been a while but we usually made our own cables because they had to use crossover cables like I posted. They are harder to find in stores.
 
I agree Bill but the OP essentially only changed the cable after proper operation both ways previously. Usually, when that happens, the cable is wrong. Store bought cables are usually the full null modem cables. It has been a while but we usually made our own cables because they had to use crossover cables like I posted. They are harder to find in stores.

Hello LockNut,

He didn't just change the cable for the heck of it; smoke was escaping. Smoke escaping is not a good thing at any time and often more than the cable is hurt. The Uart can only sustain a dead short of voltage up to 24vdc and even that is borderline if the short is prolonged, which is normally the case when smoke escapes.

Null Modem is a generic term and refers to any cable where the Send and Receive lines are crossed. Accordingly, all Null Modem cables have the send and receive lines crossed, otherwise they're not a Null Modem Cable. There are three general types as follows:

1. No Handshaking Null Modem

2. Loop Back Null Modem where Software Hand shaking us used (Xon/Xoff)

3. Full Hardware Handshaking - where data flow is controlled by voltage change on the control lines.

The cable most available over the counter is the No Handshake Cable. Its unlikely that the OP has this cable, as a p/s 86 error would occur immediately. The OP says that if he terminates the transmission a p/s 86 error occurs. This could be due to a Full Hardware Cable being used and the DSR pin at the control is being asserted by control from the PC.


Regards,

Bill
 
Hello Dan,
If your control had been wired by Lucas, you would have been in luck, as Lucas wiring smoke is available to replace that which may escape from time to time.:D

View attachment 303241

Regards,

Bill

This bottle is hilarious, and reminds me of the time in the 80's I spent doing a ground up on a Volvo 1800 coupe with you guessed it, Lucas electrics. One part of that ground up was re-doing a bunch of the wiring. I still remember a time where smoke, and maybe even a small fire creeped out from under the dash of the daily driver I had of the same model. I think it was at a Swap Meet where I found a black t-shirt to wear with what I remember as the feeling of unwittingly being part of a group who suffered along the same lines as I. The shirt said - LUCAS - PRINCE OF DARKNESS. It's funny how even today the reputation lingers.
 
.....Smoke escaping is not a good thing at any time and often more than the cable is hurt. The Uart can only sustain a dead short of voltage up to 24vdc and even that is borderline if the short is prolonged, which is normally the case when smoke escapes.........

This is correct in my experience. Until the OP responds with some description of what burned up, I'm assuming that he has damaged hardware.

Fanuc deviates from the "standard" RS-232 pin out on the 25 pin connector by providing +24VDC on pin 25. This is used to power their proprietary I/O devices (IE: Floppy Cassette, etc.) If one gets this 24V power crossed to signal lines, then it is almost certain that some hardware damage has occurred. I've seen Fanuc hardware damage even from induced voltage created by running a comms cable too close to a fluorescent light fixture!
 
This is correct in my experience. Until the OP responds with some description of what burned up, I'm assuming that he has damaged hardware.

Fanuc deviates from the "standard" RS-232 pin out on the 25 pin connector by providing +24VDC on pin 25. This is used to power their proprietary I/O devices (IE: Floppy Cassette, etc.) If one gets this 24V power crossed to signal lines, then it is almost certain that some hardware damage has occurred. I've seen Fanuc hardware damage even from induced voltage created by running a comms cable too close to a fluorescent light fixture!

I 2nd what Vancbiker said. Back in our serial com days I first encountered a bit of smoke when I plugged the control db25 cable into a surge suppressor, that's when I found out about Fanuc's non-standard trickery.

@cuki110
If you ever get too frustrated with serial wiring you might consider a LanCNC device or similar. That will enable you to run actual CAT network cabling to your mach for transfer and DNC with an added benefit of a nice amount of storage on the device. CAT network cabling is famous for being surge resistant whereas rs232 and rs422 is really more like an antenna for all sorts of RF noise and voltage spikes.
 
Until the OP responds with some description of what burned up, I'm assuming that he has damaged hardware.

Yes, far too little information from the OP. In his Post on the 28th ultimo he wrote:

"If I stop the transmission, Alarm 86."

From his perspective this could be encouraging, as it indicates that the Control's uart may not be completely dead. However, its an unusual alarm to be raised, depending on which device was used to stop the transmission.

If the replacement cable was a No Handshake Null Modem, with pins 6,8 and 20 not bridged, a p/s 86 alarm would be raised immediately program transfer at the control was invoked. Accordingly, the OP's cable must be either a Loop-back Null Modem, or Full Hardware Handshaking Null Modem cable. If the Loop-back Null Modem, then p/s 86 would not be raised irrespective of which device was used to stop the transfer. If the latter cable, the Full Hardware Handshake Null Modem, then a p/s 86 alarm would be raised if the transfer was stopped at the external device, but not if stopped at the control. The reason for this is that control of pin 6 (DSR) at the control would be asserted by the external device. Therefore, its more likely that the replacement cable is a Hardware Handshake Null Modem and as most will setup the control for X0n/Xoff Handshaking, the OP may simply have the wrong cable, as alluded to by LockNut.

Information for setting the control to use Hardware Handshaking is omitted from most Fanuc manuals for early FS0 controls and therefore, the control is most likely set as the default to use DC characters.

The OP needs to supply a lot more information, but given his one and only Post, he may have lost interest.

Regards,

Bill
 
Last edited:








 
Back
Top