Good day,
Many years ago we used to have Tralfa paint robots on which we could release the brakes and move them by hand to teach points. This doesn't seem to be a feature anymore. Was there a regulatory change that disallowed this practice? I know you can do this with collaborative robots, but are there any non-collaborative industrial robots that you can move/teach by hand without having to mount a separate teaching device on the robot?
Yup, upon closer inspection, that was it. Thanks for the help!
So I just tried this and the program call works, but the point doesn't track the line. Any thoughts on how I could make this work?
Good day,
I want to try something but just wanted to consult the experts here to see if it would work.
I have a main program which calls a bunch of line tracking programs. The line tracking programs only contain a few points but there's a bunch of other I/O assignments and register operations. I would like to encapsulate the points into another program and then call it.
So instead of:
GO[2] = 3
DO[22] = ON
R[5] = R[3] * R[4]
L P[1] 1000mm/s CNT100
L P[2] 1000mm/s CNT100
DO[22] = OFF
I would be changed to:
GO[2] = 3
DO[22] = ON
R[5] = R[3] * R[4]
CALL PROG1 //where this program would contain the move instructions for P[1] and P[2]
DO[22] = OFF
Is there any problem with doing this? If PROG1 is set for the correct tracking schedule, is there anything I need to do to make this work? Do I need something like a NOLOCKGROUP instruction?
Thanks!
Good day,
I'm stumped and hoping someone can help me understand what's going on. Here's the setup. I've got a MAIN program that's setup as a macro, initiated by a DIN from a PLC. That main program calls the actual program that does the work (call them P66, P67, P68, etc). It only runs one cycle, no looping or branching in the program. When we run MAIN, it will call and run P66, return to MAIN, then go back to the offline position as expected. However, at this point when I try to do a background edit of P66 I get 'MEMO-068 Specified program is in use'. Since the main program ran to completion, why would the robot still consider P66 as 'in use'? There's no other background logic running. I also tried FCTN + Abort All but that doesn't help. If I run MAIN again but call P67 instead, then it 'unlocks' P66 and I'm able to do background edit on it.
I looked in 'Status -> Program' and do not see P66 in there. I tried this in Roboguide but can't replicate the same problem.
What would cause a program to be 'in use' even if it completed executing? Do I need to explicitly put an 'Abort' instruction at the end of main?
Thanks,
Lei
Thank you both for your suggestions.
We did modify the way the IGS was exported and that resolved the issue.
Good day,
I'm trying to load an EOAT IGS file but getting some crazy crystalline looking artifacts.
Does anyone know what might be causing this? I'm not a CAD guy but as far as I know, these were originally Solidworks STEP files that were saved as IGS. Is there some save or export setting we need to adjust?
Thank you,
Lei
Thanks for the tip. I had a look at those items in config and all of those DO are set to 0. Now that I'm looking at it, those alarms don't show up anymore and as far as I know, nobody has changed anything. I'm looking at it remotely so who knows what's actually going on on-site ¯\_(ツ)_/¯
Good day,
I'm seeing these appear randomly on one of our R-2000iBs, but apparently it's not affecting production.
SYST-144 Bad DO specified by $GENOVRD_DO
SYST-144 Bad DO specified by $PRMPDSPOUT
Never seen these before, can't find those sys vars on the robot, and can't find any reference to them in the documentation. Does anyone know what could be causing these alarms?
Thanks,
Lei
Yup, that was it!
Thank you very much!
Good day,
Sometimes for remote support I'll grab a TP file from a robot using an FTP client (Tera Term), and load it into Roboguide on my laptop. This has worked fine in the past but recently when I try to load the TP file I get these errors.
If I get someone on-site to save the TP file to a USB drive then send it to me, it'll load in Roboguide just fine. Wondering if anyone else has encountered something like this and might know the cause and solution.
Thanks!
Thank you very much for the very detailed and helpful answer!
Good day,
Is there a setting or variable that I can change such that the contents of RD do not get cleared upon power cycle?
Thanks.
Thanks for all the suggestions.
Looks like we're going to engineer our own solution along the same lines.
For us it's not so much slippage but more like there's just too much mechanical slop from the chain all the way down to the molds. There's a distinct surging motion that the conveyor exhibits that corresponds to the pitch of the gears on the drive. The way this motion is picked up at the chain is very different from how it manifests eventually down at the mold. Maybe it could be that the oscillation in the signal just needs to be phase shifted to match what the robot sees at the mold travels across it.
We have looked at using a laser doppler to drive an encoder signal. Some success, but some challenges remain.
Thanks again for the discussion and sharing your thoughts and ideas!
Yes, we have to deal with queueing as well, which is an additional challenge.
We are also looking at ways to reduce conveyor motion variation but this has proven to be difficult.
I was thinking of how to make use of a discountinous signal and it seems like the transition from one carriage or mold to the next would be very tricky to time right. We have a high mix line with a lot of variability in robot program execution times from mold to mold. Many opportunities for getting it wrong resulting in a crash.
cking8177, SkyeFire,
Thank you both very much for your input and insights.
The line tracking solution we currently use is exactly as you mentioned; the encoder is engaged with the drive chain of the conveyor itself and there are part detect sensors that pick up each cart/mold.
This works well enough for our robots that dispense chemicals into the molds without having to make physical contact. However, we are developing a new application where we are trying to get our robots to insert components onto the moving tools, which does require physical contact at a high level of precision. The current method of driving the encoders with the conveyor is far removed removed from the molds themselves, and is not able to capture some of the more minute unsteady motion dynamics. That's why I was hoping to find a method of driving an encoder with the carts or molds themselves, while being able to deal with the gaps in the signal.
Good day,
I have an application where I need to track the motion of a set of carriages which are driven by a conveyor chain. It would be simple enough to connect the encoder to a wheel that engages with a flat surface on the carriages. The problem is that there are gaps of 6-8" between the carriages. Does anyone know of a product that provides a solution for this, to provide a continous encoder signal despite losses in engagment between the encoder and the object being tracked? We can look at engineering our own solution to this but I was hoping there's already something out there we can just purchase and deploy.
Does FANUC have any solutions for this within their line tracking software?
Thanks in advance for your help and input.
Ahh yes, forgot I could do that. Thank you!
Yup, that did the trick. Thank you very much.
Maybe I missed it but I don't remember seeing anything about that in the manual. Also, I couldn't SETIND to 0 in the frame menu as it was asking for 1-9. I had to do it through the sys var $MNUFRAMENUM.
