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

Quote from AlanL

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!

Quote from HawkME

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.

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!

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.

Quote from Sbeve2020

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

Sorry, could you explain further? Should the robot not jog without UI signals enabled? Isn't that variable related to UOP communication only?