I work for a company that does automation so I spend the majority of my time setting up new robots. Ive noticed on here guys mentioning this or that program they like to run, so Im curious how many programs are in your default list, i.e. programs you load into any new robot you are working on? Ive got a few I always load in(assuming they match the application), GRIP OPEN, GRIP CLOSE, CONV_PICK, CONV_DROP, ZERO, MOV_HOME, RECOVERY, PNS0001, PNS0002(all it does is call RECOVERY), & MACHINE. RECOVERY, PNS1, and MACHINE are basically just templates that are then massaged to work as needed. I don't have any BG pgms that I load by default but often end up creating if needed. Ive seen some pretty useful BG pgms in different threads on here so I might start using some regularly. Thanks for any input.
Default programs list
-
K-Sky -
June 10, 2016 at 8:42 PM -
Thread is marked as Resolved.
-
-
I have created a package of files that I load on all new robots. It includes the following
TP programs:
main.tp - main program template, modified as needed
home.tp - safe/intelligent homing routine, modified as needed
sys_setup.tp - sets a bunch of system variables for initial setup
macro_select.tp - works kind of like PNS but calls a macro based on the value of a GI
BG_Jogged.tp - turns a flag on if the robot has been jogged
BG_Fault.tp - sets some outputs to an off state if the robot is faultedSystem files:
DIOCFGSV.io - loads a standard IO configuration, this is a huge time saver
NUMREG.vr - loads standard numeric register comments
POSREG.vr - loads standard position register values and comments
SYSMACRO.SV - sets up some standard macros, such as home -
I have created a package of files that I load on all new robots. It includes the followingTP programs:
main.tp - main program template, modified as needed
home.tp - safe/intelligent homing routine, modified as needed
sys_setup.tp - sets a bunch of system variables for initial setup
macro_select.tp - works kind of like PNS but calls a macro based on the value of a GI
BG_Jogged.tp - turns a flag on if the robot has been jogged
BG_Fault.tp - sets some outputs to an off state if the robot is faultedSystem files:
DIOCFGSV.io - loads a standard IO configuration, this is a huge time saver
NUMREG.vr - loads standard numeric register comments
POSREG.vr - loads standard position register values and comments
SYSMACRO.SV - sets up some standard macros, such as homeWould you mind posting a copy of the sys_setup and macro_select programs? Im just curious what all you are doing in those. Are you loading DIOCFGSV just to save time on the configuration, or for all the I/O comments...or both? We seem to always bounce between local, IO link, and Ethernet so IO configurations vary, but for IO comments I could see that being a time saver, we are developing a standardized bitmap. Are you programming all points in P or PR? Our company only uses PR so even though I try to follow a basic structure my PRs vary to much job to job to have a standard PR list, but might try that for Rs. Do you have anything in place to deal with low battery alarms?. We are going to be trying something in our HOUSEKEEPING/INIT program to stop the program and alert the operator, but still allow operation. We have had 3 issues in the last year with customers ignoring the warnings and losing mastering. Thanks for the input.
-
I've attached the two programs. If you have questions on what they are doing just let me know. The DIOCFG.SV is not so much for comments, but for a standard Ethernet/IP configuration with all UI/O, DI/O GI/O, & DCS mapped. There are a few things with comments in in the IO file, but they are standard items like 'collision detected' or 'cycle stop input'. I use both P and PR depending on the situation. I use PR mainly for offsets or indirectly addressed positions and everything else is a P. I try to conserve using Registers and Pos Registers to some degree. For low battery I use the UO signal to trigger a warning message to pop-up on an external HMI. It doesn't prevent them from running, but they can't clear the warning message until the batteries are replaced and reading normal voltage.
-
Slow reply, but I was trying to figure out some of this without needing to ask, but I still got ?s. With regards to DIOCFG.SV, what are you mapping that is related to DCS? Now to the list of stuff I cant understand what are the following items doing:
JOGOVLIM(Is this the % limit when jogging manually)
PRGOVERRIDE(What is this?)
SV_OFF_TIME(Understand what it does, but not why you would adjust it)
MIX_LOGIC.$_________(I have no clue what any of these are doing)
TPP_MON(No clue)
SHELL_CFG(Im pretty sure I understand what you are doing with the system config portion, but not the program select portion)
HSCDMNGRP
JOG_IN_AUTO(It doesn't actually mean jog the robot in Auto...does it?)
UI_CONFIG(What are you doing here?)
REFPOS1(And here)Do you just load the sys_setup program and run it once, or run it every time like a housekeeping/init type of program? For your other program macro_select, what are you doing with the string registers? I still don't really even understand what they do, or how to use them. I know they like any other register where you can store a value, but that is about it. You don't have a recovery program template you use?
It looks like you have done this for quite a while to learn all these shortcuts. How long have you been working on robots, or at least Fanuc robots? Also how many new robots do you setup in an average year? Im guessing its more than just 1 or 2 with all the setup stuff you have. Thanks for the all the help!
-
I have created a package of files that I load on all new robots. It includes the followingTP programs:
main.tp - main program template, modified as needed
home.tp - safe/intelligent homing routine, modified as needed
sys_setup.tp - sets a bunch of system variables for initial setup
macro_select.tp - works kind of like PNS but calls a macro based on the value of a GI
BG_Jogged.tp - turns a flag on if the robot has been jogged
BG_Fault.tp - sets some outputs to an off state if the robot is faultedSystem files:
DIOCFGSV.io - loads a standard IO configuration, this is a huge time saver
NUMREG.vr - loads standard numeric register comments
POSREG.vr - loads standard position register values and comments
SYSMACRO.SV - sets up some standard macros, such as homeCan all these files be loaded into every controller type? I would love do something simluar, but sometimes I work with Rj3, Rj3iB, R30iA, and R30iB.
-
Slow reply, but I was trying to figure out some of this without needing to ask, but I still got ?s.See answers below, marked by '-':
With regards to DIOCFG.SV, what are you mapping that is related to DCS?
-You can map the status of a DCS check to a DI. You could then interconnect that to a DO and send the DCS status to another device (robot, PLC, HMI).Now to the list of stuff I cant understand what are the following items doing:
JOGOVLIM(Is this the % limit when jogging manually)
-Yes, default is 50%.PRGOVERRIDE(What is this?)
-Similar to the general override. Final robot speed = programed speed x General Override x Program OverrideSV_OFF_TIME(Understand what it does, but not why you would adjust it)
-This is the amount of time before an idle robot will cut servo power and brakes come on. Ever had a robot go to a position and wait on an input? If it waits too long and the brakes come on, then it will have a delayed reaction when the input does come on. Also, if you can give yourself more time when teaching points before the brakes click on.MIX_LOGIC.$_________(I have no clue what any of these are doing)
-These enable other mixed logic goodies, such as TC Online, Flags, and Markers.TPP_MON(No clue)
-This sets how condition monitors work.SHELL_CFG(Im pretty sure I understand what you are doing with the system config portion, but not the program select portion)
-Sets program select method to 'Other' and start to 'UOP'HSCDMNGRP
-Same settings available on the collision guard menuJOG_IN_AUTO(It doesn't actually mean jog the robot in Auto...does it?)
-Yes, but you must have an option such as Remote PC or Remote HMI iPendantUI_CONFIG(What are you doing here?)
-Allows remote PC to make changesREFPOS1(And here)
-Set up a reference position with a DODo you just load the sys_setup program and run it once, or run it every time like a housekeeping/init type of program?
-Just one time when robot is first installedFor your other program macro_select, what are you doing with the string registers? I still don't really even understand what they do, or how to use them. I know they like any other register where you can store a value, but that is about it.
-This works similar to PNS but with the benefit that I can start the program like a macro. SR[2] = 'Macro_'; GI[3] is appended to the end of SR[2] to make a new string, SR[1]. Then that program is called. So if GI[3] = 10, then it will call a program named 'Macro_10'.You don't have a recovery program template you use?
-No, I prefer to use a PLC for recovery routines.It looks like you have done this for quite a while to learn all these shortcuts. How long have you been working on robots, or at least Fanuc robots? Also how many new robots do you setup in an average year? Im guessing its more than just 1 or 2 with all the setup stuff you have. Thanks for the all the help!
-I have been working with them for just a couple years, but have been developing standards for my company to use on every robot. Also, I hate having to repeat my work.Quote
Can all these files be loaded into every controller type? I would love do something simluar, but sometimes I work with Rj3, Rj3iB, R30iA, and R30iB.-All of these were developed using R30ib controllers. Some of the files are not compatible with the older controllers.
-
You don't have a recovery program template you use?
-No, I prefer to use a PLC for recovery routines.Can you elaborate on this? I have come across different approaches to recovery TP programs before, but don't really know how the PLC comes into play.
-
I don't use a template for recovery because it seems to be different for every situation. But generally I do something like this:
PLC:
Monitor for error
If error occurs abort the program
If human intervention is required, send message to HMI
If auto-recovery is possible, reset faults and restart the main robot programRobot:
At beginning of main program check if a recovery has been triggered by the PLC
Initialize data, safely move home, take care of any items to get back to a known state
Then proceed as usual