Super secret variable list

    Hi gang,


    I am always amazed that when people ask for a variable to do something, a lot of you know this stuff. Im not amazed that you know it, I'm amazed that there seems to be some super secret document out there that shows what a lot , maybe most, of the system variables do.


    So I ask.. is there a document that exists already or could we as a collaborative effort compile a list of them ? Is posting this list for the group a violation against fanuc?


    Thanks, and please keep the great questions coming! Love this forum.


    -Eric

    We have thousands of users in this forum.
    I think everybody came across a problem one time where they needed a variable, then they found it and posted it
    As far as the list
    1) I dont think is a good idea to write a list (hundreds) because of copyright issues
    2) Even if you write one, we wouldnt be able to keep track. There are thousands and thousand of variables

    Retired but still helping

    This requires a person to processed messages / emails from users and published them in the topic. Another problem may arise from the disclosure of information from the manuals that belongs FANUC without their consent may not be disclosed.

    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).

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    I agree with Nation. Knowing some of these variables can make our life so much easier.
    For instance, on a thread I found: $MCR_GRP[1].$servo_disbl[9]. This one saved me already a lot of hours troubleshooting.
    I think everybody should post usefull variables so we can list them.

    Hello guys !


    Reading a couple of parameter-related topics, among this one, I notice a lot of the answers can be found in the manuals or documentation supplied by Fanuc.
    I had about the same questions, sent an e-mail to our Fanuc representative and got all the information I needed.


    I have to admit that not all information is in the standard docs, and as standard Japanese companies are not so very keen on handing over all technical info about there creation :icon_wink: However so far it has never been a problem getting the right documentation in the right way (from the right source).


    Maybe there's a difference in policy about this (we are a Dutch Fanuc integrator thus dealing with Fanuc BeNeLux) but anyway.


    Cheers !

    You can access the system variable list through FANUC's CRC website. (System Variables for R-30iB)


    =>Sign In FANUC CRC
    =>Support/Downloads
    =>eDocumentation
    =>Software Manuals
    =>V8.30 (R-30iB)
    =>Reference
    =>Software Reference Manual


    Inside the Software Reference Manual, select 'SYSTEM VARIABLE LISTING' from the index on the left side.


    Registering to this site is chargeable?


    Sent from my C2305 using Tapatalk

    Thanks regards<br />Vipin..

    Quote from vipinpunneri


    Registering to this site is chargeable?


    Sent from my C2305 using Tapatalk


    I honestly believe if your company has a Fanuc robot registered to them, all you have to do is call spare parts and they will set you up with an account for free. Also if you have ever taken a Fanuc class you can get access.

    Quote from dmbj

    I honestly believe if your company has a Fanuc robot registered to them, all you have to do is call spare parts and they will set you up with an account for free. Also if you have ever taken a Fanuc class you can get access.


    I took a class last summer and the access the students are given on the cRc site is far less than I already have working for an official integrator. I don't know if the access they are given includes access to manuals, I would guess not. Seeing as they only took a class, not buy a robot from Fanuc. Like you said though if you can show you own a robot you should have good luck getting access.

    Hi,


    I don't have access to CRC and probably my question could be answered with one System Variable.


    I am integrating system with tool changer, is there a system variable that will block possibility of manually changing current UTOOL with SHIFT + COORD?
    I want the change to always be done with a tool change macro, for reasons that I hope are obvious.


    Thanks,
    macru

    I do not know if there is a way to block the change of tool number, but you can use the variable to set the number you want.


    $MNUTOOLNUM


    Now, if you have the problem that people manipulate the TP when they shouldn't, you can install password protection option.

    So the scenario here is:


    UTOOL number is going to be set up by toolchanger program, so when the tool is changed physically the UTOOL number will be changed as well.
    Programmer will start programming and by accident changes the tool number when for example switching between different JOGFRAMES or UFRAMES.
    I want to make possible to change UTOOL number only by program command, not the Shift+Coord Menu.


    The tool changer does not have contact switches confirming which tool is loaded, just a barrel type, so programming is in charge of remembering what tool is loaded.


    Any ideas?

    You can have the tool changer program set a register with the desired tool number. Then have a background task constantly compare that register to the active UTOOL using the variable mentioned above. $MNUTOOLNUM If they don't match then set it back to the register value of the desired tool.

    FANUC Robot controllers have a very large list of system variables, many of which are dangerous to change, and may not be documented. Many are for internal use and are read only, but some dramatically affect performance and are writable, at the least during a Controlled Start, if not normal Start. Some may require a Cold Start to take affect.



    System Variables that affect performance:

    • $Group[1].$USEMAXACCEL - enables 'fast acceleration' feature
    • $Group[1].$MAX_SPEED - Not described in manual.
    • $Group[1].$CNT_SPEEDUP - Also enables maxaccel? Not clear from manual. Enabled in Alere robots.
    • $Group[1].$CNSTNT_PATH - The robot will take the same path for cartesian moves regardless of speed, limits speed override to 5% as the minimum. (COLD start required for changes to take affect.)
    • $PARAM_GROUP[1].$CP_CUTOFFOV=5 (default), sets min override speed, only active when $Group[1].$CNSTNT_PATH = TRUE, 5% is the minimum allowed.
    • $Group[1].$CNSTNTPTHJT - The robot will take the same path for joint moves regardless of speed
    • $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.
    • $MOR.$safety_stat

    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

    256 MFS_BELTBREAK

    512 MFS_ENABLE

    1024 MFS_FALM


    System Variables for Speed Override (+/- keys, used with and without shifting)

    Be aware that if $Group[1].$CNSTNT_PATH=TRUE, then $PARAM_GROUP[1].$CP_CUTOFFOV (default is 5) becomes active and limits speed override to a minimum of 5%.


    $OVRD_RATE=5 (default). Set to higher number to increase the change in value in when pressing the un-shifted +/- override keys. (10 is probably more friendly for most cases.)

    $SHFTOV_ENB=1 (default). Set to 0 to make shifted +/- override keys work the same as un-shifted.


    Or customize the shifted +/- override keys:

    $OVRD_SETUP.$OVRD_NUM_S: Set to number of shifted jumps desired, such as 6 or 7.

    $OVRD_SETUP.$OVRD_NUM: Set to number of un-shifted jumps desired, or leave as is for default un-shifted behavior.

    (When $OVRD_NUM is set to non-zero, $OVRD_RATE will have no effect.)

    Example:

    $OVRD_SETUP.$OVRD_NUM_S = 7

    - Under the details of $OVERRIDE_S, set the values from [1] to [10] to the following: -1, 0, 5, 25, 50, 75, 100, -2, -2, -2

    - This will give you the shifted increments of VFINE, FINE, 5%, 25%, 50%, 75%, 100%. Un-shifted will remain unchanged if $OVRD_SETUP.$OVRD_NUM=0.



    Other System Variables (some of these can be set from System:Config, or other places in the interface.)
    $ALM_IF.ENABLE = TRUE ($ALM_IF.LAST_ALM and $ALM_IF.LAST_UALM)
    $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.$SFJOGOVLIM: SAFETY JOG SPEED LIMIT
    $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 greatly 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.

    DCS:

    • $DCS_CFG.$SYS_PARAM: If you set this to 1, it will disable almost all of DCS. If you go to the DCS menu, it will only show your SAFE I/O connect and device, the code number setup, and the signature. Every other option will be gone. Also you will have to reapply the DCS for it to take.

    - Jay

    Edited 2 times, last by Jaycephus: added more variables ().

    Like 2 Thumbs Up 2

    One more variable hidden from this planet and only known to FANUC Japan is:


    $GROUP[i].$CRTFLTENB


    This stands for Cartesian Filter Enable. Documented nowhere, not listed on FANUC Variables menu (WHY?!) no mention of it on the net and 90% of Fanuc tech gurus are unaware of its existence. Can only be used as a program statement for enable/disable and it was suggested to be disabled by FANUC Japan after countless studies of one of my projects to solve a problem with Jerky movement on linear movement types when using continued turn. This didnt solve the problem though, merely offered a way around.


    CONTINUED TURN is still so buggy.

    Hey ps0f0r,


    Can you maybe describe the "cartesian filter" sysvar a little bit more? Where did you use it exactly and what is it doing?

    I have problems with some small corners. I cant hold the speed with the path accuracy i have.


    Thanks and Br,

Advertising from our partners