Advertising

Posts by a00948630

    On an aside; will changing a payload's values programmattically on-the-fly via the above quoted $PLST_GRP1[1].$PAYLOAD=(n) system variable set mess with the motion planning algorithm that FANUC has running in the background to calculate motor torque, current draw, encoder counts/speed rates/whatever type of PID algorithm they have going on? I always assumed that changing the variable as it's being used could cause corruption of the motion planner.


    I was also not really sure about this, as when someone manually changes any value inside the payload schedule page, we get a "Path and Cycletime will change. Set it?" message, not sure it after hitting “Yes” a new calculation was made but dynamically modifying the variables could result on something like what you mention, but maybe not and this is just a warning for just entering the value and it would be the same as modifying the variables directly.


    Tests will say :P

    Hello HawkME,


    Just to let you know that I tested Mapping the UI signals to Flags and controlling the Hold and the Start via software and It's working just fine! :toothy9:


    Thanks a lot for the recommendation!
    Regards.


    :bravo:

    Hello TitusLepic,


    By looking at the PLC and Robot programs, yes it looks like the PLC is the only one that uses those signals and not the robot, so now I understand why and how.


    Thank you!
    Regards.


    :dance2:

    Hello all,


    I have a RJ3 controller and it has "I/O PLC Type" PO[] - PI[] signals that I hadn't seen before on other controllers, as reference my R30ib Plus have the normal Digital, Analog, Group, Robot, UOP, SOP, etc signals but it does not have "PLC Type" signals.






    Does anyone know what are this signals exactly?



    I know I could use digital signals but I'm migrating a RJ3 to a R30ib Plus and I'm curious on why is this not available on this new controller or how can I get them too on the new controller.


    Thank you,
    Regards!

    Hello Nation, thanks a lot for your reply!


    Quote

    It does stop motion (well, jumps to the next line if the skip conditional is satisfied, or jump to the label specified if the condition is not met.).


    Yes, I also considered using skip condition at first, but because of how skip condition works, I think this solution would not work either.



    For example, If I need a motion sequence of 10,30,50,100,XXXXX points, a normal program flow with no SKIP condition would follow the required motion sequence as normal:




    If I add SKIP CONDITION RI[1]=OFF and no part is lost/dropped during motion sequence (sensor signal = ON), once each instruction is finished and because the skip condition will not be satisfied (robot never lost the part during motion which is correct), it will jump to the indicated label instead on continuing with the normal program flow, so now I would need to do something like this:




    This makes program control harder plus adds a lot of labels and jumps on big program sequences, but also does not fix the issue as I don't want to cancel the current motion at the middle without reaching its final position and then moving to other point from any interrupted/unknown position, I just want to "pause/hold" its current motion, take actions based on operator selections (no motion of course), and then to continue with the current motion and normal program sequence.



    ¿Is there maybe any other way to do it? or ¿what do you think?


    Thanks again.
    Regards!!
    :merci:

    Hello everyone,


    I'm currently programming a FANUC robot with R-30iB Plus controller and I would like to ask for your advice on how to get around the following situation:


    note: The following examples are not the real programs under development, this are just simple test programs to represent and explain the situation.


    As an example, I have a main program moving indefinitely between two point (i.e. A: Home Position and B: Pick Position).
    I also start a condition monitoring at the beginning to check for a sensor -> The idea is, if the sensor signal is lost (i.e. part dropped), do something...




    MAIN_TEST

    Code
    1. 01: !MAIN TEST
    2. 02:
    3. 03: MONITOR COND_MON
    4. 04:
    5. 05: LBL[1]
    6. 06:L P[1:@HOME] 100mm/sec FINE
    7. 07:L P[2:@PICK] 100mm/sec FINE
    8. 08: JMP LBL[1]



    Condition monitoring program is very simple, just check for sensor signal OFF, if so, call program to take actions.


    COND_MON

    Code
    1. 01: WHEN RI[1]=OFF,CALL ACTION_PROG


    Here's where I need some help... What I want to do is to stop (no abort) the current robot motion as soon as the sensor signal is lost:
    I first send the error code to an external EtherNET HMI so It can display the correct error screen with it's corresponding error correction options, then I wait for the operator to select the desired option (i.e. Drop Part, Ignore, Retest, etc).


    note: I know a similar decision logic can be done via "Menu Utility" but it needs to be done this way (External HMI via EtherNET), not from the TP screen.


    During this time, the robot motion must remain stopped but the logic running, waiting for the operator selection plus executing the upcoming corrective actions.


    I started to look for different options to stop the motion and found that setting "$MCR_GRP[1].$HOLD" TRUE interrupts/holds the motion immediately and clearing "$MCR_GRP[1].$HOLD" FALSE resumes the motion.


    ACTION_PROG


    The problem is that after the $HOLD variable is set back to FALSE, it correctly resumes the previously interrupted motion (finishes the point) but it does not continue with the next line in the main program and stays there...


    So for example, if the sensor signals goes OFF while executing "L P[1:@HOME] 100mm/sec FINE" instruction, it will hold motion as soon as "$MCR_GRP[1].$HOLD" is set TRUE and it will resume motion and finish the point (reach @HOME) after "$MCR_GRP[1].$HOLD" is set back to FALSE, but it will not continue with the following line "L P[2:@PICK] 100mm/sec FINE" or loop.


    As you can see on the following image, the program flow already returned to Main program (after sensor went off and corrective actions were taken) and the robot reached @HOME ("$MCR_GRP[1].$HOLD=0") but it stays on line 6 forever, even when the TP says that the program is running and all the status seem to be OK...





    I just picked $HOLD variable as it does (kind of) what I try to archive, but the real questions would be:


    :help:1. I'm I missing something to make the program run again after $HOLD variable was set back to FALSE and held motion finished? (current approach).
    :help:2. Is there any other way (any other variable, any other signal) that I can use to also hold/stop/interlock the robot motion until I give release back?


    note: I tried using UI[6] *HOLD signal to stop motion as soon as PLC receives GO[1:FAULT CODE] but that would trigger "HOLD signal from UOP Lost" alarm on the TP, requiring me to reset and hit start again, not desired... I just need to hold current motion, present situation on HMI, operator press an option, and motion continues, no reset, no start, just continue...


    :help:3. Is there a way to just hold motion with UI[6] *HOLD signal without an actual alarm being displayed?



    I was also thinking on running this "WAIT FOR OPERATOR SELECTION" logic separately via RUN or BGLOGIC with "Ignore pause = TRUE" option so it could run even after a PAUSE instruction gets triggered from ACTION_PROG (stopping motion too) but I would now need a way to resume the program VIA SOFTWARE without an actual start button hit..


    :help:4. Is there a way (a variable or something) to resume programs execution after a PAUSE instruction was used that I can write to?



    :help:5. Or based on what I'm trying to archive, do you have any other recommendation to get around this situation?




    Thanks a lot in advance for your reply!
    Regards!


    Hugo.
    :merci: