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.
Posts by TitusLepic
-
-
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.
Code1: 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.
Code
Display More/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
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
-
Relevant post: General conversion between different coordinate system types (KUKA, Fanuc, ABB, etc)
More detailed explanation: https://www.mecademic.com/academic_artic…n-euler-angles/
Off the top of my head I don't know the conversions, but you should be able to figure it out with this information.
-
-
You don't have to do a wait. Just a fine termination for the previous point.
-
This method is way easier, and you can do it yourself:
Do yourselves a favor and create a TP program, chose an open register (in this case Register 1 was open) and put in the following code:
R[1] = $DCS_CODE
Run that line and look up the value in your Data Registers. -
Userframe, or UFrame. There's a bunch of information on this forum; it's the reference frame that all of your points are taught relative to.
Menu > setup> frames > F3[other] > user frames
-
Dropping the collision detect to 50% increases the disturbance threshold. I would monitor that look for spikes. A lot of things can cause this.....cables, motors , bad RV gear and even a servo amp. When these things suddenly start happening I look for cable damage first especially if the RCC are laying on the floor. I've found metal shavings pierced through the insulation from people stepping on cables.
Thanks. I should have mentioned, I put the collision detect back at 100% after sending it home and it's run fine since then. Will inspect the cables today if I get a chance.
-
Is it set to inverse polarity? (next > detail)
-
From the mechanical maintenance manual:
-
You should take your backup from a known position, but that doesn't have to be the mastering position. I always take mine from our home position.