Posts by leidai5

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.

• LANG-016 Can not read file
• TPIF-218 UT1:\P99991.TP failed to load
• FILE-081 Load fail LMNEd (939,1042)

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.

Good day,

I'm trying to use the 3-point method to setup the nominal tracking frame. When I try to teach the origin point, I get a message 'User Frames not allowed during record.'. Not sure what that means and how I get past it. If anyone has any advice on this, it would be greatly appreciated.

Thanks.

Well, same problem going the other way, I'll need to go to +240° which is probably also not doable.

Is there any way to save/load just the IO comments without changing any of the configuration?

Good day,

The M-10iD/12 manual states that J1 has a maximum stroke of ±185°. I've got something where I need J1 to go as far as -240° but only at T1 speeds. Does anyone know if this is possible to do without damaging any cables or connections?

Thanks.

This would be really helpful right about now...c'mon FANUC anytime now...

Good day,

Came across a weird one and hoping someone can point me in the right direction.

We have a TP program calling a KAREL program RUNPROG. I get a report of 'INTP-222 Call program fail' pointing to the line in the TP program that calls RUNPROG. I thought that maybe someone inadvertently deleted RUNPROG but taking a look at the program select screen, it's still there. I then go into the TP program to the line 'CALL RUNPROG', cursor to the program name and scroll through the list of KAREL programs. Surprisingly, RUNPROG was not there. So for some reason, even though I could still see RUNPROG in select screen, the TP program didn't recognize it.

I then deleted RUNPROG and the associated VR file, then loaded RUNPROG.PC from a backup. This fixed the problem and we were able to resume production. In retrospect, I should have looked at a few other things like whether I could see RUNPROG.PC in MD: in the file menu, or if I could see its KAREL vars or positions. However, in the rush of the moment I did not do those things.

I'm at a loss to understand what happened. Any thoughts or ideas would be appreciated.

Thanks!

That did it...thank you for your help!