March 23, 2019, 09:00:23 AM
Robotforum | Industrial Robots Community

 Settings to make Fanuc programming easier (From all of us)

Author Topic:  Settings to make Fanuc programming easier (From all of us)  (Read 17571 times)

0 Members and 1 Guest are viewing this topic.

February 05, 2017, 04:50:09 PM
Read 17571 times

Fabian Munoz

Hello all
I wanted to do this for a long time. A compilation of information that generally takes hours to find on manuals (if you can find them)
This is a contribution from of all us

I will collect the info from posts that I find beneficial (You can PM to help me)
I'm going to try to keep clean, just info, no comments, no thanks , just pure info
It will be and sticky and it will be locked.

On my first day collecting information I realized that's almost impossible to do it without modifying the original post. That brings the point that I should not copy and modify somebody post without the author permission. I'm just writing the author name to clarify where the info came from. For more clear details just search for the actual post

« Last Edit: February 06, 2017, 09:57:35 PM by Fabian Munoz »

Today at 09:00:23 AM
Reply #1



February 05, 2017, 04:51:04 PM
Reply #1

Fabian Munoz

From Nations, lexx905,RobAuto

  0    process I/O boards (also memory image)   
16    AB or Genius I/O   
32    Slave SLC2 I/O   
33    internal relay/register   
34    flag marker   
35    always on/off port   Slot 0 = OFF Slot 1 = ON
36    DCS port   
48    address mapped I/O for LR Mate Peripheral connectors
64    ME-NET   
65    INTERBUS-S   
66    PROFIBUS DP master   
67    PROFIBUS DP slave   
68    FL-net   
69    FL-net status   
70    InterBus-S master   
71    InterBus-S slave   
72    IO-LINK II master   
73    IO-LINK II slave   
74    FIPIO master   
75    FIPIO slave   
81    first DeviceNet board   
82    Used by DeviceNet   
83    Used by DeviceNet   
84    Used by DeviceNet   
85    controlnet; also used 86   
86    Used by ControlNet   
87    RoboWeld   
88    Ethernet Global Data (GE-EGD I/O)   
89    EthernetIP (ControlNet over ethernet) I/O   
90    Arclink Rack Number   
91    WTC Serial Weld Controller I/O   
92    CC-Link RD   
93    InterBus PxC PCI master   
94    InterBus PxC PCI slave   
95    InterBus PxC PCI cmd   
96    Modbus TCP   
97    TOYOPUC PC3J Interface   
98    InterBus PxC Slave interface   
99    PROFINET I/O Controller   
100    PROFINET I/O Device
101  Dual Channel Profinet I/O Controller   V9
102  Dual Channel Profinet I/O Device   V9
106    EtherCat
« Last Edit: March 20, 2019, 09:07:55 PM by Fabian Munoz »

February 05, 2017, 06:03:58 PM
Reply #2

Fabian Munoz

From  soenderhegn

To stop running program do these steps.

Step 1. UI8 enable =OFF and program Will stop.
Step 2. Pulse UI4 Cstop 200 ms and main program will start from first Line
Step 3. Send new job from plc.
Step 4. Pulse UI start 150 ms an program Will restart when UI start goes low
« Last Edit: January 10, 2018, 03:56:58 PM by Fabian Munoz »

February 05, 2017, 06:47:09 PM
Reply #3

Fabian Munoz

From  HawkME, dmbj, scotty, Jaycephus

There are a few options for "zones".

1) is reference positions, standard feature, which are not cubes, but a recorded point with joint angle tolerances. If you open up the tolerances you can create larger zones of varying shapes, but it may be hard to visualize.
2) is space check, paid feature, which is a true zone function like you would expect.
3) is DCS, paid feature, which the main purpose is for safety, but does allow you to create zones that do not trigger any stop functions, just turn a bit on or off.
4) is create your own program using $MCH_POS, LPOS or JPOS to determine the current position.

I believe MCH_POS only updates in auto mode and outputs in world coords, you would have to test this. LPOS outputs in whatever the current UF & UT is, so if you want it in world, then set UF to 0 just before reading LPOS. Also, keep in mind that if the move prior to LPOS is CNT it will trigger LPOS before the move is complete.

Set $SCR_GRP[1]$M_POS_ENB to true and use the variable:
$SCR_GRP[1].$MCH_ANG[1] replace the 1 with what ever axis you want to monitor
$SCR_GRP [ 1 ].$MCH_POS_(X/Y/Z/W/P/R) to tell my PLC the robot positions in the world.

