If it moved in the wrong direction, then your Tool is set up with a different coordinate system than normal, or your PR was in Joint instead of Cartesian. Switch your Jog Frame to TOOL, and see which direction is away from your part. Alternatively, if your part is square to your world, use a regular Offset instead of Tool. Our parts are cylindrical, we always need to use ToolOffsets.
Posts by Robo_Eng_13
-
-
I... Am not sure exactly what you need.
To set up a PR
Press the Data button on the teach pendant
Press the softkey for Type (F1, i believe) and select position registers
Choose which PR you want to use
Navigate to the PR and choose Position Softkey to view the numeric values of the PR
Change all of the values except for Z to 0
Change Z to the number of millimeters you would like to move away from the part.
Make sure your representation is in Cartesian, not Joint.To add an offset to a position
Navigate to the desired line of the program, then move over to the blank space at the end of the line.
Press the soft key for Choice, and select the OffsetTool or ToolOffset option, or something to that effect, same as a normal offset
Add your PR for your Z offset -
1. Why can you not use PR Offset?
2. Is the value changing regularly and needs to update on the fly, or can it be a static value?
-
We usually have a PR register reserved for Z offsets that we usually use for Tool Offsets to move directly away from the part.
Set up a PR[] with only a Z value
L PR[1] 100mm/s ToolOffset PR[2]
L PR[1] 100mm/s
L PR[1] 100mm/s ToolOffset PR[2]That would come to an approach point directly out from the part, come in to touch, then straight back out. Touching up PR[1] representing your touch point would then change your approach and retreat identically.
-
1. If your custom config file does not address any of the default password levels, then they will remain unchanged. If you use wildcards, they WILL effect the defaults as well as those mentioned specifically.
2. No, not really. There are ways to get pretty good lists, but nothing 100% complete that i have found. I have a pretty extensive list, but i know i am still missing some things. I had found some instruction that said to enter the browser page of the robot and you could then get the Screen ID and Soft Part ID for different things.
3. There are a few, but not many, and as far as i know STEP and HOLD are not included.
4. I usually start each new level by defining it to be identical to operator or install, then add or subtract privilages as needed. But in general, you do have to define access to every screen and menu individually for each level.
-
If you use offsets like this:
L P[1] 100mm/s OFFSET PR[1]
Then the offset is applied to that point for that move only.
If you use offsets like this:
PR[1,1] = PR[1,1] + 200
L PR[1] 100mm/sThen the offset is permanently applied to that position. It does not automatically revert back to the original values when you restart the program.
-
I believe you would usually use Touch Skip to detect your condition, then jump to a line that records your current position like
PR[1] = LPOS
That way, you now have a position register with your actual position instead of your original intended position. Then you can modify and act based on that.
-
L P[1] 100mm/s
This command will move the robot along a linear path at approximately 100 milimeters per second, to the cartesian position (X, Y, Z, w, p, r) stored in P[1]
Lets say i have a PR[1] in Cartesian mode with values like such (50, 50, 100, 0, 0, 0)
Lets make P[1] be (750, 40, 325, 0, 0, 0)If we change our command to
L P[1] 100mm/s OFFSET PR[1]
then now we will move to the sum of the original point and the offset point (800, 90, 425, 0, 0, 0)
Not to be confused with a ToolOffset, where the direction the offsets are applied in are in the orientation of the tool.
Does this help?
-
From what you have said, i see two main options.
1. Have a main program that detects the part in work and selects a sub program based on that. For this, you can copy the original program with the first 16 points in to five more identical programs, then touch up the points in each sub program. This is the "easiest" in that it has the least advanced techniques, and is easiest for an untrained individual to come up, understand what is going on, and maintain the program.
2. Have a single program using a base pattern and an offset for each part. This uses less memory (a significant concern for us, but not for everyone), and it is really easy to expand to additional parts in the event they decide to make 7 instead of 6. (The other method is not hard, just another branch in the main program, and another copy of the program to touch up). Downside, it is easier for an untrained person to screw up a lot with a little error.
If you are sure you want to go ahead with offsets, then there is an addition split.
1. You can have 16 points, and then offset for the different parts. (More ideal for a complex hole pattern)
2. You can have 6 corner points depending on the part, then offset your hole pattern. (More ideal for a super simple pattern like 4x4 grid)
Depending on which direction you want to go in, we can help you along.
-
I have also had many struggles with the password option. I get the feeling that they threw in some features and then no one really used them or stretched them to the limit, and now that people ARE putting their systems to the test, bugs are coming out that should have been handled well before.
On the other hand, it is pretty cool being on the leading edge of the development and usage of the password system, and being able to help set the standard for how it is used within our company!
-
What exactly are you trying to avoid reteaching? More details might help.
-
Imagine you had a piece of paper with your 16 holes punched in it. Could you have one paper that you could use for all six parts just by moving where you set the paper? If so, then you can get by with offsets or user frames. If not, you will be better off just programming each one individually.
If you can hold the piece of paper and slide it side to side without rotating it to reach all of the parts, then PR offsets will work pretty easy, but if you would have to turn the paper to cover some parts, then you may be better off using a User Frame instead. A User Frame is a way of moving all points to a new relative position and orientation.
Alternatively, are we misunderstanding and you actually want to use offsets to create the hole pattern?
EDIT since you replied mid reply.
Convert some input so that you have a numeric representation of what part you are running, that way you know what offset to apply.
If DI[1] = ON, R[1] = 1
If DI[2] = ON, R[1] = 2
If DI[3] = ON, R[1] = 3
...Move to each point plus the desired offset
L P[3] Offset PR[R[1]]
L p[4] Offset PR[R[1]]
... -
I am assuming that you Hole Pattern is identical on all 6 parts, just in a different absolute position relative to the robot. I will also assume there is no rotation, which would make things more difficult, but not impossible.
I would start by setting up my program to identify the part based on an input, such as DI[1] on for Part 1, DI[2] on for Part 2, etc. Then, set a register based on which part is selected. R[1] = 1 for Part 1, R[1] = 2 for Part 2, etc. Next, reserve a range of PRs, one for each part. they will each start as all zeros.
Make each of your 16 points be a point with an offset of an indirect position register, with the register containing your part number as the index. PR[R[1]] would use PR[1] when R[1] = 1, and PR[2] when R[1] = 2, etc. This way you will offset the same hole pattern for each part.
You would then tweak each of your PRs to match the needed offset for each part.
NOTE: Make sure that your move is Linear and that your PR is Cartesian. If you try to apply an angle change, or criss cross angle changes and Cartesian changes, you will have a bad day.
NOTE: Make sure all of the non-offset elements of your PR are zeroed out. It will offset by the entire content of the PR, not just the feature you want, unless you deliberately perform the math operations to change values one element at a time.
If your parts DO have a rotational offset, you may be better off setting up a User Frame for each part.
-
Maybe it is something new to that version. If you enable the Password menu for the lower level (Temporarily) and log in at that level the long way, then return to that screen and press the four squares, what options appear? Could it be being populated incorrectly with the logged in user instead of the available user? I wish i could get to the same screen, i would be interested in having a similar log in screen.
-
Are you using HMI Menus? I will go try that.
Edit: HMI menu either does not do what i thought it did, or it requires a power cycle to change. Either way, i am not sure how you got your screen to look like that. What controller and software version do you have? I have R-30iB V8.30
Edit: Just noticed the background, you appear to be working in RoboGuide. Does your physical TP screen have that button?
-
There’s a little button on the tp screen in the bottom left that looks like four squares. When password protection is enabled, pressing it brings you to a screen to change users. The only user listed is the install user even though there are others created. Anyone know how to fix this? Fanuc is at a loss.Sent from my iPhone using Tapatalk
I am unfamiliar with this button, could you send a picture? Ours has a visual indication of the current screen mode and which screen is active, but it does not seem to act like a button.
Navigating to the password screen the normal way through Menu -> Setup -> Passwords, do you still only see one user?
-
What i'm going to ask might be obvious but I dont see where you mentioned "...I also hook the robot directly to my laptop......"
I would start my troubleshooting there : direct PLC robot connection Again, sounds obvious but if I dont ask...Always start with the simplest possible thing that can go wrong. Tech support asks if you have your computer plugged in and the monitor turned on first for very good reasons!
In so far as additional troubleshooting goes, here are some things i would try.
1. If you have another system that IS working, try swapping. We had Robot 1 and PLC 1 in one cell, and Robot 2 and PLC 2 in another adjacent cell. Robot 1 stopped talking to PLC 1. We got a 100 foot Ethernet cable and connected Robot 1 to PLC 2 and Robot 2 to PLC 1. We were able to establish communication between Robot 1 and PLC 2, but not between Robot 2 and PLC 1, so we knew the issue was in PLC 1. This can give you an iron clad reason to point the finger at one or the other.
2. Do you have a backup from before things stopped working, for both PLC and Robot? Try restoring a backup (take a new backup first).
3. Go over the setup of both with a fine tooth comb. Question everything. If you have a duplicate cell, all the better. Compare every value. It may be that someone accidentally entered an unfamiliar screen and adjusted something unintentionally. IT is way easier to do than it should be sometimes.
4. Find ways to verify whether the issue is hardware related or software related. This is very hard to prove definitively, but if you have the spare parts, you can test hardware failures to some extent by swapping components and re-trying.
A note from my experience, we have found that turning the robot off and the PLC on for any significant length of time can occasionally cause the Safety PLC communication to drop and need to be re-established. We had similar occur with normal PLC communication when both the robot and the PLC were powered down for a day. This has been unreliable and we have not done the testing necessary to say it IS a repeatable problem, but it seems to have occurred about 60% - 70% of the time when power is turned off for more than a few minutes, or when power is cycle multiple times back to back.
-
[shadow=red,left]3. There may be a way (i am not sure) to have a pop-up occur on the TP which will prompt the user to select a program.[/shadow]There is a way to do this. I think you have to have the Menu Utility option. An Operator Entry menu and/or List menu will do this. The Operator Entry menu can be configured to accept various types of data such as boolean, numeric, etc. The List menu can be configured to list up to 8 items or so that can be selected.
That is great information! I am not sure we have the Menu Utility option, but i may look into that for our new training cell!
-
If you go this route, some things to watch out for:
1. Stack overflow. Make sure that your sub called programs come to an end before returning to your main call program. By default, it should complete the subprogram, and then return to the main, there is no need to re-call the main at the end of each sub.
2. Put in a mechanism to pause the main when a change of program is needed, otherwise it will re-trigger the same sub over and over without giving you a chance to choose.
3. There may be a way (i am not sure) to have a pop-up occur on the TP which will prompt the user to select a program. I am not sure what all is available, and what is impossible. It is not something we have ever looked into since we put all macro scale decision making on the PLC, and only leave the more micro scale decisions to the robot.
4. To prevent the need to abort tasks and switch to Teach mode to change the program, it may be in your best interest to have an interface via some other inputs. If i were setting up a system to run like this, i might have a range of Digital I/O or flags which were labeled with each of the available program names, and then have a master program called by the UOP start which would check for a change in I/O status, and run a program based on this. It would be possible to use a Register to count parts down to a new program change, and a register or duplicate range of I/O to keep track of what the previous program was. Ideally, you would want to make it so that only one program could ever be selected at a time.
I hope you are able to get your system working in a way that satisfies everyone on your end!
-
We had a robot crash while i was out of the plant, and our techs say it showed an error which indicated the robot had lost calibration. They cycled power and the error cleared and resumed operation without further issue.
My first impulse is that the crash caused a current spike which caused some odd behavior and triggered a false alarm, but i want to see if anyone else has had a similar occurrence, and is it likely that there is a bigger issue that will need to be addressed?