Solutions for jogging and remote support.

  • Hello there,

    First time poster - hope I'm doing this correctly!

    I am currently working on a couple of solutions involving Fanuc LR Mate 200id. The way we usually provide first line support is through remote connections to our systems (that are usually situated onboard vessels or in factories all over). That way, we can monitor and investigate issues from the office. Additionally, like most other robot applications, our solutions come with a jogging option for the operators to use, in case something abnormal occurs (out of bounds etc.).
    After working with the robot, and the R-30iB controller, for a while, I'm not so sure about how to replicate the same setup for jogging and remote support that we have on existing solutions. For instance, it seems to me that the operator would have to enable the TP + set controller to T1 mode + disable UI signals in the config to achieve jogging (that is how I am currently doing it), which is too complicated for the typical operator of our systems; having the operator use the TP at all is something we would like to avoid. Instead, we want to create a simpler solution baked into a PLC HMI or some GUI. Is it feasible to create a fluent solution that allows for swapping between autorunning a program per PLC instruction and switching to manual mode to allow jogging? I was thinking about creating a second program that loops a move instruction to the current position plus some increment based on PLC input (operator jogging on HMI leads to increments in the target position), but that seems a little hacky.
    As for remote connection, I've been thinking about the Remote iPendant solution - does anyone know if it is possible to embed that into something like an Ignition GUI, for instance?

    Thanks :smiling_face:

  • Fubini

    Approved the thread.
  • Maybe it isn't possible in your situation due to complexity, but we make our robots able to home from anywhere to include places that the robot shouldn't ever be. Our homing routines can be some of the most time consuming programs to setup when the cell goes live. It's a pain, but in the end an operator can just press the home button on the HMI and get on with their day.

  • Remote ipendant is what I use for remote support. It definitely has its quirks but works. You can also do remote jog in auto thru remote ipendant but requires setup and is risky if you aren't very careful.


    I agree with the recovery routines that AlanL mentioned. I do the same.


    At the end of the day it would still be good for an on-site maintenance person to know how to jog the robot and do basic troubleshooting.

  • Maybe it isn't possible in your situation due to complexity, but we make our robots able to home from anywhere to include places that the robot shouldn't ever be. Our homing routines can be some of the most time consuming programs to setup when the cell goes live. It's a pain, but in the end an operator can just press the home button on the HMI and get on with their day.

    Thanks for the reply. We do have a homing procedure, although I am not so sure it will work in all cases as you say. For instance, on one of the applications we set up a DCS zone because the gripper is rather large, and the path between pick and place points is dynamic within a large workspace. During testing, when the gripper DCS zone interfered with the robot link DCS zones, it was impossible to start the program due to the DCS-triggered stop; without jogging the robot, the DCS collision would still be present. It was also incredibly cumbersome to manually jog the robot out of the DCS interference area, but I'm guessing there isn't a fix for that other than reducing the severity of the DCS. I wish there was a brake release button! :grinning_face_with_smiling_eyes:



    Remote ipendant is what I use for remote support. It definitely has its quirks but works. You can also do remote jog in auto thru remote ipendant but requires setup and is risky if you aren't very careful.


    I agree with the recovery routines that AlanL mentioned. I do the same.


    At the end of the day it would still be good for an on-site maintenance person to know how to jog the robot and do basic troubleshooting.

    Thanks for the reply. I do agree that a person on-site should be trained. Unfortunately, the desire for training on the customer's side of things is usually not there - traditionally, the systems used in these facilities have been very simple in terms of controls, and quite rugged and interlocked so that nothing can really go wrong (such as running pumps against closed valves, or opening chutes when the downstream components are not ready). Operating rather complex machines such as 6-DOF robots is something they have very little experience with. The operator turnover is also quite high, the operating skills are often not properly passed on to the next person. On top of that, I would prefer not to give them access to a wide-open TP that lets them configure and "tamper with" whatever they want, unless there is a user access level system - I must admit that I have not yet searched for that at all. :smiling_face:

    A quick follow-up question though. We control UOP signals from the PLC, and therefore I need to disable the "enable UI signals" config parameter every time I switch to T1/T2 in order to jog the robot. Is there a workaround, or am I doing something wrong?
    I think if it wasn't for this hindrance, the solution you're suggesting with regular jogging using the TP could be an option in combination with software-based mode selection (controller must be in a proof cabinet because of the environment it is in).

    Again, thanks to both of you for the replies!

  • Why do you need to disable UI signals? Every robot I have ever jogged had UI enabled. Seems unrelated to me unless you are doing something strange with your PLC programming.


    All the person should need to do is switch the 2 key switches and start jogging.


    I never have operators touch the TP, only maintenance. Are you saying this company has no maintenance personnel?

  • I am not sure why the signals need to be disabled, worked back when I was first encountering the issue, and I just figured it had to be that way. I will check it out in a little while and get back to you on that.

    It is not so much a company, but more like an industry that is in the process of being automated. There is still a lot of manual operation, and the same people that used to do the procedures manually are likely to be on duty when those procedures are automated. We then become their troubleshooting/maintenance/tech resource remotely, so to say. It works well for most of our systems, but I am having doubts about this one.

  • I am not sure why the signals need to be disabled, worked back when I was first encountering the issue, and I just figured it had to be that way. I will check it out in a little while and get back to you on that.

    It is not so much a company, but more like an industry that is in the process of being automated. There is still a lot of manual operation, and the same people that used to do the procedures manually are likely to be on duty when those procedures are automated. We then become their troubleshooting/maintenance/tech resource remotely, so to say. It works well for most of our systems, but I am having doubts about this one.

    Yea I'm with Hawk on this one I don't get how the robot even jogs

  • As long as you aren't dropping out the 4 UI that always needs to be on, it should have no bearing on whether you can jog or not. So the fact that you disabled it leads me to the conclusion that the PLC is turning off a UI signal that it should be keeping on.

Advertising from our partners