Posts by IRockWell

    Also, if you have the other method selected, and any of the PNS bits are high, it will overwrite whatever you have in the OTHER setup as your program with a PNS.

    Make sure your PNS bits are low when the start signal comes across.

    That worked. It still bothers me. Is there an actual use case for this or is it an oversight on FANUCs part to allow PNS bits to override the "OTHER" start method?

    I recently started working for a different employer. In house controls guy. They have a view Fanuc robots which were programmed terribly (100s of lines and jmp lables all over the place).

    They were also using the PNS method to start the robot. I switched that over to "other" the only method I have ever dealt with.

    Everything works fine unless there is a fault in the line - then the robot starts PNS001, a recovery program from the original integrator. It even seems to start while another, correct, program is running. How is that possibel?

    I just started a new job for a automotive supplier. They actually have nice workcells for roboguide from their integrator, with actual cad data for the cell. However the robot changed, programs as well as the io config. (potentially more)

    Is there an easy way to update the robot in roboguide from the actual robot? Right now I am debating loading the tp files and io files or just creating a new robot from and AOA backup and hoping that I can reattach the EOAtoolS.

    Thanks a lot! Can't wait to try those out!

    If i understand 3 correctly, it would move let's say 100mm above the pick location, then set the uframe, rotate, then move down 100mm? I think that would look awesome, and cycle time should not be an issue.

    Could you elaborate on 2? I did linear algebra in college, but it's been a while and was my only d.

    Am I good if the user frame is as the same x y directions and z height as the camera calibration ie does the origin matter? What do i do with the result of the matrix multiplication?

    Also, do you have a "buy me a beer' PayPal or something? You helped me so much over the last couple of years , either with answers to my questions or even more with answers to other peoples questions that it makes me feel bad.

    I am trying to guide a r2000iC robot on a 30iB (non plus) controller with a cognex 8405 camera.

    I calibrated the camera and I am using on offset in the user frame that is at the same z height as the calibration for the camera. Works great for x and y. rotation was a little bit off a hickup until I realized that I need to have the origin of the camera pattern be at the same x and y coordinates as the tcp. Now rotation works fine as well.

    What I am worrying about is maintenance or whatever reteaching the pick location (or the vision program). We have other cognex to fanuc guidance applications which were created by an external contractor using karel. Seems like he is manipulating the user frame instead of using an offset. Is that a common practice? Is there a best practice, ideally using .tp? I am not a big fan of karel, as the .kl will get lost if it even provided.

    I am basically duplicating a line, which includes 5 robots. The robots have the exact same options. The minor revisions are slightly different.

    What's my best option to copy all programs and setting from the existing cell? Do I just do a restore of a AOA backup or should I restore an image backup? I have roboguide available if that makes a difference.

    Thanks in advance!

    In such a case I would create an AoA backup and take a closer look into the logbook file which is part of the AoA backup. If somebody made a change you will definitely find some hints within the logbook.

    Good idea, ill try that, thanks!

    Did it change to something else, or is it empty? If someone has UI17 PNS_STROBE mapped to a digital input, and toggles true, it will wipe clear your "$shell_wrk.$cust_name" and your robot will just sit there doing nothing after you send it a start signal.

    If it changed to something else, then I'd say someone is changing it.

    It was changed to something. A non-existing program btw. However, the name is similar to existing programs, just a different number suffix.

    Do you have a cold start autoexec program? It would be listed under SYSTEM > CONFIG

    No cold start autoexec program, I just checked.

    For the second time the startup program in one of my robots somehow changed. I do not remember the specifics of the first time, but today it changed after a power outage.

    Now what I do not know is whether it was truly the power outage that somehow reset the variable entry, or if some maintenance guy changed it in an ill attempt for troubleshooting.

    Any ideas?

    Thank you that helps alot!

    Does using a color camera make any difference? That's the only one I can find in stock.

    I have two robots that are using 3dl already. I need to add a GigE camera to each with higher focal length lenses to do a quality check. I successfully added a Basler acA1300-30gm that I was able to borrow from another robot and it worked flawlessly.

    Now I got a sticker shock when I got a quote from Fanuc for the acA1300-30gm cameras, I thought they would be a couple hundred dollars. I tried sourcing it from other vendors, but the lead time is very long. In addition, I found out that the camera is obsolete.

    So here are my questions:

    - can I use third party GigE cameras or do only specific ones work? Any direct replacement for the Basler acA1300-30gm?

    - if its only specific ones, would the acA1920-48gm work for all robots or only specific versions. It was specifically mentioned by a guy from Fanuc to work for this application, but I would want to make sure that it works for another robot in my plant as well.

    Thanks in advance

    I need to run an LR Mate 200Id in an environment where the ambient temperature is about 90 degrees F if no workpiece is present. If a workpiece (~275 deg) is present, other metal objects in the vicinity and at the same distance the base of the (inverted) robot will be reach a surface temperature of about 130 degrees.

    The robot has plenty of cycle time and will move with an average of lets say 500 mm/s and have a duty cycle of less than 50%. The load is 3 kg.

    Will that work or do I need to implement some sort of cooling? I have to be careful with external fans, as I am not allowed to blow it on the workpiece. Any other recommendations? Do they make some kind off cooling jackets or something similar?

    If it is not ok, what do I have to be afraid off? Will the robot stop moving if it senses it is overheating? Is that a based on a variable that I can change? (i would want to move it away from the workpiece before stopping).

    As TitusLepic explained all, I just want to say it's too complex for you for the moment if you are beginner to robots. You won't know how to make things you want to do unless you first learn RG well. There are necessary math calculations on registers that you will have to learn to use.

    I don't disagree with your statement, just curious which math calculations you're referring to?

    My issue is the following: I received a step file from our corporate office for a part for which I have to program a fairly complex part. For whatever reason our corporate engineers like to have the origin of the part way away from the actual part and they love making sure that the axis of the CAD part does not align with any physical features of the part.

    My usual work flow is to import the part as a fixture, calibrate it with how the part will be presented in the real world, add a part to the roboguide fixture, align that by hand with the fixture, and then do my cad to path. This is fairly labor intensive, Is there a better way?

    I don't really think anyone actually knows the potential problems that could occur from a minor revision upgrade, because nobody really does it (including some Fanuc techs). I've transferred files (with the exception of sysvars and some other .sv files) between major revisions without issues. I've also upgraded a multiarm ArcTool cell from 8.0 to 8.3 because of issues with coordinated motion. I never had any issues, but nobody wants to take on that liability either. This is just my opinion.

    HandlingTool manual explains that you can go between minor revisions 8.10 to 8.20 for example. I would take an image first (auto update does preform an image prior but I have heard that this has crashed on people before), then preform the auto update. Never heard of .TP's not transferring. They can be translated between any major revision or xxTool software as far as I am aware.

    That sounds somewhat reassuring, thank you!

    One thing I forgot to ask which you brought up: Worst case scenario, can restore an image backup and bring everything back to the way it was?