Posts by Nation

There are several ways to do what you are asking.

I would recommend using an offset based on a position register.

You could hard code the offset in the program, or point it at a register.

For example (hard code version):

1:  !LPOS and then zero, in case ;
   2:  !someone changed it to a JPOS. ;
   3:  PR[100:Offset]=LPOS    ;
   4:  ! X componant ;
   5:  PR[100,1:Offset]=100    ;
   6:  ! Y componant ;
   7:  PR[100,2:Offset]=0    ;
   8:  ! Z componant ;
   9:  PR[100,3:Offset]=0    ;
  10:  ! W componant ;
  11:  PR[100,4:Offset]=0    ;
  12:  ! P componant ;
  13:  PR[100,5:Offset]=0    ;
  14:  ! R componant ;
  15:  PR[100,6:Offset]=0    ;
  16:   ;
  17:J P[1:Clear] 100% CNT100    ;
  18:L P[2:Above Pick] 100mm/sec CNT25 Offset,PR[100:Offset]    ;

How step mode behaves is also set under the Test Cycle menu.

Menu -> Test Cycle -> Item 3.

Quote from Sergei Troizky

Thank you, Nation, it worked.

I also would like to directly read a user frame component into a register.
This will be done in TP format BG logic, so reading to position register cannot be used.
What would be the syntax for this? Say, I need Z of Uframe 1.
R[1]=($MNUFRAME[1,1]???). How to refer the Z component?

Display More

I too would really like to know how this is done, assuming it is even possible. I even had a thread here, but no one was able to give me an answer.

What you are seeing in the PR is the first 6 components of a rotation matrix. If you hit the page key (F2 I think) when viewing it you will see the remaining 6 components.

Turn $PR_CARTREP to True in the system variables. This will make the PR in a PR[XX]=UFRAME[X] command show up in normal Cartesian representation and not in matrix representation.

Of course this very useful system variable isn't documented...

If you want to use the robot as a pass through, you could use the interconnect screen under IO to map the robot inputs and outputs to digital inputs and outputs. I've seen that done before.

I really like this idea. Especially since it seems that about 1/4 of all the system variables are undocumented. I've discovered a couple of nice ones just through experimentation. Other ones I've found out from some one "in the know". Do a control-F for them in the system variables document? 0 results.

I would like to see a list of variables that are not in the current documentation, with a blurb of the theorized or observed affect of the variable is. How could Fanuc claim copyright when the variable in question is not in their documentation?

You could categorize them so searching through them is easier. These variables directly affect the mechanical unit. These affect the motion planner. These affect how ASCII upload works. It would be far better than how Fanuc organizes their system variable document (plain A-Z).

Only joint jogging mode is available. If you try to jog in any other mode, it will say something like "robot not calibrated" and not move.

Quote from Sergei Troizky

I've never worked with RJ, but does not it have dual-channel safety inputs to stop the robot?
Something similar to "fence" or "servo off" on r-30iA/B.
Safety functions should not be implemented by software, especially for human safety.
The same applies to the press.

I agree with Sergei on this. Implementing this in software is asking for trouble.

I also have never worked with an RJ, but I think once you get into this old of a controller, you only have single channel safety inputs. Even still, that is better than doing it in software.

You are stepping on the style select inputs used by the UOPs. When input 16 turns on (UOP style select 8), you are effectively telling the robot to run a style (style 128 in this case) that doesn't exist.

In short, don't use inputs 1-18. They are mapped to the UOPs on your robot. Shame on the previous robot programmer for not labeling them. Lazy.

That, or unassign input 16 from the UOP inputs. This is an ugly solution in my opinion.

The same is probably true for outputs 1-20. Likely assigned to the UOP outputs.

If you just want to use a solid light, you can use the interconnect screen under IO to connect various safety signals up to outputs. Simple and clean.

Menu ->IO -> Interconnect -> [Select] (F3) -> "ES -> DO"

Quote from Chipprogr

I dont have the condition monitor list in front of me, but this would have to be done as a background program task , not in a main motion group program. I do monitoring programs like this in KAREL, not TPE. Maybe someone can chime in here and say.. does TPE programming have the ability to keep a program running, even on an abort all command? In Karel, you modify the compiler directives and can force the program to keep running indefinately , even on a Estop. Only a power cycle would stop the program.

Others are fans of the BG Logic (background logic) and I would think maybe this could be accomplished in it too.

Yes there is a way to do this. In the header of a .ls program, change it to the following:

TCD:  STACK_SIZE	= 0,
      TASK_PRIORITY	= 50,
      TIME_SLICE	= 0,
      BUSY_LAMP_OFF	= 1,
      ABORT_REQUEST	= 3,
      PAUSE_REQUEST	= 7;

