Data Transfer Problem from PC to CNC (FANUC O-MD)
Close
Login to Your Account
Results 1 to 14 of 14
  1. #1
    Join Date
    Oct 2020
    Country
    INDONESIA
    Posts
    25
    Post Thanks / Like
    Likes (Given)
    2
    Likes (Received)
    0

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

    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

  2. #2
    Join Date
    Jan 2014
    Country
    UNITED STATES
    State/Province
    Washington
    Posts
    5,426
    Post Thanks / Like
    Likes (Given)
    977
    Likes (Received)
    3012

    Default

    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.

  3. #3
    Join Date
    Jan 2007
    Country
    UNITED STATES
    State/Province
    New Jersey
    Posts
    1,137
    Post Thanks / Like
    Likes (Given)
    627
    Likes (Received)
    637

    Default

    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

  4. #4
    Join Date
    Jan 2007
    Country
    UNITED STATES
    State/Province
    New Jersey
    Posts
    1,137
    Post Thanks / Like
    Likes (Given)
    627
    Likes (Received)
    637

    Default

    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
    Attached Thumbnails Attached Thumbnails rs232-cable.jpg  

  5. #5
    Join Date
    Jun 2011
    Country
    UNITED STATES
    State/Province
    New Jersey
    Posts
    1,258
    Post Thanks / Like
    Likes (Given)
    735
    Likes (Received)
    504

    Default

    If you smoked a cable, you may want to thoroughly check inside the control pendant.

  6. Likes mjk liked this post
  7. #6
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,979
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1637

    Default

    Quote Originally Posted by LockNut View Post
    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
    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.

    Quote Originally Posted by cuki110
    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

  8. #7
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,979
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1637

    Default

    Quote Originally Posted by cuki110 View Post
    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.

    lucas-smoke1.jpg

    Regards,

    Bill

  9. Likes mjk liked this post
  10. #8
    Join Date
    Jan 2007
    Country
    UNITED STATES
    State/Province
    New Jersey
    Posts
    1,137
    Post Thanks / Like
    Likes (Given)
    627
    Likes (Received)
    637

    Default

    Quote Originally Posted by angelw View Post
    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.

    lucas-smoke1.jpg

    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.

  11. #9
    Join Date
    Sep 2002
    Location
    People's Republic
    Posts
    5,230
    Post Thanks / Like
    Likes (Given)
    620
    Likes (Received)
    3241

    Default

    I am pretty sure he would need negative earth smoke



    I would want to know why the cable smoked, as I would be suspicious of grounding errors

  12. #10
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,979
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1637

    Default

    Quote Originally Posted by LockNut View Post
    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

  13. #11
    Join Date
    Jun 2015
    Country
    UNITED STATES
    State/Province
    Minnesota
    Posts
    621
    Post Thanks / Like
    Likes (Given)
    12
    Likes (Received)
    214

    Default

    Quote Originally Posted by angelw View Post
    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.

    lucas-smoke1.jpg

    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.

  14. #12
    Join Date
    Jan 2014
    Country
    UNITED STATES
    State/Province
    Washington
    Posts
    5,426
    Post Thanks / Like
    Likes (Given)
    977
    Likes (Received)
    3012

    Default

    Quote Originally Posted by angelw View Post
    .....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!

  15. Likes Qwan liked this post
  16. #13
    Join Date
    Sep 2013
    Country
    UNITED STATES
    State/Province
    Minnesota
    Posts
    337
    Post Thanks / Like
    Likes (Given)
    126
    Likes (Received)
    79

    Default

    Quote Originally Posted by Vancbiker View Post
    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.

  17. #14
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,979
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1637

    Default

    Quote Originally Posted by Vancbiker View Post
    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 by angelw; 11-01-2020 at 06:54 AM.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •