In order to modify positions, why won’t it work when I jog the robot to the location, go to debug, and click modify position ? When I click modify position it asks if I’m sure and it acts like it saved it. However the robot always reverts to the previous location. What all do I need to do to modify positions. Somone today said I need to change the location in Robtarget and wobjdata, or when I PP to main the new number is erased.
Modifying positions
-
cat91345 -
May 10, 2024 at 7:09 AM -
Thread is Unresolved
-
-
What version of controller? What version of robotware? Is there UAS set up that does not allow the modification of positions? Why not use the Modify position function key, should be right next to debug.
-
Are you sure it's not a calculatet position,
P1:=p2
-
What version of controller? What version of robotware? Is there UAS set up that does not allow the modification of positions? Why not use the Modify position function key, should be right next to debug.
RW:5.11
controller: i can't find the controller info.
I have been trying to use the modify position key but the position won't take. Everytime I start the progream over, it goes back to original positoin. In order to change it i have to to through robtarget and guess the position pretty much. Also i can modify positions from robtarget so it must not be UAS since i can edit from there.
-
Could be reloading a saved program/module when it boots. If you don't save after your changes before you reboot, then it reloads everything from the last time it was saved.
If it's calculated as Black suggests, take a copy of a backup and use a text editor to search everything in the backup for instances of that position. You'll usually find that position referenced somewhere if it is calculated.
-
So I found out since my robot uses routines, I can’t move the robot to that location and modify. Apparently when I PP to main, all the original positions are input. I don’t know how to override this. Apparently I have to go to main program and sift thru thousands of line of code in Notpad.
-
Apparently I have to go to main program and sift thru thousands of line of code in Notpad.
You should be able to use RobotStudio (free version) to make this easier. Either plug in directly, or import a backup of the robot. You can use tools like "find all references" on a variable to find everywhere it is declared, altered, or used.
You might also want to download a comparison tool like KDIFF3 or WinMerge or BeyondCompare. You can point them at two different backups and get a quick view of which lines in which files changed (and which ones didn't) before and after you made a change, for example.
Also, look through your robot for any occurrences of UnLoad and StartLoad commands. ABB RAPID allows a program to swap program modules between "active" memory and storage. It's possible whoever set that robot up in the past has it set to re-load files from storage. Certain German companies like Thyssen like to use this trick heavily, which makes touching up points something that requires extra care.
-
You should be able to use RobotStudio (free version) to make this easier. Either plug in directly, or import a backup of the robot. You can use tools like "find all references" on a variable to find everywhere it is declared, altered, or used.
You might also want to download a comparison tool like KDIFF3 or WinMerge or BeyondCompare. You can point them at two different backups and get a quick view of which lines in which files changed (and which ones didn't) before and after you made a change, for example.
Also, look through your robot for any occurrences of UnLoad and StartLoad commands. ABB RAPID allows a program to swap program modules between "active" memory and storage. It's possible whoever set that robot up in the past has it set to re-load files from storage. Certain German companies like Thyssen like to use this trick heavily, which makes touching up points something that requires extra care.
“You should be able to use RobotStudio (free version) to make this easier. “
I have subscription to RS, will this make it easier to change positions?
Also, I currently go to robtarget and wobjpallet to change the height of infeed pickup, I have to change it in 2 positions to make it work. How do I know if I change it in all the necessary spots when I use the notepad editor ? -
I have subscription to RS, will this make it easier to change positions?
It'll make it easier to test, certainly. If you have the licensed RS, you can build a virtual duplicate of your real robot from a backup and do actual code execution.
The real benefit of RS is that it makes it much easier to trace down all occurrences of a variable.
Also, I currently go to robtarget and wobjpallet to change the height of infeed pickup, I have to change it in 2 positions to make it work. How do I know if I change it in all the necessary spots when I use the notepad editor ?
"Change in 2 positions"? I don't understand what you mean.
Robtargets are always defined relative to a WObj. You can offset positions by changing the Robtarget, or by altering the WObj. You should not have to change both.
Any WObj or RT should only be recorded in one location, like:
CONST robtarget pToolRackPounce:=[[1900.91,21.85,989.61],[0.00398645,-0.710583,0.703596,0.002808],[-1,0,-2,0],[354.883,9E+09,9E+09,9E+09,9E+09,9E+09]];That is an implicitly global declaration -- any other RT declared with the same name in another module should cause an error. The only exception would be something like:
LOCAL PERS robtarget pWobj_U_PointX1:=[[4506.385,-1904.591,1311.162],[0.665561676025391,-0.282265663146973,-0.650280237197876,0.233429610729218],[-2,-1,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];The LOCAL limits the scope of that RT to the module it is declared in. In that case, it's possible for points in different modules to have the same name without collisions, but they are completely seprate points -- modifying one has no effect on the others.
-
It'll make it easier to test, certainly. If you have the licensed RS, you can build a virtual duplicate of your real robot from a backup and do actual code execution.
The real benefit of RS is that it makes it much easier to trace down all occurrences of a variable.
"Change in 2 positions"? I don't understand what you mean.
Robtargets are always defined relative to a WObj. You can offset positions by changing the Robtarget, or by altering the WObj. You should not have to change both.
Any WObj or RT should only be recorded in one location, like:
CONST robtarget pToolRackPounce:=[[1900.91,21.85,989.61],[0.00398645,-0.710583,0.703596,0.002808],[-1,0,-2,0],[354.883,9E+09,9E+09,9E+09,9E+09,9E+09]];That is an implicitly global declaration -- any other RT declared with the same name in another module should cause an error. The only exception would be something like:
LOCAL PERS robtarget pWobj_U_PointX1:=[[4506.385,-1904.591,1311.162],[0.665561676025391,-0.282265663146973,-0.650280237197876,0.233429610729218],[-2,-1,-1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];The LOCAL limits the scope of that RT to the module it is declared in. In that case, it's possible for points in different modules to have the same name without collisions, but they are completely seprate points -- modifying one has no effect on the others.
"Change in 2 positions"? I don't understand what you mean”
For example, to change the height the robot goes to pickup of infeed I have to go toRobtarget/infeedpick/ change Z
I also have to go to
Robtarget/infeedpickpositionolasticbuckets/change Z
If I don’t change the Z in both locations, the robot reverts to original Z position. -
For example, to change the height the robot goes to pickup of infeed I have to go to
Robtarget/infeedpick/ change Z
I also have to go to
Robtarget/infeedpickpositionolasticbuckets/change Z
If I don’t change the Z in both locations, the robot reverts to original Z position.I would have to see the actual program modules to completely understand what's going on here, but it seems as if some RAPID code is executing that "resets" the Z value of those points.
-
I would have to see the actual program modules to completely understand what's going on here, but it seems as if some RAPID code is executing that "resets" the Z value of those points.
as you see in line 181 and 188, i have to change the Z in both line in order for robot to change height when it picks up product off the line. If i don't change in both locations, it won't work.
-
that´s still not the whole programm, just the declaration of some robtargets
which is interesting as you can already see some are PERS while other are CONST, but that´s it...it seems that you have some calculations happening in your programm and you still can´t back
trackthe easiest thing you could do is use the <code> tags and copy the program text here, if it occours in more then a single module make a code box for every module
or upload a backup -
as you see in line 181 and 188, i have to change the Z in both line in order for robot to change height when it picks up product off the line. If i don't change in both locations, it won't work.
So, if you change the Z value of one and not the other, the changed Z value reverts? Does it behave the same way if you change the 1st and not the 2nd, and then try changing the 2nd but not the 1st?
I'd need to see the executable, but if (in RS) you right-click each of those RTs and use the "Find All References" option, you'll get a list of every line, in every module, where that RT is referenced. My first guess is that there's some sort of error-checking code that is comparing the Z values of those two RTs, and resetting them to some fixed reference value if they don't match.