This will make a tp program impossible to abort, pause, and will not light up the cycle light. It will not honor this if there is a group assigned to the program though.

If you have an IRC5, try using HotEdit. If you want to adjust the points more than 5mm at a time though, you will have to modify a system parameter.

That parameter is: HOTEDIT_MODPOS under the topic Controller.

I am not sure if it is available on the S4C+.

I ended up calling Fanuc and asking them what these do. They are the macros used to communicate to a program on a computer somewhere running the pc dev kit. Useless for what I need.

I just wish the included macros had a bit more text inside of them that stated what they do.

Does anyone have any example programs on how to use the SENDDATA and GETDATA macros?

What I want to do is send a PR from one robot to another robot. I believe I could do that with the above macros.

This screams to me "mechanical screw-up, make controls fix it".

It sounds like you need to master your jigs (make them all the same) and/or the pallets carrying the jigs. Also, as Atticabob stated, how repeatable is the method you use to locate the jigs? In my experience the best method is to set the pallet carrying the jig down on a 2 way and 4 way locator.

Quote from Atticabob

Hi Greg,

I would set up user frames for each jig... If the number of jigs exceeds 10 I would simply put the frame data into PR's then pull it into the frame as needed... You could use PNS to call a specific program that holds jig number / frame number/ product number... Does the system get a BCD type input to know what fixture is in it?
With things varying slightly... How well does the conveyor repeat position?

On the newer controllers (R30iA and up, not sure about older), you can increase the number of user frames by manipulating the $SCR.$maxnumufram system variable. I've taken it as high as 64 frames before.

Your program gets the old data because you are not waiting for the vision process to complete, thus running old offsets. Its like firing a gun without aiming it. Likely into your own foot.

You need to interlock the two programs together. This can be done with a flag bit or a register.

I've modified your programs to include an interlock. Take out all those timers, every time I see this in the field it means that there is spaghetti code ahead.

Also, your program now has no way of failing gracefully if the vision can't find anything. I'll leave adding that as an exercise to the user.

1st (main) program.

1:  LBL[1] ;
   2:  UFRAME_NUM=4 ;
   3:  UTOOL_NUM=4 ;
   4:  RO[3:YUKLEME AC]=ON ;
   5:  RUN CAM ;
   6:L PR[1:HOME_POS] 2000mm/sec CNT100    ;
   7:  LBL[30] ;
   8:  R[20:KNV_CNTR]=0    ;
   9:L P[1] 2000mm/sec CNT20    ;
  10:  WAIT DI[102:PARCA HAZIR]=ON    ;
  11:   ;
  12:  LBL[2] ;
  13:  IF R[20:KNV_CNTR]>=1,JMP LBL[7] ;
  14:  R[20:KNV_CNTR]=R[20:KNV_CNTR]+1    ;
  15:  WAIT    .50(sec) ; <-- Not needed.
    :   WAIT F[1:CAM INTERLOCK]=ON ; <-- New addition.
  16:  R[10]=VR[1].MODELID ;
  17:  WAIT    .50(sec) ; <-- Not needed.
  18:  IF R[10]=7,JMP LBL[5] ;
  19:  IF R[10]=8,JMP LBL[6] ;
  20:   ;
  21:  LBL[7] ;
  22:  DO[107:KNV.CALISTIR]=PULSE,1.0sec ;
  23:  JMP LBL[30] ;
  24:   ;
  25:  LBL[5] ;
  26:   ;
  27:L P[2] 2000mm/sec FINE VOFFSET,VR[1]    ;
  28:L P[3:ALMA_5] 500mm/sec FINE VOFFSET,VR[1]    ;
  29:  WAIT   0.00(sec) ; <-- Not needed.
  30:  RO[4:YUKLEME KAPA]=ON ;
  31:L P[4] 2000mm/sec FINE VOFFSET,VR[1]    ;
  32:   ;
  33:L P[5] 2000mm/sec FINE    ;
  34:   ;
  35:  DO[107:KNV.CALISTIR]=PULSE,1.0sec ;
  36:L PR[1:HOME_POS] 2000mm/sec CNT100    ;
  37:  CALL TRS_PARCA_KOYMA    ;
  38:   ;
  39:  JMP LBL[1] ;
  40:   ;
  41:   ;
  42:   ;
  43:  LBL[6] ;
  44:  WAIT   0.00(sec) ; <-- Not needed.
  45:L P[6] 1000mm/sec FINE VOFFSET,VR[1]    ;
  46:L P[7:ALMA_6] 500mm/sec FINE VOFFSET,VR[1]    ;
  47:  WAIT   0.00(sec) ; <-- Not needed.
  48:  RO[4:YUKLEME KAPA]=ON ;
  49:L P[8] 2000mm/sec FINE VOFFSET,VR[1]    ;
  50:L P[9] 2000mm/sec FINE    ;
  51:  DO[107:KNV.CALISTIR]=PULSE,1.0sec ;
  52:J P[10] 100% CNT50    ;
  53:L P[11] 1000mm/sec FINE    ;
  54:L P[12:BIRAKMA] 100mm/sec FINE    ;
  55:  WAIT   0.00(sec) ; <-- Not needed.
  56:  RO[3:YUKLEME AC]=ON ;
  57:L P[14] 2000mm/sec CNT10    ;
  58:J P[15] 100% CNT50    ;
  59:L P[17] 1000mm/sec FINE    ;
  60:  RO[3:YUKLEME AC]=OFF ;
  61:  WAIT   0.00(sec) ; <-- Not needed.
  62:L P[18] 1000mm/sec CNT20    ;
  63:  RO[4:YUKLEME KAPA]=ON ;
  64:J P[20] 100% CNT100    ;
  65:  CALL TRS_PARCA_KOYMA    ;
  66:  JMP LBL[1] ;