1) $SCR_GRP[1].$MCH_ANG is live and is a functional replacement for JPOS, and is faster if you just want a single joint, as you have mentioned already.
2) $SCR_GRP[1].$MCH_POS_(X/Y/Z/W/P/R) is not live, and is in World coords only, as you mentioned, BUT it only updates at the point of a move command when running a program (auto or manual execution).

So, to effectively $MCH_POS_(X/Y/Z/W/P/R) as live data, after a manual jog may have occurred, you would need to assign JPOS or all of the $SCR_GRP[1].$MCH_ANG angles to a PR, move to that position (zero motion to current position), and then the $SCR_GRP[1].$MCH_POS_(X/Y/Z/W/P/R) values will be updated to current.

(LPOS and JPOS would be usually preferred, but I have a configuration-issue that makes LPOS and JPOS fault out, currently, so I looked into using these System variables as alternatives.)
« Last Edit: January 09, 2018, 12:43:09 AM by Fabian Munoz »

February 10, 2017, 12:50:30 PM
Reply #4

Fabian Munoz

« Last Edit: February 12, 2017, 01:37:07 PM by Fabian Munoz »

February 12, 2017, 01:36:24 PM
Reply #5

Fabian Munoz

From Racermike123

This alarm occurs when the robot positional data that is stored in the CPU does not match the positional data of the pulse coders.
Mastering is not necessarily required but it could be. As in the instance of restoring an image that has different mastering data.
I suggest jogging the robot to zero and verifying the witness marks. If all is OK RES_PCA, cycle power, set $DMR_GRP[1].$MASTER_DONE=TRUE, and calibrate

March 18, 2017, 08:45:10 PM
Reply #6

Fabian Munoz

From Racermike123

Today at 09:00:23 AM
Reply #7



January 09, 2018, 12:48:46 AM
Reply #7

Fabian Munoz

From  Jaycephus,stare284

FANUC Robots have a gigantic list of system variables, many of which are normally aren't meant to be accessed, and may not be documented for one reason or another. Many are for internal use and are read only, but some dramatically affect performance and are writable, at the least during Controlled Start, if not normal Start.

System Variables that affect performance:
$Group[1].$USEMAXACCEL - enables 'fast acceleration' feature
$Group[1].$MAX_SPEED - Not described in manual
$MCR_GRP[1].$fjog_enb - Fast Jogging Mode Enable
System Variables for Status
$MCR.$GENOVERRIDE:       This is the system variable that changes when you hit the +% and -% buttons.
The value must be decoded, according to the software reference manual, it is bit coded as follows:
     1   MFS_EMGOP
     2   MFS_EMGTP
     4   MFS_DEADMAN
     8   MFS_FENCE
   16   MFS_ROT
   32   MFS_HBK
   64   MFS_EMGEX
  128  MFS_PPABN
1024  MFS_FALM
Other System Variables (some of these can be set from System:Config, or other places in the interface.)
$CR_AUTO_DO - set for DO to indicate robot is in Auto, integer in the range of configured DO
$CR_T1_DO - set for DO to indicate robot is in Teach mode, integer in the range of configured DO
$DMAURST = TRUE - Auto Deadman reset. Teach pendant resets robot faults, enables servos as soon as deadman switch pressed when in Teach mode (T1).
$GENOV_ENB = TRUE - Speed override enabled.
$SCR.$RUNOVLIM: will control the speed globally in any program during T1 non-step mode and i believe fully automatic. So even if you set an override in a TP program higher than this system variable, the system variable will override it.
$SCR.$JOGLIM:   The percentage of system maximum speed you can jog the robot. maximum of 250mm/sec. (applies for T1 non-step and step)
$SCR.$JOGOVLIM: The global override for non-step mode T1 speed. Careful with this one as if you turn it to 100 you may see a fault occasionally because it reaches over 250mm/sec.
$SCR.$COLDOVRD:        Default speed set when you reboot the robot.
$MCR_GRP[1].$PRGOVERRIDE: - this is a programmable/secret scaling factor for override, affects programs to make them run slower even though the General Override is set to 100%. (default=100=100%, full speed)
$PARAM_GROUP[1].$SV_OFF_TIME - allow setting timeout for brake activation, per axis, as in after jogging and holding deadman. By default, brakes activate after 20 seconds.

These are only writeable when the SFSPD signal is OFF. (Either change in Control Start mode, or set SFSPD off.)
$SCR.$SFRUNOVLIM:       PROGRAM RUN OVERRIDE LIMIT (in T1 mode, use to allow 100% manual Run mode)

