Continuous motion between program calls

    Greetings!

    I am currently working on a few new spot weld cells cycle times. One area that we could save a couple of seconds is in between program calls (from within main program, not PNS call from PLC) where the robot comes to a stop and does not follow a continuous path. Is there a way to get the robot to anticipate into the next program where it is going to go?

    An example would be a standard pedestal spot welder / material handler.

    1. PICK
    2. WELD
    2a. Run TIPDRESS (after weld, while dropping)
    3. DROP

    I know one option would be to put it all in to one program, but that would eliminate our ability to run tip dress in the background because the main program and tip dress program would both need Group 2.


    Thanks,
    Steven

    Hi
    In general "anticipate" a program number is not good. A million things can happen between the anticipation moment and the end of the program.
    Now (i've done it only once), the wrong was returning home , maybe two points before, so did not matter what happen , i was going home anyway. Meaning I was looping back to the top of the program to ask the PLC the new number.
    During those two couple of motions, I will tell the PLC that I was home, then, the PLC will tell me, program 5. By the time that robot gets to actual confirmation, the handshake was already done, so saved us less than a second but in a 6 second project thats a lot

    Usually, I will finish the job, go to the top tell the PLC I'm done , wait for PLC number, confirm number then go

    Retired but still helping

    I tend to structure my cell movements via a series of logical movement programs that monitors the last known position (Safe Moves), so i have Call MovetoHome and Call MovetoPickArea, etc..Unfortunately, even running these moves at CNT100, there is a brief pause. The ability to optimize these movements does help reduce cycle time, but I haven't found a safe way to achieve the continuous motion between program calls.
    Super curious to hear from anyone who may have found a solution to this. Fanuc is typically processing a few lines ahead, as evident by DO lines being processed in transit to a CNT move position, so I'm not sure why the pause when trying to do this.

    Quote from retobor


    How are you executing this program; a RUN command or a CALL? Have you tried it as a Macro?

    They are all being CALLed except tip dress which is being RUN. The material handling robots with a pedestal spot welder have 2 groups. Group 1 which is obviously the 6 axis of the robot and group 2 axis 1 which is the servo gun.

    CALL Pick (Group 1)
    CALL Weld (Group 1 &2)
    RUN Tip Dress (Group 2) and CALL Drop (Group 1) so that tip dress can run while the robot is dropping the part at the next passing table.

    We have a few material handlers that everything was packed in to one program so we don't see the pauses and they even put all tool and robot interference I/O directly in the main program as opposed to calling a "Enter Tool" program for example. Unfortunately, this won't work with running the tip dress program in the background, because of the group masks.


    Fabian, I'm not such concerned about the pause waiting for the PLC to call a new PNS, but rather within the PLC calling separate programs.

    PNS0010
    CALL Pick Part
    CALL Weld Part
    CALL Drop Part

    I have all of these programs starting and ending with CNT50-100 but the robot always comes to a complete stop when it completes the Pick then starts the Weld program, and Weld to Drop.

    I don't think anything has changed regarding the pause between program CALLs. I think its due to the difficulty of motion planning across different programs. Normally, certain things are locked when a program is running such as position values. So the motion planner knows that nothing will change.

    A potential solution would be if Fanuc would allow you to "group" TP programs. Basically, your CALL instruction would be like a #include in C++ where its the same as pasting the contents of the program into your main program. All programs in the group would be locked when one of them was running.

    In my case, this would be helpful to organize the code and make it easier to troubleshoot and unit test.

    I've ran into this on high speed applications where normally I send over a INT from a PLC to call every Pick/Place. I think calling between pick and place or whatever, the robot controller can't anticipate what will happen next because it hasn't happened yet or been called. Maybe restructure your program to automatically weld a part if it has been picked, because what else would you do with it. And then obviously drop the part off when the process is done. You can have the main loop call some sort of autocycle program via the PLC and do the logic conditioning for Pick/Weld/Drop inside of that as sub programs.

Advertising from our partners