UOP Start [Revisited]

    Alright, I'm working with an R-J3 controller. recently changed operating mode to remote, with always on UI set to ON(of course), and Pushbuttons for UI Fault Reset and UI Start. (there is also another input from plc wired to UI start)


    first time trying the new system with production, I set up the robot, switched from t2 to auto, entered interlock mode, hit UOP fault reset, and when I pressed UOP start, I received error PRIO 023 - "No ports of this type"


    I scrambled to try to get it working, and noticed that under system>config UI was enabled but "Start for continue only" was set to true. I set it to false, rebooted, and everything worked perfectly.


    Later I came back, went back to t2, changed TP programs, and once again when I pressed my UOP start in auto, error PRIO 023 came up. checked the config and it was the same as before (UI on, start for continue only FALSE).


    I know I must be missing something simple here.. :hmmm:

    Edited once, last by djogf412 ().

    One more thing to add: When in manual (T2), I can run the TP program, but if it jumps out to the condition>macro from the laser, I have to manually execute the next line after the program pause. ( I understand it must be in auto for some UOP IO to work, my point is everything works in manual)


    However, when I switch to Auto(remote), program pauses, fault reset PB works fine, but error PRIO 023 when I push my UOP Start PB.


    This has me thinking I have some setting wrong for remote to work correctly.


    I have UOP mapped. Normally Closed UI are held ON.


    UOP Enabled.


    Remote mode = TRUE.


    Start for CONTINUE only = FALSE.


    The thing that really has me scratching my head is it ran production (in remote, with light curtain working) for several hours, but when I left auto and changed TP programs, then my UOP start doesn't work.

    Check your UOP mapping to see if it is still valid and has the correct Rack/Slot assignment.


    Also look at System>Config>UOP Auto Assignment. I always set this none, otherwise if you have unmapped UOP signals it will automatically map them for you which is good for testing but in my experience can cause issues if you have an "abnormal" UOP mapping. This may not be your issue, but something to look into. You can also access it through the system variables:


    $IO_AUTO_UOP=0 (disable auto UOP assignment)
    $IO_AUTO_CFG=0 (disable auto DI/DO assignment)

    Thanks for the reply.


    I'll check the mapping again but I'm 99% sure it is correct, although I haven't tried changing the auto UOP mapping.


    Is there a difference in aborting/changing TP programs in remote mode that could cause an issue? It's just so strange to me that everything worked, then after aborting one program and loading another, my remote start PB stopped working. (UI[5] Fault Reset still worked though..)


    I've also seen several people mention BGlogic for switching remote/local. If I ran my programs in local, but just had the controller switch to remote in a macro, then back to local after remote start is given, could that work? Would I also have to manipulate UOP enable variable as well?

    Currently set as style.


    This robot has a handful of different TP programs. I set one up, check it and EOAT, then run it in auto. (this is why I just had it in local. it was simple and it worked)

    In Remote the robot waits for an init signal from the plc then calls the program according to its setup (Sytle,RSR,etc..) If you have it set for Style check the Style table and make sure its linked correctly to the program you are trying to run. The PLC sends a GI to the Robot telling it which Style to choose and then the Robot calls the program that is linked on that entry of the Style table. Sounds like Style might not be the way to go for you.


    Sent from my SM-G900P using Tapatalk

    Alright, that makes sense about the remote mode.


    One problem I have to work around is that I do not have a PLC to interface with this controller.


    I need to set up an interrupt with this laser input, but I suppose I need to remain in local, and handle the logic within the controller.

    Are you always starting the same program with the remote start? For remote start you have a method to select the program then start it. the selection methods are: PNS, RSR, Style, or Other. I always use other. Then I use UOP signals to start.


    With the Other method you define 1 program that will always be called by remote start. In this example the program is named "MAIN" and I use UI[18] - (production start) to start the robot, NOT UI[6] - (start). Using UI[18] with this method guarantees that your "MAIN" program will always start from line 1, whereas UI[6] will start the program from whatever line the cursor is currently on.


    Program Select:
    Program Select Mode: Other
    >F3-Detail> $shell_wrk.$cust_name : MAIN
    Production Start Method: UOP


    System>Config:
    Enable UI Signals: True
    Start for Continue only: True (UI[6] becomes a resume button not a start button, must now use UI[18] to start)
    CSTOPI for Abort: True
    Abort all programs by CSTOPI: True
    PROD_START depend on PNSTROBE: False

    HawkMe, I have different TP programs that I run. (no MAIN.. I know this isn't best programming practice but I'm working with what I have)


    Thanks for the info on remote / other


    you mentioned the system variable for starting the program, could i just add a line of code to match the selected PRG to that variable?


    Normal operation goes like this: a job is running, when it is time(production job changes) I switch to T2, exit(ABORT) current program, select new PRG, setup EOAT/check FINE positions, Auto, fault reset/ start (currently SOP)


    If I had that line of code for the Prod_start Var, maybe I could make sure I step through it when in manual to set the prod start?

    One last question (I think I can finally see the light lol). When programming on TP, I am only allowed to assign a Constant or Register to that variable, so I am assuming I need to use a string.


    I've never had to use strings with Fanuc. I found limited information in my manual, but I did find a section mentioning $ARG_STRING[num].$title and $ARG_STRING[num].$item[num]. I noticed the manual said not to manipulate ARG_STRING[1].


    Is this relevant?, or is there a better way to use strings with Fanuc? I've also never had to do this, but as a last resort could I just edit the programs in .txt and force my PRG names to the PROD_START variable?

    That is unfortunate, however you should be able to manually select the program in the Prog Select menu, which is probably the easiest way in your situation.


    There are many options to select a program with remote start, but they are assuming that you have a remote device to select and start the program such as PLC, HMI or even hard wired buttons/switches. The main premise behind remote selection is that you send an integer # to the robot to select a certain program. The integer can be created from a group of Boolean inputs such as hardwired DI's. This could even be done programmatically without any external device or inputs, for example, by setting a register value and using branching logic to call a program. No doubt this is much more elegant if you have a PLC or can manipulate strings.

    Yeah I'm beginning to see all of that. Fanuc seems to be a very deep system with alot of functionality, but you do need plenty of external/PLC control to use it correctly.


    I'm glad you mentioned what you did because that's exactly what I'm thinking now. I am thinking of making a MAIN prg to run with the PROD_START input. And basically all that MAIN will do is call another PRG depending on a register

    Alright so my program select works like clockwork.


    Only problem is, when the interrupt is given the robot pauses briefly, then continues to the position it was moving to, and THEN waits on the input to let it continue the routine


    any ideas? :hmmm:

    Alright HawkMe, don't roast me on this, I know I have something off here. :respect:


    MONITOR sees the laser input, and calls this Macro:


    DO[]=pulse 1 sec (I'm assuming the problem has something to do with this. This was my solution for resuming after PAUSE. Pulse goes to UI[Start].)
    PAUSE
    WAIT DI[]=ON (laser clear)
    MONITOR (turns monitor cond back on)
    End


    I am thinking it is because I am trying to use PAUSE to stop the robot movement.

    The PAUSE is actually in reference to program state. So you are pausing the execution of the program by using that Command. I would just use the waits or Ifs.


    Sent from my SM-G900P using Tapatalk

Advertising from our partners