Software Request to Fanuc - the robot forum bugs and wish list

    Missing explanation for a "pretty confusing" statement in B-83184EN/13 Dual Check safety Function:

    What does the statement Vertexes are duplicated in Cartesian Position Check Function (CPC) using Method "Working zone (lines)" mean? What has been duplicated?

    I figured it out by try and error. It indicates that 2 or more of the vertices are identical and therefore invalid. Choosing Method "Working zone (diagonal)" shows Invalid zone is enabled which also isn't mentioned but - at least - is understandable! :unamused_face:

    Quote from HalbesYoyo

    Missing explanation for a "pretty confusing" statement in B-83184EN/13 Dual Check safety Function:

    What does the statement Vertexes are duplicated in Cartesian Position Check Function (CPC) using Method "Working zone (lines)" mean? What has been duplicated?

    I figured it out by try and error. It indicates that 2 or more of the vertices are identical and therefore invalid. Choosing Method "Working zone (diagonal)" shows Invalid zone is enabled which also isn't mentioned but - at least - is understandable! :unamused_face:

    is this a question or a Software Request?

    Quote from HalbesYoyo

    The information on PAYLOAD under Payload Estimation and MENU > SYSTEM > MOTION are different and the second one also is extremely confusing:

    BTW: What is kgfcms^2? -> Help with payload inertia

    I'm pretty sure there are others out there who would like to see this changed!

    Wrong thread, but: Set the system variable $SI_UNIT_ENB to TRUE to show the payload data in SI units (kgm²). This makes the values a bit more understandable.

    Detection is also possible using TP instructions. I wouldn't call it "official," but I've been using it for years. Can even get it down to one line if you want. The system variable "$NULL_CYCLE" is always 0 for a virtual robot and non-zero for a real robot.

    Set up a line like this:

    IF ($Null_Cycle>0),F[5:Real Robot] = (On)

    Just make sure to initialize F[5] back to off somewhere.

    Hi Erik Olsen

    IF ($Null_Cycle>0),F[5:Real Robot] = (On)

    I gave this advise years ago here inside froum :smiling_face:

    Thread

    VIRTUAL ROBOT DETECTION

    Hi every body, i would like to know if there is a way to detect by the karel code if the robot is virtual or not ? (for example in ABB controller we can use RobOS())

    Thanks ahead
    i_robot72
    June 21, 2022 at 5:07 PM

    But I think we need official way!

    An since sysvars aren't accesscible on R-50iA, there is a need!

    Quote from PnsStarter

    An since sysvars aren't accesscible on R-50iA, there is a need!

    How does that work? Do sysvars still exist in the same way, but are now just inaccessible through TP code and Menus? Are they accessible through Karel? (or python?) Or have they drastically changed the OS?

    I've been trying to get my grubby hands on an R-50iA controller for a while now, but it looks like I won't get to check things out until next month with RG V10.

    Quote from cattmampbell

    Will the Variables Menu (accessible via MENU > 0 -- NEXT -- > 6 SYSTEM > 2 Variables) exist on R-50iA Teach Pendants?

    No, sysvars are not accessible anymore.

    Quote from cattmampbell

    Will lines of Teach Pendant code like IF ($NULL_CYCLE>0),F[5: Real Robot]=(ON) ; work on R-50iA?

    No, they will not work!

    There is a (growing) list with so called DataID's. Using of these ID's is possible through karel,python and TP.

    Access is the same like sysvar.

    But the will get more useful names and they are curated by fanuc:

    System VariablesData IDs
    $MNUFRAME $USERFRAME.FRAME
    $DMR_GRP[a].$MASTER_COUN[b]$MASTERING.MASTERING_COUNT[a,b]
    $SV_INFO[a]. $AXIS_POS[b]$SERVO_FEEDBACK.POSITION_JOINT[a,b]
    Quote from PnsStarter

    No, sysvars are not accessible anymore.

    PnsStarter How disappointing!

    Do you know if *.va files still exist with R-50iA Controllers?

    Quote from PnsStarter

    No, they will not work!

    This is also disappointing!

    Do you know if KCL Commands are still executable via *.cf files, *.cm files, and/or the Web Server with R-50iA Controllers?

    Quote from PnsStarter

    There is a (growing) list with so called DataID's. Using of these ID's is possible through karel,python and TP.

    Access is the same like sysvar.

    This is somewhat of a relief, though also frustrating as many people (like myself) do not have: access to (or a license for) RoboGuide, access to the KAREL compiler (ktrans), access to the software add-on required to modify KAREL on the Teach Pendant, and I imagine that the ability to execute and/or modify Python on the Teach Pendant will also be a software add-on.

    Quote from PnsStarter

    But the will get more useful names and they are curated by fanuc:

    System VariablesData IDs
    $MNUFRAME$USERFRAME.FRAME
    $DMR_GRP[a].$MASTER_COUN[b]$MASTERING.MASTERING_COUNT[a,b]
    $SV_INFO[a]. $AXIS_POS[b]$SERVO_FEEDBACK.POSITION_JOINT[a,b]

    Are the Data IDs a one-for-one match for each writable System Variable?

    I am struggling to see the benefit of removing System Variable access on the Teach Pendant in exchange for these Data IDs.

    I imagine a lot of knowledge may no longer be transferable, much third-party software may no longer be functional, and many programming standards are no longer applicable without the ability to read/write System Variables in Teach Pendant code.

    This is obviously a big change. Do you know the thought process behind this decision?

    I'm sorry for all of the questions, but I would greatly appreciate any insight you might be able to provide.

    Edited once, last by cattmampbell (March 26, 2025 at 1:34 PM).

    @cattmampbell

    I think that's a good decision ! In the past, freelancers as well as system integrators have manipulated or changed the sysvars without any sense or reason. Mostly the sysvars are parts of structs with and without dependencies to other vars. If I now only change one element in the structure but not the “whole object”, there are problems!
    This is prevented with the DataIDs!
    It is important that Fanuc expands the list, listens to customers and maintains it cleanly!

    Quote from PnsStarter

    @cattmampbell

    I think that's a good decision ! In the past, freelancers as well as system integrators have manipulated or changed the sysvars without any sense or reason. Mostly the sysvars are parts of structs with and without dependencies to other vars. If I now only change one element in the structure but not the “whole object”, there are problems!
    This is prevented with the DataIDs!
    It is important that Fanuc expands the list, listens to customers and maintains it cleanly!

    "without any sense or reason" is a little bit of a stretch. The only time I willingly go looking through system variables is when Fanuc neglects to expose those features through a dedicated option, instruction, function, menu, etc. Cleaning up the system variables is a good idea, but the new solution shouldn't remove anything we currently have access to with a workaround.

    • New

    Can SRVO-018 (Brake Abnormal) be changed to SRVO-666? Because it’s straight from the pits of electro-mechanical hell. This fault does not simply occur it manifests, often during peak production hours. This error is less of a fault and more of a curse. It is nearly impossible to trouble shoot whether its a faulty servo amp, cable set, motor, or most chillingly a quantum overlap of all three.

    • New

    • Excessive Brake Current:

      The fault message signals that the servo amplifier detects an abnormally high current flowing through the brake system, which is an indication of a problem.


    • Brake System Issue:

      The brake system is designed to stop the robot's movements when commanded. When the brake is engaged improperly, it can cause the robot to stall, jerk, or not move as expected.


    • Possible Causes:

      The fault could be due to a short circuit in the robot's internal wiring, a faulty servo amplifier, or a problem with the physical brake mechanism itself.


    Troubleshooting Steps:

    1. 1. Check Cables:

      Examine the robot's connection cables (especially the RM1 cable) for damage or short circuits.


    2. 2. Inspect Mechanical Components:

      Look for any issues with the brake mechanism on each axis, such as physical damage or binding.


    3. 3. Test Servo Amplifier:

      If the issue persists, the servo amplifier may need to be replaced.


    4. 4. Consult Documentation:

      Refer to your FANUC robot's specific manual for detailed troubleshooting procedures and error code explanations.


    Important: This is a serious fault that can cause damage to the robot if ignored. It's crucial to address the issue promptly to avoid further

    • New
    Quote from PnsStarter

    Hi Erik Olsen

    IF ($Null_Cycle>0),F[5:Real Robot] = (On)

    I gave this advise years ago here inside froum :smiling_face:

    Thread

    VIRTUAL ROBOT DETECTION

    Hi every body, i would like to know if there is a way to detect by the karel code if the robot is virtual or not ? (for example in ABB controller we can use RobOS())

    Thanks ahead
    i_robot72
    June 21, 2022 at 5:07 PM

    But I think we need official way!

    An since sysvars aren't accesscible on R-50iA, there is a need!

    I think this is solved. I don't have a real R50iA/V10 robot controller to try it on, but it appears to work in roboguide.

    The DataID: $STARTUP.IS_VIRTUAL_CONTROLLER

    Also, for robots between V8.4 and V9.4 you can access $[ATSHELL].FRVRC as an alternative to NULL_CYCLE for checking if the robot controller is real or virtual.

Advertising from our partners