1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Forum
  3. Industrial Robot Support and Discussion Center
  4. Fanuc Robot Forum
Your browser does not support videos RoboDK Software for simulation and programming
Visit our Mainsponsor
IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Sponsored Ads

Help Needed: Issue with CALL SR[3] in Main Program

  • ParametricGuy
  • June 10, 2025 at 6:34 PM
  • Thread is Resolved
  • ParametricGuy
    Reactions Received
    1
    Trophies
    1
    Posts
    9
    • June 10, 2025 at 6:34 PM
    • New
    • #1

    Hello everyone,

    I'm currently working on a large project that involves calling several programs from a main program. In this main program, I use CALL SR[3], where SR[3] is a string "TEST_1".

    The TEST_1 program works perfectly when run independently. However, when I try to call it from the main program, it fails. I've triple-checked the SR[3] reference, but Roboguide isn't providing any clues about the issue. The log simply shows a "call program failed" message, and the execution stops there.

    Has anyone encountered a similar problem or have any suggestions on what might be causing this issue?

    Thanks in advance for your help!

    Quote

    Solution Found:

    After thorough investigation and multiple attempts to resolve the issue, it has been determined that the problem was related to case sensitivity with String Registers. Even though the name of the program to call and the string register matched, the string register needed to be in all caps. It appears that every program is automatically "renamed" to an all-caps version of itself. Therefore, ensuring that the string register is in all caps resolves the issue.

    Solved - the only issue was case sensitivity with String Registers.

    Edited once, last by ParametricGuy (June 11, 2025 at 4:19 PM).

  • DS186
    Reactions Received
    200
    Trophies
    6
    Posts
    1,072
    • June 10, 2025 at 7:46 PM
    • New
    • #2

    Is the same motion group (typically group 1) active in your main program and your TEST_1 program? If yes, deactivate the motion group in one of the programs and try again. You can check this under the program detail screen.

    The content of SR[3] is definitely "TEST_1"?

  • ParametricGuy
    Reactions Received
    1
    Trophies
    1
    Posts
    9
    • June 11, 2025 at 11:32 AM
    • New
    • #3

    Isn't motion group related to external axis? I'm doing some research but I can't find anything useful on program calls issues.

    I can share the ATTR of the two pieces of code, are you talking about the "DEFAULT_GROUP" line?

    The main file starts as follow:

    Code
    !main program;
    
    /ATTR
    OWNER		= MNEDITOR;
    COMMENT		= "";
    PROG_SIZE	= 434;
    CREATE		= DATE 22-02-07  TIME 17:11:58;
    MODIFIED	= DATE 22-02-08  TIME 10:17:08;
    FILE_NAME	= ;
    VERSION		= 0;
    LINE_COUNT	= 19;
    MEMORY_SIZE	= 878;
    PROTECT		= READ_WRITE;
    TCD:  STACK_SIZE	= 0,
          TASK_PRIORITY	= 50,
          TIME_SLICE	= 0,
          BUSY_LAMP_OFF	= 0,
          ABORT_REQUEST	= 0,
          PAUSE_REQUEST	= 0;
    DEFAULT_GROUP	= 1,*,*,*,*;
    CONTROL_CODE	= 00000000 00000000;
    LOCAL_REGISTERS	= 0,0,0;
    Display More

    One of the called files (TEST_1):

    Code
    !TEST_1;
    
    /ATTR
    OWNER = SHIFT;
    PROG_SIZE = 29445;
    CREATE = DATE 00-00-00  TIME 00:00:00;
    MODIFIED = DATE 00-00-00  TIME 00:00:00;
    VERSION  = 0;
    LINE_COUNT = 453;
    MEMORY_SIZE = 95400;
    PROTECT  = READ_WRITE;
    DEFAULT_GROUP	= 1,*,*,*,*;
    CONTROL_CODE = 00000000 00000000;
    Display More
  • DS186
    Reactions Received
    200
    Trophies
    6
    Posts
    1,072
    • June 11, 2025 at 12:04 PM
    • New
    • #4
    Quote from ParametricGuy

    Isn't motion group related to external axis? I'm doing some research but I can't find anything useful on program calls issues.

    Motion group 1 is always related to the robot (and e.g. an integrated rail. But this depends on the system setup). The other groups are related to e.g. external/additional axes.

    Quote from ParametricGuy

    I can share the ATTR of the two pieces of code, are you talking about the "DEFAULT_GROUP" line?

    Yes, I am talking about the DEFAULT_GROUP.

    I don't know the program structure of your programs, e.g. if you are using instructions in both programs that require a motion group. If possible, deactivate the motion group in your calling program (main program) by setting the DEFAULT_GROUP from 1 to * and then try to run the program again.

  • DS186
    Reactions Received
    200
    Trophies
    6
    Posts
    1,072
    • June 11, 2025 at 12:09 PM
    • New
    • #5

    If a program is called with a motion group which is already locked by another task/program this will cause problems. In this case, there should normally be addtional errors in the alarm log (some INTP errors). But I would say it's worth a try.

  • ParametricGuy
    Reactions Received
    1
    Trophies
    1
    Posts
    9
    • June 11, 2025 at 12:22 PM
    • New
    • #6
    Quote from DS186

    I don't know the program structure of your programs, e.g. if you are using instructions in both programs that require a motion group

    The main program doesn't have any movement, just some calls and register operations.

    Quote from DS186

    If possible, deactivate the motion group in your calling program (main program) by setting the DEFAULT_GROUP from 1 to * and then try to run the program again.

    Tried but nothing changed unfortunately.

    :exclamation_mark:This morning I tried inserting a CALL TEST_1 right before CALL SR[3]. The main program successfully call TEST_1 and when finally jumping to the next line (CALL SR[3]) I get the same error as before.

    This doesn't really make sense, does it?

  • DS186
    Reactions Received
    200
    Trophies
    6
    Posts
    1,072
    • June 11, 2025 at 12:50 PM
    • New
    • #7

    That is strange. Can you check SR[3] again or send a screenshot, etc.? Maybe there is a typo or you accidentally entered a space at e.g. the beginning of the string, etc.?

  • PnsStarter
    Reactions Received
    92
    Trophies
    6
    Posts
    330
    • June 11, 2025 at 12:50 PM
    • New
    • #8

    Hi ParametricGuy,

    Are there any whitespaces at the end(or beginning) of SR[3] value? Double check the string.

    Backdate/TP-Tools: A small collection of tools that simplify the commissioning and programming of Fanuc robots. (github.com)

  • ParametricGuy
    Reactions Received
    1
    Trophies
    1
    Posts
    9
    • June 11, 2025 at 12:58 PM
    • New
    • #9

    I checked several times for whitespaces in SR[3] as it happened to me before. I can't find anything wrong with the string though.

    The actual file name is now "Test04_1", here's a screenshot of SR window in roboguide:

    And here's the two lines of code in the main program (the first works, the second doesn't)

    Images

    • image.png
      • 16.28 kB
      • 511 × 60
      • 2
  • AnandTUD
    Reactions Received
    12
    Trophies
    2
    Posts
    42
    • June 11, 2025 at 1:17 PM
    • New
    • #10

    Could it be because of Capital letters? Please try writing TEST04_1 in SR[3] and try again.

  • ParametricGuy
    Reactions Received
    1
    Trophies
    1
    Posts
    9
    • June 11, 2025 at 1:34 PM
    • New
    • #11
    Quote from AnandTUD

    Could it be because of Capital letters? Please try writing TEST04_1 in SR[3] and try again.

    Shockingly enough, this seems to be the solution.. I'm confused though.

    The main code is Call Test04_1 which in roboguide shows as CALL TEST04_1 (all capital letters) and correctly calls the program file named "Test04_1.ls".

    Nevertheless if i Call SR[3] and SR[3] = Test04_1 it won't work unless I replace SR[3] with SR[3] = TEST04_1

    I need to dive deeper on how Fanuc handles case sensitivity, but it seems that String Registers are case sensitive while .ls programs names and calls inside of a program are not.

    Files

    image.png 9.51 kB – 14 Downloads

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics

Job Postings

  • Anyware Robotics is hiring!

    yzhou377 February 23, 2025 at 4:54 AM
  • How to see your Job Posting (search or recruit) here in Robot-Forum.com

    Werner Hampel November 18, 2021 at 3:44 PM
Your browser does not support videos RoboDK Software for simulation and programming

Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Thread Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Similar Threads

  • Any suggestion how to resolve KSS01205 Ackn.: Interpolation cycle timeout monitoring LRS_HP issue

    • Aivaras Narbutas
    • September 11, 2023 at 3:43 PM
    • KUKA Robot Forum

Tags

  • Fanuc
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download