*Though these manual-mode jog and run speed changes can massively speed up your development time, I recommend setting them back to original settings when putting the robot into service. Inexperienced or average users could crash the robot much more easily.

$SHELL_WRK.$curr_line   contains the current line value
« Last Edit: August 22, 2018, 01:16:46 PM by Fabian Munoz »

August 22, 2018, 01:14:27 PM
Reply #8

Fabian Munoz

From Nation

In solid works, you have to setup a coordinate system to match the faceplate coordinate system, then output the COG and the moments of inertia about the COG in that coordinate system. You only need the principal axis, boxed in red in the attached image. You also need to convert solid work's output from grams*mm2 to kg*m2.

If you want to do it by hand, the HandlingTool manual goes over how to calculate moments of inertia in the payload section.
« Last Edit: February 07, 2019, 02:20:50 PM by Fabian Munoz »

October 07, 2018, 12:37:21 AM
Reply #9

Fabian Munoz

From bmello


WHEN DI[1]=(1), UI[2: HOLD]=PULSE, 0.2SEC    Hold program with UOP
PR[1]=LPOS      Write current cartesian point to position register
R[1]=1    Set register to indicate program was paused (will be used in TP program)
UI[4: CSTOPI]=PULSE,0.2SEC      Abort program UOP
UI[5: RESET]=PULSE,0.2SEC      Fault reset UOP
UI[18: PRODUCTION START]=PULSE,0.2SEC    Production start UOP


IF R[1]=1 JMP LBL[2]      If last program was aborted
IF R[1]=0 JMP LBL[3]      If last program was not aborted

L P[1: POUNCE] 250mm/s CNT50
SET R[1]=0
L P[2: HOME] 250mm/s FINE

L P[1: POUNCE] 250mm/s CNT50
L PR[1: PROC_START] 250mm/s FINE  Using the PR that was saved when the program paused
L P[2: PROC_END] 100mm/s FINE
L P[1: POUNCE] 250mm/s CNT50
L P[1: HOME] 250mm/s CNT50

February 10, 2019, 10:42:11 PM
Reply #10

Fabian Munoz

From Robo_Eng_13

1. Linear moves and their finicky speed behaviors. The way Fanuc robots calculate their speeds and apply their speed limits do not line up very well, and this is what causes your axis issues on linear moves. Your robot has a TCP linear speed limit, as well as individual axis speed limits. In a joint move, the robot compares every joint to its speed limit, and sets each to the fastest speed they can be set to and still reach their target at the same time. This means that axes traveling a short distance will move very slowly, while axes traveling a large distance will travel as fast as their speed limit allows them. With a linear move, the robot checks if the command speed is legal to its linear speed limit, then calculates the joint speeds necessary to maintain that speed across the linear move. Unfortunately, it does not check any of those joint speeds against any of the joint speed limits.

Practically, this means you have to be very careful of a lot of odd details of linear moves. The biggest thing we run into is having a short absolute distance with a large posture change. The short distance and the speed it is given tell it that it needs to arrive at its destination in a very short time. It then tries to rev all the axes to max and beyond to get to the new posture in that time limit. Then, ESTOP, fault, bad day. In so far as avoiding this goes, here are my suggestions.

A. Break up posture changes between multiple points.

B. Only use linear moves for approach, retreat, and action points. Air cuts should usually be joint.

C. Test your program at low speed and work your way up. You will get a feel for what moves will cause problems.

D. When welding, it is important to have a very constant travel speed. We solved this by using an external axis turn table and moving the part under the weld tip.

2. CNT 100 means the robot will round the corner as close to the point as possible while still maintaining 100% of its speed. CNT 50 will cut the corner a bit less, coming closer to the command position, maintaining 50% of its speed. CNT 0 and FINE in theory behave the same, but some testing a results reported here suggest they do not. FINE will go to the exact command position.

In general, similar to linear moves, you will have high CNT moves on air cuts, and FINE moves on approach, retreat, and action points.

A. Be mindful of CNT at different speeds. By their very nature, they take a different path at different speeds. We have punched a servo off of a robot because our techs were trying to cut the path as close as they could and then turned the speed up.

B. Make all reference positions that trigger a needed output FINE, or tweak their windows until it encompasses a wide drive by.

C. Again, with welding the path and speed are critical. We use the external axis to complete the entire weld in one move, rather than risk acceleration and declaration from multiple FINE moves.

Conclusions, it sounds like you are already doing pretty good. I understand feeling like you have marked C as the answer for too many questions in a row, but in this case, the answer really is C a whole lot of the time.

Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter