Controller "freezing up" while running irPickTool/irVision

  • Brand-new LR-Mate 200iD with an R30 iB Mate Plus controller, running system version 9.30199, with irPickTool and irVision doing line-tracking pick from a moving conveyor. The Vision task is triggered every Xmm of conveyor travel, with no part-detected input.


    The whole setup is running well so far, but I've come across something very strange. After running for some time, the robot will simply stop reacting to parts passing under the camera. When this happens, there are no errors, the RUN indicator is still lit, but the pendant menus become strangely unresponsive. The Function button does nothing, as do Select and Edit. Menu will bring up the menu tree, but hitting Enter on any of the sub-menus does nothing. And the menu tree stays on screen permanently, no matter how many times I hit PREV. The only way I found to get out of this condition was to power-cycle the controller. Although I did find that if I switched the robot to T1, after several seconds, the menus would start working again (but rather laggy, compared to normal response times).


    After a few occurrences of this, I initially believed that it was connected to the fact that I had the irVision Runtime opened on my computer (connected to the R30 ethernet port). I thought this because, whenever the robot "froze", the web browser page on my computer would also throw a fault.


    However, after ensuring that I did not have the irVision Runtime open (or any other irVision/irPickTool browser pages), and rebooting, I encountered the issue again, after only about 30min of runtime. My next suspect was the irVision image logging -- at the time, I had the logging active to my USB drive, and was logging all images. And with the conveyor moving at a quick pace, irVision was probably triggering 2-3 times per second.


    I shut down the logging and removed my USB drive. After that, I got 2hrs of continuous runtime without the issue recurring, so I think that may be it. But I'm still waiting for it to happen again.


    Has anyone else ever encountered any behavior like this? I can't yet rule out the possibility that this robot just has a bug somewhere. No errors appear in the logs from the times when this happened.

  • Place your Ad here!
  • I will say 4 years ago, we have the same issue. We were troubleshooting the vision at the end of the day and I guess we forgot we left the Log All on. The next day we found "your problem" I think we lost the whole morning, I end up calling Fanuc and they told me to check the Log All, and there it was . No issues after


    I tell you something, if it goes good for a couple of days, turn it on again and you see the problem coming back

    Retired but still helping

  • This isn't too related, but I've seen slow behavior like this when the PLC was hammering the robot with explicit messages every scan requesting it read a register. Unplugging the Ethernet cord stopped the slowdown, and convinced the PLC guy there was something wrong with his code.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

  • Nation, that started happening to us when I started using messaging. PLC guy ended putting a timer when reading trivial things from the robot and also reading some of them in particular robot locations


    Actually, that was my first thought when I saw SkyeFire post

    Retired but still helping

  • Yes, if you had logging enabled and a (logging path) device in the robot, that will put the robot right to it's knees.


    Fabian is also correct, explicit messaging will bog things, and lock the teach pendant up. We tie them to a "flasher" bit set up in the PLC to do a 1 second flash on indicator lights or Stacklights.

  • Yes, if you had logging enabled and a (logging path) device in the robot, that will put the robot right to it's knees.

    I have to wonder why they haven't resolved that issue. The logging data is really valuable for debugging, but if you can't collect it w/o breaking the process...

  • Well , I have already had the same problem. I my case, was the PLC sending wrong signal all the the time and the robot coulnd't do because it was in running in another program. So the TP screen was freeze. My conclusion was signal conflit . Try to check the all the signal and maybe you can find the reason.

  • Well , I have already had the same problem. I my case, was the PLC sending wrong signal all the the time and the robot coulnd't do because it was in running in another program. So the TP screen was freeze. My conclusion was signal conflit . Try to check the all the signal and maybe you can find the reason.

    My robot doesn't have any signals, though. It has an RO to open/close the gripper, but there's no other I/O set up or enabled yet.

  • Maybe the IRvision is trying to find a part all the time. Look in your program if the instruction stop after find a part .

    I dont know your process, but you have to ask your self . When the camera does not find a part , how many attempts its make until the show failure you didn't find? Are you using a instrution for stop to search after found it ?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners