Hello all, I'm looking for a way to view the contents of the execution history. This is normally accessed by going to STATUS > TYPE > Exec-hist. When I'm not able to see the teach pendant, but have web access to the robot, this would be helpful at some times.
I've done some searching through the backup files, and know the different files pretty well. My guess is that's it's a summary of information found throughout a couple different files, and possibly not all stored in a single file.
I was told by Fanuc that just updating the variables did not force the robot to re-calculate the info that gets done when entered in via the setup screen. I never actually tested this and just took their word for it.
Have you tested with a large and small payload on the same moves and seen if the robot accel is limited with the higher payload?
You need the HMI SNPX option on the robot. In Crimson, you would use the GE/TCP/IP Master via SRTP driver. I use this method frequently as a low cost easy method to communicate with the robot. The HMI SNPX option is very low cost.
Here is the variable I used on a previous application. I remember there being a couple of diffrent sets of values, but that's the one that gave the raw forces from the sensor, and not some "auto calculated" values.
R[81:Start Force X]-$CCC_GRP[1].$FS_FORCE[1]
My normal method is to use zones to determine what area the robot TCP is in and have custom recovery moves for each zone.
To check the zones, I save 2 PRs to represent the diagonal corners of a box and check if the LPOS is inside of the zone using > & < comparisons.
The recovery moves are normally pretty generic, check z position and move up if needed, check x and move back if needed, etc.
In the past, I found it easiest to generate a text file with the coordinates and then use Karel to read in the coordinates and plug them into a PR. When I did this, the Karel logic was running in the background waiting for the robot to need another PR. It would then read another line from the text file. This worked pretty smoothly but required all the coordinates to be known before the process started.
We use RedLion HMI's to communicate with the robots over SNPX. You need to add the HMI Option to the robot which is $550 list price. Once it's enabled, you don't need to do any setup to pass I/O and integer registers. If you're looking to use real numbers, or get access to things like frames, system variables, and PR's you will need to edit the SNPX_ASG variables. Let me know if you need help getting it setup.
To solve this problem, I put these lines of code in my background logic. Essentially, the robot stays in local mode unless the PLC is trying to start it. When the PLC sends the Start or RSR signal, it also turns on DI[112].
When using push buttons instead of a PLC, you could probably modify the IF to look at the push button input instead.
14: !Remote/Local ;
15: IF (DI[112:OFF:Remote]) THEN ;
16: $REMOTE_CFG.$REMOTE_TYPE=1 ;
17: ELSE ;
18: $REMOTE_CFG.$REMOTE_TYPE=2 ;
19: ENDIF ;
I've been using this program to check if the robot is in a zone. Sometimes I have it in a background program pulling in the position, and others, I do an LPOS and run it once before recovery. It relies on having 2 PRs to define a zone and checks if the position is inside of the zone. If anyone is familiar with ABB's worldzones, this was my attempt to replicate it.
1: R[198:pr 1]=AR[1] ;
2: R[199:pr 2]=AR[2] ;
3: R[200:flag]=AR[3] ;
4: ;
5: PR[98:LPOS]=LPOS ;
6: //J PR[98:LPOS] 100% CNT100 ;
7: ;
8: !Pull in TCP Coords ;
9: //R[191:zone x]=($SCR_GRP[1].$MCH_POS_X) ;
10: //R[192:zone y]=($SCR_GRP[1].$MCH_POS_Y) ;
11: //R[193:zone z]=($SCR_GRP[1].$MCH_POS_Z) ;
12: R[191:zone x]=(PR[98,1:LPOS]) ;
13: R[192:zone y]=(PR[98,2:LPOS]) ;
14: R[193:zone z]=(PR[98,3:LPOS]) ;
15: ;
16: !Check X & Y coord of P1 & P2 ;
17: ;
18: !Get Smallest Coord ;
19: IF (PR[R[198],1]<PR[R[199],1]) THEN ;
20: R[194:x sm]=PR[R[198],1] ;
21: R[195:x lg]=PR[R[199],1] ;
22: ELSE ;
23: R[194:x sm]=PR[R[199],1] ;
24: R[195:x lg]=PR[R[198],1] ;
25: ENDIF ;
26: IF (PR[R[198],2]<PR[R[199],2]) THEN ;
27: R[196:y sm]=PR[R[198],2] ;
28: R[197:y lg]=PR[R[199],2] ;
29: ELSE ;
30: R[196:y sm]=PR[R[199],2] ;
31: R[197:y lg]=PR[R[198],2] ;
32: ENDIF ;
33: ;
34: !Zone 1 start ;
35: F[R[200]]=(R[191:zone x]>R[194:x sm] AND R[191:zone x]<R[195:x lg] AND R[192:zone y]>R[196:y sm] AND R[192:zone y]<R[197:y lg] AND R[193:zone z]<=PR[R[198],3]) ;The problem is that there is not a set amount of parts. The robot is handling parts that can range in size. The operator enters the length, diameter and center of gravity.. My plan was to calculate the inertia and then update the payload. I did this on an ABB robot a while ago using a function called gripload.
Hello,
I have an application where the robot's payload changes drastically between cycles. i.e. The EOAT mass is over double in some scenarios, and the CoG is far enough out that the inertia will make a large impact on the payload. I see the PLST_GRP system variables and have tested changing them via a TP program, but when I asked Fanuc, they said it needs to be entered via the TP Motion screen for it to take effect. Something about it having to run calculations once entry is complete. This makes sense since the screen can only be updated when it's the primary window, and due to the confirmations that are presented when making a change to one of the values.
If I can't update the values form the program and have them take effect, then my backup would be to update the values and maybe make a single change from the pendant to make them work. That would at least save the manual entry of all the values.
Does anyone have any experience with changing the payload values (mass, CoG, inertia) from the program?
Are you using a tool changer or just un-bolting the tools. The tool changers such as the ones from ATI Industrial Automation have built in tool ID signals. You could do something with a rotary dial and have the operator set the dial to the correct position, then the robot would just look at the IO that are on to determine the tool that's active.
We use RedLion HMI's with our Fanuc robots. The RedLion ties in seamlessly with the Robot's SNPX (paid option). In my experience, the RedLions are much more powerful than the other HMI's on the market as far as animations and running logic on them. On small systems, I've eliminated a PLC and done all the auxiliary controls in the HMI. I've probably done about 25 robot/RedLion systems. I'm not afiliated with RedLion, I've just had many good experiences with them.
If you're connecting just the one time and don't want to save the path, type in the IP address along with a backslash at the end.
192.168.0.1/
I had a similar problem once and of course couldn't come up with a solution. A few days later when I was gone from the customer's site, I realized that if I made the 2 DI's into a GI, it should work. Then you would search until GI > 0.
Like I said I haven't tested it, but it should work.
There's a vision simulator that I've used to debug my vision processes on a PC. You can download it from the Fanuc CRC, it's called iRVision Simulator. It's been a while, so I'm not sure, but I think a license is required to run it. The licence is free, but you have to ask Fanuc for it.
Thanks for the suggestions, but I wasn't able to find a solution better than using flags to track if the program is running.
I am looking for a way to check if a program is running in the background via a system variable. I know the common practice is to use Flags to check this, but there is room for error in this method as others have discussed. This can be fixed using a WAIT 0.01 sec, but I'm looking for a more reliable way to do this.
In the below example, the main program calls COORD and waits for F[23] to turn on meaning the program has finished, but what I see happening is that the flag turns on before COORD is actually finished. In the main program on line 4, I get the error "Program is already running".
The program COORD has 4 steps, the three lines of code and the program END command. The flag gets turned on on step 3 before the program has ended.
-- MAIN PROGRAM --
1: RUN COORD ;
2: WAIT (F[23]) ;
3: PR[2]=PR[1] ;
4: RUN COORD ;
5: DO WORK
-- BACKGROUND PROGRAM --
1: F[23:Prg Run]=(OFF) ;
2: CALL GETCOORD ;
3: F[23:Prg Run]=(ON) ;
Does anyone know of a way to check what programs are currently running without using flags?
Are you calling the "READ" command more than once? Each time it is called, a new line is read/
There is an "Expanded Register" option that will allow up to 2000 R's and 5000 PR's.
Here is the data sheet for the option. https://crc.frc.com/price_list…nded_Registers_(R830).pdf