Your second program.

1:  R[70]=0    ;
    :  F[1:CAM INTERLOCK]=OFF ;  <-- New addition.
   2:  LBL[1] ; 
   3:  VISION RUN_FIND 'TAH_3838H'    ;
   4:  WAIT    .50(sec) ; <-- Not needed.
   5:  R[70]=R[70]+1    ;
   6:  IF R[70]>2,JMP LBL[2] ; 
   7:  VISION GET_OFFSET 'TAH_3838H' VR[1] JMP LBL[1] ;
    : F[1:CAM INTERLOCK]=ON  ; <-- New addition.
   8:   ;
   9:  LBL[2] ;

Quote from JonHopper

I'm curious as to how this DCS input/output system is considered "dual channel" when all I need is 1 opsfty input to enable or disable a zone, and also can link 1 zone to 1 output? This is not dual channel. Unless I am missing something.

Sup three year old thread.

See the image below.

A1 and B1 are the inputs for a single safety input (OPSFTY1 in this case). Its dual channel since two inputs need to change state within 200ms of each other in order to actuate the input without generating a chain fault. It functions the same way the fence circuit does, or the external estop circuit.

You can have a safe output on pins A5 and B5. When ESPDO1 is turned on, both A5 and B5 will source 24V. It is up to the user to supply hardware that checks for dual channel functionality (like a safety relay).

Well I was unable to determine the syntax.

I ended up doing in Karel, as much as I didn't want to.

Here's the code (stripped down a bit):

PROGRAM LNTRKTOPR


%COMMENT = 'Line Trk to PR'
%NOLOCKGROUP
%NOPAUSE = ERROR + COMMAND + TPENABLE


VAR
data_type,
dest_PR ,
int_value,
LNTRKSCH ,
STATUS : INTEGER
LNTRKFRAME :XYZWPR
real_value: REAL                         -- Used only for the GET_TPE_PRM command
str_value : STRING[32]                  -- Used only for the GET_TPE_PRM command


BEGIN


GET_TPE_PRM(1, data_type, int_value, real_value, str_value, STATUS)
LNTRKSCH=int_value
GET_TPE_PRM(2, data_type, int_value, real_value, str_value, STATUS)
dest_PR=int_value


--Get the frame from the commanded line schedule.
LNTRKFRAME=$LNSCH[LNTRKSCH].$TRK_FRAME


--Set the commanded PR.
SET_POS_REG(dest_PR, LNTRKFRAME, STATUS)


END LNTRKTOPR

Quote from luetin

When I'm having problems finding the correct formatting for a system parameter I use the variable browser in Roboguide. If you browse to the desired variable there it displays the correct formatting in the same window.

That's what I normally do as well, but when you go to the system variable I am looking at, it just changes to a "view position" button. Similar to how a PR is displayed.

Pulling from a system parameter isn't even an option if I don't use mixed logic.

If I point the PR at a number, or a bool, it works fine.

example:

!No invalid parameter name message. ;
PR[98,1]=($LNSCH[1].$TRK_GRP_NUM) ;

However, I can't figure out how to access a sub component of a position. It always says invalid parameter name.

Stuff I have tried so far (all invalid parameter names.):

PR[98,1]=($LNSCH[1].$TRK_FRAME.$X) ;
PR[98,1]=($LNSCH[1].$TRK_FRAME[1].X) ;
PR[98,1]=($LNSCH[1].$TRK_FRAME[1].$X) ;

Does anyone know the syntax to pull a component of a position out of the system variables?

I am trying to do the following, but the pendant keeps saying invalid syntax.

PR[98,1]=($LNSCH[1].$TRK_FRAME.X) ;