Yep, so the below example would wait for 3 seconds for DI: 1 to turn on. If after 3 seconds the signal does not come on, the program will jump down to Label 1 and call the HOME job.
-----------------------------------------
WAITTMOUT = (300)
WAIT DI[1: TEST] = ON, TIMEOUT LBL[1]
//Move To Next Position
J P[1] 25% FINE
END
[LBL: 1]
CALL HOME
-----------------------------------------
Hello
I haven't worked too much with fanuc robots.I know how to use other robots and I am new to fanuc robot.When a condition is met, if your example is if (di1=1 and di2=1), I want to stop the robot's motion
If I'm understanding this correctly you also want to STOP the robot when DI:1 & DI:2 are ON. To do this you would use a SKIP Condition and a SKIP LBL. More information can be found in the HandlingTool Setup and Operations manual under Chapter 7 Program Instructions.
I dont leave such decisions on operator personnel. The robot operators only deal with the HMI and the controls I have implemented through the PLC. I dont even let them choose the production program or cycle start. I use recipies that directly store every variable the robot needs, to choose the correct program.
Recipies take care 90% of the decisions. I also use RSR services to start the robots remotely. When the operator loads the desired recipe, the RSR program goes through a switch case logic to decide which production program to start based on the selected recipe. All this does not require any particular experience on robots.
If you check my original post, the Home routine uses a pretty sofisticated branch logic to decide how to go to home based on the cell's current equipment. This way the operator only needs to know how to navigate through the HMI pages and press "HOME" to home the robot. It goes without saying that when you add a new fixture or equipment inside the cell you will also need to modify your background logic to add one more danger zone and your home routine to calculate one more exit move based on the new equipment/fixture added.
Usually, when a customer needs to make additions to a cell they always contact their intergrators. If an employe of a company has the skills to modify a robotic cell by adding new equipment and integrate it to the system (=integrate it to the machine controller/PLC controlling the system) I can assure you he can modify the home routines too, or easilly learn how to do so.
They can add as many processes as they want as the home routine is not subject to the currently running program but only to solid fixtures and equipment inside the cell.
Thank you for the response. Sounds like a good practice to get into. Will definitely start a slow transition to a system like that (at least on the robot side for what I'm responsible for) going towards the future. I've been looking for something new to tryout!
Thinking it all through I have some concerns going this method though...Let me ask the question: Have you (ps0f0r) ever had issues with any end user getting stuck or not understanding how the robot goes home? I'm asking because I feel like, even though breadcrumb trail isn't always the best, it would be better(?) for troubleshooting with Maintenance personnel? What are your experiences with that? I'm thinking at least with breadcrumb trail anyone can pick up the TP and read, "JMP OK...goes to this label here ok...then it jumps to home position and goes there, ok..."
Maybe the point is, don't let them have to think or read anything - just work?
Have you had any experience with customers who may not be as experienced with robots, but plan to add equipment or processes later on that would require them to make additions to the home routine? Are they on their own then to figure it out themselves? Pay you more money to come out and add stuff in? Just asking out of curiosity because my mind is sometimes a dumpster fire of What If's 
That's what I'm saying
Thanks for great explanation of groups. I do have 1 robot and masking is set correctly (1, *, *, *, *, *).
Huh, well if you do have the correct group masked inside the job using the PR then yes that should be working...I know I've ran into this before when making a home program a while ago. I promise you it was an issue with my program and NOT Roboguide. I am kicking myself for not remembering what the darn problem I had when getting the INTP-311 before when everything seemed all well and good...
maybe I took notes...hmm...
Display MorePay 2 minutes trouble to read my orginal post
You don't need DCS, only a well defined BackGround Logic routine to check your TCP location. Use Diag_GRP[1].CUR_TCP_X, Diag_GRP[1].CUR_TCP_Y, Diag_GRP[1].CUR_TCP_Z system variables. Use your own DOs depending the TCP Location. Create a home routine and use those DO signals to safely exit any danger zone (defined in the BG logic) and return home. BG logic will constantly update those DOs based on its current TCP location. Each time you will call your Home routine, the robot will use some branch logic (IF-ELSE) based on the signal ON from the BG LOGIC to decide the exit strategy and safely return home. You can even use CUR_TCP_W, CUR_TCP_P, CUR_TCP_R which represents your TCP orientation to better define your danger zone. Or you can use Space Function which is a standard function although I find that creating my own Space Function is a lot more reliable than the embedded space function that has a lot of bugs (especially when using continuous turn axis).This is a sample code that defines 3 "hazard zones" for my robot and constantly checks for them.
IF ($DIAG_GRP[1].$CUR_TCP_X<1050) THEN
DO[4:ON :out of space wheelstabl]=ON
ELSE
DO[4:ON :out of space wheelstabl]=OFF
ENDIF
IF ($DIAG_GRP[1].$CUR_TCP_Y<700) THEN
DO[35:ON :out of space bench]=ON
ELSE
DO[35:ON :out of space bench]=OFF
ENDIF
IF ($DIAG_GRP[1].$CUR_TCP_X<(-90) AND $DIAG_GRP[1].$CUR_TCP_Y<(-700)) THEN
DO[3:ON :out of space barrel]=OFF
ELSE
DO[3:ON :out of space barrel]=ON
ENDIF
Gotcha, yes that makes sense. And the nice thing is it will always update and an operator or inexperienced user can't just turn off or on one of the outputs used, so therefore it makes it idiot proof, for lack of a better term.
Thanks. How do I properly set up PR? What is group masking used for?
Well the PR[100]=LPOS should be doing the trick, that is grabbing the robot's current linear position and config and placing it into PR[100]. The Group Mask is setup in the Job Details page. SELECT -> cursor to job -> F2 for Detail -> Group Mask (*, *, *, *, *, *) or however many asterisks there are. Under the Group Mask you set an asterisk to a 1 using the function soft keys. What this tells the robot is your job uses only the group masked in the job.
So if you have lets say two robots on one controller with a turntable, you have 3 groups (Robot 1 = Group 1, Robot 2 = Group 2, Turntable = Group 3). If you need a job that only spins the turntable 180° from side a to side b, you would MASK the ROTATE_TT.TP job to Group 3, so it would look like: Group Mask: (*, *, 1, *, *, *). Any PR's you have inside the ROTATE_TT.TP job will only write to Group 3 of the PR. So if you had PR[100] in that job you would only use data for Group 3 of PR[100].
Not sure if you have multiple groups, but if you do check that they are masked correctly. Even if you have only 1 group, you still need to make sure it is masked to the job, so the robot knows which group to place the data into. Hopefully that makes sense, I can explain better if need be - I don't always do the best job...
I understand that no software is perfect. It's just that I'm getting errors which I shouldn't be getting.
For example "INTP-311 Uninitialized data is used". No matter what I done with register, I was getting this error every time, when function was used in program with input parameters, then suddenly it start working, with no change in the code.
CodeDisplay MoreHome program: CALL INPOSITION(210,100,50)) Program INPOSITION: UFRAME_NUM=1 UTOOL_NUM=1 R[100]=0 PR[100]=LPOS IF (PR[100,1]>AR[1] AND PR[100,2]>AR[2] AND PR[100,3]>AR[3]) THEN R[100]=1 ENDIFWhen I deleted input parameters for program call, it was working and replaced AR with constants, it was working.
Agreed, no software is perfect. I've blamed Roboguide many times thinking it was their fault, but every time it has turned out to be mine, that's what I'm getting at. Every time I've received Uninitialized data it's because I didn't setup a PR before hand or I didn't have the right GROUP MASKED to the job.
Use *.ftx , and compress it to .tx，the example FORM and.ftx in the Roboguide OLPC ，you can build up them,than try to change the code, the text message in user2. the mean can use direction key to display those item.
Sweet I'll check that out - thank you. I've been skimming through the KAREL manual for days now picking out what I need and trying it out. This will save me some time for sure.
Tom, just as the last 2 posts have said.
You create enough DCS zones (or LPOS "zones") to handle each situation needed. I prefer DCS zones because they can be seen visually on the teach pendant so are easier to setup in my opinion, but they achieve the same result as checking the LPOS.
Right, sorry I missed that as I skimmed through. Too bad my current robots have neither DCS nor 4D (it's a very strict budget project...) I can get creative with the basic interference check I twisted their arms to get for the robots possibly or setup all the LPOS boxes...Thanks for the information.
Sorry everyone I don't check back here as frequent as I should...
correct.
But 9 lines should be enough. whta do you want Display?
So I want to display info of what my KAREL program is doing: "Set PR[count]'s info to PR[new]". It would be great if each iteration of my loop could be shown, but with the limitation of 9 lines, only the last 9 lines show. It's just feedback for the user of my KAREL program so they can see what is going on. I guess in the end they'll be able to see what happens when they check PR list. Idk I just like to over complicate things sometimes 
You could write your full log to a text (.dt) file on the robot, then read from that text file to the user screen. Either require a key press to show the next 9 lines of info, or put it on a timer (while .dt file has more lines, read 9 lines from the text file, write them to the user screen, wait 5 seconds, loop).
This is a good method, I'll look into it. Thank you TitusLepic!
WRITE (CHR(128),CHR(137))
I'm not bright enough to understand if this is serious or joke hahaha
Display MoreAgreed. I do not like the Register only method. Instead I prefer to examine the current position and state, then make a decision.
Several options for the robots current position in order of my preference: DCS Zones, Ref Positions, LPOS, JPOS
Then in your homing program you examine the current position (could be in combination with IO state) and then select the correct path to move to home. IO or Registers would be used for secondary information only, such as if there is a part in the gripper, etc.
The benefit of this is that it is completely independent of the program logic. You don't have to worry about forgetting to change a register if the program is modified and you don't have to worry about someone jogging the robot. In my opinion, coupling homing logic or safety logic to process logic is always a mistake. Inevitably it will get into a different state than you anticipated and you will end up crashing the robot if you only rely on the process logic setting the correct register at the right time.
This is good information, but I'm curious about a couple things: I get using DCS Zones to see if robot is here or there, but once you've determined you are inside that DCS zone are you then using LPOS to see where the robot is inside that Zone? How are you determining then where the robot is compared to the programmed position(s) to bring it home? Do you query each point of the program and see how close LPOS is to each point? Saying that out loud to myself sounds silly, so I know I'm missing something very obvious...Thanks for any input you can/may provide. I'd love to replace my lazy use of the breadcrumb trail (i.e. register setting). I definitely have seen where it can fail to do its job.
Pretty reliable on my end to the point where I can dump and go my .TP, IIC, DCS, Registers, etc etc. It's like having a robot controller in front of you. Usually when I receive the alarm codes you mentioned it is MY code that is wrong. Make sure you initialize your Position Registers before using them. I will go into the Pos Reg list and type in all zeroes to XYZWPR to initialize the PR I want to use. You can do it in code to by using PR[x] = LPOS-LPOS, which will do the same thing as manually typing in all zeroes.
As far as INTP-106: Continue request failed - If you're trying to go backwards in your program to another point and that point has a WAIT (for example) after it, the robot will not back up behind the WAIT statement.
To put it bluntly, there are reasons you are receiving those alarms and it is probably not the virtual robot controller. Keep researching and learning and definitely ask questions! We are here to help!
Hi all,
Diving in to the KAREL world and writing my first program to copy and paste PR's and their comments from one spot to another. I want to show information of the operation, so my co-workers can understand what happened. It seems though if I write more than 9 times to the USER screen the information is cut off. I'm writing "Set PR[count]'s info to PR[new] every FOR loop. But as I said after about 9 loops the remainder of the WRITE's are not displayed.
How can I allow more WRITE's to happen on the USER screen? Is this even possible? Am I doing something wrong?
Thank you for any help that may be provided,
TomFoolious
EDIT: Looking at the Handling Setup and Operations manual, it seems that a max of 9 lines can be written to the USER screen.
Any luck finding a description for your feeder alarm fault? I'm not sure how else to help until we understand what the robot is telling us about the feeder.
Correct, don't forget to use the port CD38A..
Not sure what experience you've had, but I don't think I've ever needed to worry about which port I've used. Is there a difference between them?
To clarify, when I said I don't update software, I meant on the real robot.
For Roboguide, I will update periodically.
Ah yes, definitely. One time though I was instructed from FANUC with no hesitation after telling him my software version to update, immediately. That's the only occurrence I've had though. Other than that the software version the robots have come with have been fine.
EDIT: I would investigate the fault you are receiving. Look up a manual for the lincoln feeder you are using and check the faults. Other than that you can carry on to my original response below.
Yeah looks like with that software version you only have access to Arc Start, Weld Point and Arc End . That's no problem. Looks like after Arc Start and Arc End, the number within the brackets, is the Schedule number. Also looks like each schedule defaults to 200 or 300 IPM (under Data -> F1 (Type) -> Weld Schedule).
If that's the case, you should be seeing wire...When you attempt to run the program, do you see the DO command go High when issuing the Arc Start? You may be able to split the screen with Shift + Disp button -> Double.
I never update. If it ain't broken, don't fix it.
I'm quite the opposite - always looking out for a new roboguide update and installing. Sometimes they gift us some nice new features! The one I use a lot lately is the program drop down list on the virtual teach pendant. Sure I can hit F9 (Select) and cursor up and down on the VTP, but selecting quicker from a drop down list is more favorable to me.
What does your Arc Start line look like in your program? Are you using a schedule or doing a direct entry of the weld parameters?
Does it look similar to this?
L P[1] 100mm/sec FINE Weld Start [1, 1]
Or this?
L P[1] 100mm/sec FINE Weld Start [0, 0.0IPM, 0.000, 0.00]
If it's similar to this first one - Go to Data-> Weld Proc and setup your Weld Procedure and Weld Schedule. Hint: [1, 1] after Weld Start means use Weld Procedure 1 and Weld Schedule 1. I'm thinking perhaps if you are using Weld Procedures, maybe you didn't setup the schedule and therefore it is being given no parameters to use (no wirefeed)
If it's similar to the second one - Make sure you punch in some numbers in place of the zeroes (obviously). Highlighting each set of values, you will see a description of each at the bottom of the programming screen (near the softkey labels). Again, perhaps you haven't given it an instruction of how much wire you want to feed when welding.
It seems your I/O does work, since you are able to inch the wire. So, to me I'm wondering if you're just not instructing the wirefeeder to feed any wire when running your program/schedule?
