April 24, 2019, 10:12:36 PM
Robotforum | Industrial Robots Community

 Robots and TP freezing up

Author Topic:  Robots and TP freezing up  (Read 5762 times)

0 Members and 1 Guest are viewing this topic.

November 14, 2013, 01:44:00 AM
Read 5762 times

Daud

Guest
Hi. I am new to this forum and need some help with this problem. Four of our M-900iA with RJ3iB controllers and TPs will freeze at the following two occassions:

1. Auto-back up starts
2. Someone accesses the safety gate

Initially we thought its the auto back up so I have disabled that because we do manual back ups every month. The safety gate may cause all or just one robot to freeze. I am unable to look at the alarm history because TP is frozen.

The PLC (control logix) will show an I/O error on the specific robot which is frozen. We would have to recycle power to get it going. This will not happen at all safety gate entries and is very confusing. (random)

After the boot up the Alam history showed PRIO-230 Ethernet / IP Adapter Error, and then SFSPD, ENBL, HOLD, IMSTP signals to be lost. I diagnosed it to be an ethernet issue. So I did the following:

1. I ensured that the IP addresses of the Ethernet module (on PLC) and the network switch through which its communicated to robots are in the same range and submask is 255.255.255.0. This was done a week ago and the problem is still there.
 
2. This morning I added the Router IP address in all robot ethernet configurations. I saw this on another machine, that has two robots, and never gave us a problem. So I implemented it on  these as well. I am not sure if this would work so I thought of posting it here to get some feedback.


Can anyone help or share if they had the same experience?
I have basic troubleshooting training on Fanuc robots and program AB PLCs.

Thanks

Today at 10:12:36 PM
Reply #1

Advertisement

Guest

November 14, 2013, 06:26:32 AM
Reply #1
Online

scotty


About part 2 : u must add routing when u use router or communicator in your local. If local've circle from 2 robots & PC united with switch that u cannot write routing on robots or PC.
But if your stand united with factory local it can have some trouble with broadcast or other packets in lacal :((( This assumption its true if problem real in local not in ports or slot.

November 14, 2013, 12:30:41 PM
Reply #2
Offline

charliecarol


Had same issue found  sd card slot  bad replaced then ok some of the pins were smashed.

November 14, 2013, 09:37:43 PM
Reply #3

Daud

Guest
Thanks Scotty. Sorry I couldn't understand well because of me new to robot programming. Are you referring Local as the robot itself? Current the Ethernet module of the allen Bradley PLC (192.168.3.172) is connected via CAT5 to a Hirschmen Network Switch (192.168.3.190) and that switch is then connected to 4 robots (192.168.3.179, 180, 181, 182). I have assumed The Network switch (192.168.3.190) as the router and have put this address in robot configuration as shown below:

ETHERNET CONFIGURATION::

$HOSTNAME   :D_ROBOT 2
TMI_ROUTER  :ROUTER
TMI_ETHERAD :00:e0:e4:0c:99:51
Subnet mask :255.255.255.0
Host Table [17]:      QUICC0 addr:192.168.3.180
Host Table [18]:      QUICC1
Host Table [19]:      QUICC2
Host Table [20]:      ROUTER addr:192.168.3.190
Server [1]:         FTP state: 3
Server [2]:         FTP state: 3

November 14, 2013, 09:38:46 PM
Reply #4

Daud

Guest
Was that during the backup process? or even when there was nothing in the SD card slot and robots were not backing up? Thanks

December 05, 2013, 09:34:08 PM
Reply #5
Offline

DuhbCakes


Fanuc's stock response if you asked them would be to update the teach pendent firmware, and run an auto update.  the early rev's of robots always have some issues. i have noticed a lot of them on the 30iB.

February 05, 2019, 10:34:32 PM
Reply #6
Offline

Mokerjario


HI Daud do you ever find out what was the issue with the TP and Robot freezing, I am having this problem rn in one of our robots.
Fanuc's tech support recommendation was to change the main board, but I somehow think is something communication/firmware related rather than a fail in a board.

Thanks!

Today at 10:12:36 PM
Reply #7

Advertisement

Guest

February 06, 2019, 01:46:04 AM
Reply #7
Offline

Robo_Eng_13


Copy and paste from a previous response,  I will edit in the morning for clarity if needed.

"Is it connected to other devices via Ethernet? Apparently the robots are by default set to look at all Ethernet traffic, even if it is not addressed to that robot. There is a filtering setting that can be changed to correct it so the robot only cares about traffic aimed at it. We had to do this with two of our robots. They would become non-responsive, but disconnecting Ethernet and cycling power usually fixed it.

The change we made was
$ETH_FLTR[4] from 0 to 44818

Must cycle power to take effect. No guarantee this is related, especially if you do not use Ethernet."

Edit: Looking at this more closely now that i am awake, this seems like it could be your issue. Even if it is not, i have seen no reason not to go ahead and make this change regardless. It makes no sense to me why this is not the default.
« Last Edit: February 06, 2019, 02:05:52 PM by Robo_Eng_13 »

February 14, 2019, 10:14:56 AM
Reply #8
Offline

Mokerjario


 from 0 to 44818

Must cycle power to take effect. No guarantee this is related, especially if you do not use Ethernet."

Edit: Looking at this more closely now that i am awake, this seems like it could be your issue. Even if it is not, i have seen no reason not to go ahead and make this change regardless. It makes no sense to me why this is not the default.


Yes, we have Modbus tcp communication. Will try this.
Actually we have been having a lot of issues of communication lost, sometimes it come back after a few secs, sometimes we have to unplug Ethernet cables and sometimes we have to cycle power either the robot controller or the PLC.

Also, I have read that it might be due to bad TP cable, what are your thoughts on this?

Thanks a lot.


Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter