Any idea what it could be?
I had a similar issue earlier this year, there was a ton of good information and advice it this thread: SRVO-050 (collision detect) on first move of the day
Any idea what it could be?
I had a similar issue earlier this year, there was a ton of good information and advice it this thread: SRVO-050 (collision detect) on first move of the day
CellFinder is now called "iRCalibration Frame Shift." It's described in the iRCalibration manuals.
what would be the benefit of an array over a single variable that is declared?
You can use indexing to accomplish what you want instead of bulky select statements
DOUT is a predefined port array. You can address it as if it were an array because it is one.
UseZone is not a declared array. Therefore you can't use array addressing.
To do what you want, you could do the following:
1) declare UseZone as an array.
UseZone: BOOLEAN[2]
2) Use a select statement
SELECT n OF
CASE(1):
UseZone1 = True
CASE(2):
UseZone2 = True
ELSE:
ENDSELECT
3) Do the same thing with if statements
Without any further information about what you're trying to do, I would recommend declaring UseZone as an array and going that route.
Sorry, that isn't how variables work. You could use a SELECT or IF statement to set UseZone[n] to true if you don't want to use an array.
To use an array, declare
UseZone: BOOLEAN[2]
Looking through my FRAMEVAR.VA, I found this. The highlighted positions are the three points defining my origin, x, and y (positions are world 0). I don't know how to make use of this information, but it's definitely there.
edit: posting this removed the highlighting. COMP_POS1.NODEDATA[13].NODE_POS, COMP_POS1.NODEDATA[14].NODE_POS, and COMP_POS1.NODEDATA[15].NODE_POS are origin, x, and y, respectively.
edit #2: I looked at another robot and on that one, it's 7, 8, and 9 instead of 13, 14 and 15.
[TPFDEF]COMP_POS1 Storage: CMOS Access: RW : PATH =
Field: COMP_POS1.NODEDATA ARRAY[72] OF PATH1_NODE_T
Field: COMP_POS1.NODEDATA[1].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[2].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[3].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[4].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[5].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[6].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[7].NODE_POS Access: RW: XYZWPREXT =
Group: 1 Config: N U T, 0, 0, 0
X: 970.456 Y: -1038.993 Z: -667.294
W: 179.165 P: -.390 R: 25.433
Field: COMP_POS1.NODEDATA[8].NODE_POS Access: RW: XYZWPREXT =
Group: 1 Config: N U T, 0, 0, 0
X: 2455.328 Y: -1021.317 Z: -679.000
W: 179.166 P: -.389 R: 25.433
Field: COMP_POS1.NODEDATA[9].NODE_POS Access: RW: XYZWPREXT =
Group: 1 Config: N U T, 0, 0, 0
X: 2470.603 Y: 1067.160 Z: -681.771
W: 179.296 P: -.095 R: 71.475
Field: COMP_POS1.NODEDATA[10].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[11].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[12].NODE_POS Access: RW: XYZWPREXT = Uninitialized
Field: COMP_POS1.NODEDATA[13].NODE_POS Access: RW: XYZWPREXT =
Group: 1 Config: N U T, 0, 0, 0
X: 1513.966 Y: -883.466 Z: 13.721
W: -179.757 P: -.470 R: 92.472
Field: COMP_POS1.NODEDATA[14].NODE_POS Access: RW: XYZWPREXT =
Group: 1 Config: N U T, 0, 0, 0
X: 2330.211 Y: -862.026 Z: 16.359
W: -179.757 P: -.470 R: 50.829
Field: COMP_POS1.NODEDATA[15].NODE_POS Access: RW: XYZWPREXT =
Group: 1 Config: N U T, 0, 0, 0
X: 1456.289 Y: 638.774 Z: 30.119
W: -179.757 P: -.470 R: 50.829
Display More
Weird that it isn't even showing analog in the menus... do you have quick menus enabled instead of full menus (Fctn > next > quick/full menus)?
What interface card are you using? Are you sure that the interface card is getting 24V? Have you made sure that your K1X cable is connected to JD1A on the controller and JD1B on the interface card?
What version of RG are you running? Click on "test-run" on the menu bar, then "Profiler"
Use the cycle start button on the toolbar. When it's done, go to the profile it generated, double click on the task, and it will display cycle time in a popup.
What about PR[200]=P[x] before CALL Move_To_Aprox?
I've been playing with tool rotation to try to find the optimal orientation to help with the reach issue. What I decided to do was to run a program containing the following code at the start of my problematic move, then just pull the values from numreg.va and plot it in excel for various tool rotations.
1: R[120]=123 ;
2: LBL[1] ;
3: R[121]=$SCR_GRP[1].$MCH_ANG[2] ;
4: R[122]=$SCR_GRP[1].$MCH_ANG[3] ;
5: R[R[120]]=R[121]+R[122] ;
6: ;
7: WAIT 1.00(sec) ;
8: R[120]=R[120]+1 ;
9: IF R[120]<200,JMP LBL[1] ;
The problem I'm running into is that $SCR_GRP[1].$MCH_ANG[2] and $SCR_GRP[1].$MCH_ANG[3] aren't updating - they're stuck at -9.03 and -34.1, respectively. $SCR_GRP[1].$M_POS_ENB is TRUE; any idea why this isn't working?
Kinda a long shot here, but I figure it doesn't hurt to ask...
I'm getting a MOTN-017 limit error in the position shown for pretty obvious reasons (J2/J3 interaction). However, none of the individual axes are anywhere near their limits, and the RG (V8, FRVC 6.4) TCP trace function "color by axis limits" doesn't have an option for looking at the J2/J3 interaction limit. Does anybody know of any way to highlight when I'm getting close to this limit, other than observing with the Mk1 eyeball?
I tested this on my RJ3iB (HandlingTool 6.4) a few years ago. The Origin-X axis defines the X axis direction. The XY plane is defined as containing the Origin-X axis and the Origin-Y axis (ie, the Y point controls rotation about the X axis). And the Z axis is orthogonal to the XY plane. So no, the angle doesn't have to be 90 degrees, but the Origin-X axis defines the X axis direction and therefore the orientation.
another way might be to set a motion group allocated in your program again.
And then setup your program to run as BG_LOGIC.
Thanks, for some reason I was under the impression that BGlogic programs couldn't have motion groups but testing in RG shows that that will work.
What I'm trying to do:
Read several PRs from the robot to my CompactLogix PLC on demand so that I can display them on an HMI (budget is $0, so can't use SNPX HMI unfortunately). The robot is running HandlingTool 7.70, so it doesn't support PRs via explicit messaging.
My thought was to break each PR into 3 registers (only care about position, not rotation) and read those via explicit messaging into a REAL array in the PLC that the HMI can access. I'm using a DI over Ethernet/IP to trigger a macro that copies the PR positions into the registers.
/PROG RD_PR_POS Macro
/ATTR
OWNER = MNEDITOR;
COMMENT = "PRs to PLC";
PROG_SIZE = 657;
CREATE = DATE 23-09-21 TIME 15:52:52;
MODIFIED = DATE 23-09-21 TIME 15:52:52;
FILE_NAME = ;
VERSION = 0;
LINE_COUNT = 25;
MEMORY_SIZE = 929;
PROTECT = READ_WRITE;
TCD: STACK_SIZE = 0,
TASK_PRIORITY = 50,
TIME_SLICE = 0,
BUSY_LAMP_OFF = 0,
ABORT_REQUEST = 0,
PAUSE_REQUEST = 0;
DEFAULT_GROUP = *,*,*,*,*;
CONTROL_CODE = 00000000 00000000;
/APPL
AUTO_SINGULARITY_HEADER;
ENABLE_SINGULARITY_AVOIDANCE : TRUE;
/MN
1: R[59:rd_B1 Approach X]=PR[11,1:Bowl 1 Approach] ;
2: R[60:rd_B1 Approach Y]=PR[11,2:Bowl 1 Approach] ;
3: R[61:rd_B1 Approach Z]=PR[11,3:Bowl 1 Approach] ;
4: R[62:rd_B1 Pick X]=PR[12,1:Bowl 1 Pick] ;
5: R[63:rd_B1 Pick Y]=PR[12,2:Bowl 1 Pick] ;
6: R[64:rd_B1 Pick Z]=PR[12,3:Bowl 1 Pick] ;
7: R[65:rd_B2 Approach X]=PR[13,1:Bowl 2 Approach] ;
8: R[66:rd_B2 Approach Y]=PR[13,2:Bowl 2 Approach] ;
9: R[67:rd_B2 Approach Z]=PR[13,3:Bowl 2 Approach] ;
10: R[68:rd_B2 Pick X]=PR[14,1:Bowl 2 Pick] ;
11: R[69:rd_B2 Pick Y]=PR[14,2:Bowl 2 Pick] ;
12: R[70:rd_B2 Pick Z]=PR[14,3:Bowl 2 Pick] ;
13: R[71:rd_B3 Approach X]=PR[15,1:Bowl 3 Approach] ;
14: R[72:rd_B3 Approach Y]=PR[15,2:Bowl 3 Approach] ;
15: R[73:rd_B3 Approach Z]=PR[15,3:Bowl 3 Approach] ;
16: R[74:rd_B3 Pick X]=PR[16,1:Bowl 3 Pick] ;
17: R[75:rd_B3 Pick Y]=PR[16,2:Bowl 3 Pick] ;
18: R[76:rd_B3 Pick Z]=PR[16,3:Bowl 3 Pick] ;
19: R[77:rd_B4 Approach X]=PR[17,1:Bowl 4 Approach] ;
20: R[78:rd_B4 Approach Y]=PR[17,2:Bowl 4 Approach] ;
21: R[79:rd_B4 Approach Z]=PR[17,3:Bowl 4 Approach] ;
22: R[80:rd_B4 Pick X]=PR[18,1:Bowl 4 Pick] ;
23: R[81:rd_B4 Pick Y]=PR[18,2:Bowl 4 Pick] ;
24: R[82:rd_B4 Pick Z]=PR[18,3:Bowl 4 Pick] ;
25: DO[22:PR write done]=PULSE,1.0sec ;
/POS
/END
Display More
My problem is that if I give this macro a motion group *, I get an INTP-214 "Specified group not locked" error. If I give it a motion group of 1, I get INTP-105 "Run request failed" and PROG-040 "Already locked by other task" messages. I understand why this is happening, but am scratching my head trying to figure out how to get around it. It seems like there should be a much better solution than what I'm trying.
Any suggestions?
Although... this seems to be a matrix notation I'm not familiar with. Normally I see the Matrix translation of a 6DOF position as a 4x4 matrix, and this is only a a 3x2. I'm guessing that the OX, OY, and OZ are the... unit vectors? In the 4x4 matrix, each Rotation is represented by 3 values in a column, and IIRC those three values can be combined into a single unit vector.
It's a 3x4, hit F2 (PAGE) to see the rest of the values. The N,O, and A values are your unit vectors and the L values are position.
Truncate: R[x] = R[y] DIV 1
Round: R[x] = (R[y]+.5) DIV 1
Depending on your physical layout, you could use an area sensor, beam detector, floor mat, or something like that (not safety rated) to drop the hold signal before the operator gets to the light curtain; use the light curtain for safety as part of the fence circuit.
This thread may be helpful: Best practice to calibrate real world to roboguide