Hi,
When people refer to background logic in a fanuc robot. Are they referring to macros or the PMC? Or is it something else?
Thanks.
Hi,
When people refer to background logic in a fanuc robot. Are they referring to macros or the PMC? Or is it something else?
Thanks.
I think you are talking about bglogic.
Is a code used to work in background. For example I use bglogic to check continuously if the range of tool is correct.
Background Logic is TP programming that continually loops in the background, much like ladder logic. Set in Menu > Setup > BGLogic. Now there are a lot of rules to it. No motion, mixed logic is a must, any jumps must be down never up, & many more. Very useful, I use it a lot.
Thank you both for the answers.
Would this be the place to write checking logic for an auto home routine?
Or would this be better structured in the TP program?
Thank you both for the answers.
Would this be the place to write checking logic for an auto home routine?
Or would this be better structured in the TP program?
Depends what kind of auto home routine you want to use. If you want to check the logic conditions for the entire program runtime, background is your best bet. You could also use monitor condition instruction.
What is monitor condition instruction?
I was thinking about using the current position instruction, but using this do I have to create multiple zones within the whole cell?
For instance: current position is within cube #1, then create a safe home routine back? Doing it this way I may need to have quite a few zones. Is this typical?
Thanks,
What is monitor condition instruction?
I was thinking about using the current position instruction, but using this do I have to create multiple zones within the whole cell?
For instance: current position is within cube #1, then create a safe home routine back? Doing it this way I may need to have quite a few zones. Is this typical?Thanks,
OK I see what you are trying to accomplish. You want an universal one button "return home" program. Your suggested approach is a rather tedious task to do and it's certainly off topic. I'm trying to figure out the most effortless way to do it too.
Monitor condition can be used to monitor some DI/DO/FLAG...whatever you want to check. First you need to create a "condition" subtype program, lets name it COND1 which is something like: WHEN "condition1" CALL SOME_PROGRAM_1.
Then in TP program you can use MONITOR COND1 to start monitor the condition, and MONITOR END COND1 to stop monitoring. The condition is evaluated in some background process.
For example: you are moving part from A to B. On the path from A to B you can use MONITOR instruction to assure that the part is present (on the whole path from A to B), and you can (for example) stop when the part is not present. It is a very naive example but I hope it sheds some light on the topic.
Bill,
In my opinion you should structure this logic in a normal TP program. No BG Logic, no condition monitors. Then you can either use the LPOS to create zones or if you have DCS, create them that way (I like DCS ). Depending on how complicated your cell is you could have as few as 1 or many zones. This is typical for a complex recovery routine.
The only thing left is to decide when you want to use this homing routine. You can do it automatically at the beginning/end of your program, or make it a manual selection to go home. You could also decide to not allow the program to run unless it is at home, which would force the operator to run the homing routing first.
If you have a well thought out homing routine, I like to make it automatic . Also, keep in mind that you don't have to cover every situation, you put in the logic, "If robot is not in a specified recover zone, don't do anything". Then it would force a person to jog the robot at least into one of your zones, or all the way home.
Prasolet,
Now I understand what you mean, monitor instruction. Thank for the description. I have never used BGLogic before.
HawkME,
I believe this is what I was searching for. I do have DCS on this one. At the end/beginning of the main program I will be returning home, and will also not let them start without being at (start pos/home)But in any other circumstance the operator will have a home button on the HMI. I am familiar with Lpos/Jpos, but have never implemented it.
I thought if in zone 1, jmp to prog-X, if in zone 2, jmp to prog-Y, etc etc. That is the easy part I think. My main concern is does the Lpos/Jpos instruction effected differently if I have say 4 different user frames?
Thank you
I prefer to use DCS zones, set to 'not-stop' for the stop type. Then you can tie the status of the DCS zone to a DI and check if you are in that zone.
The alternative is to use LPOS/JPOS. Effectively this does the same thing, but you won't be able to see the zones visually on the teach pendant, like you could with DCS and 4D graphics. When you record LPOS into a position register, it is relative to the currently active UFrame and UTool. So in your homing program you would first set the active frames, then do all of your zone checking, then finally call the appropriate recovery path. To make it simple I would make all of your zone checking happen in one UF and one UT.
On my last system running 2x LR Mate 200iD, I setup one of my more complicated homing/ park routines. Since we were using 2 robot to pick from 1 pallet and present to 1 laser and then place on a tester that is operated by a 3rd robot (Scara). Since I was using both a I/O bit for intent to go to a location along with position reference I/O for each of the location.
So each homing program checked the I/O of itself and the Jpos value of J1 to see what it was needing to check. If it was over the pallet it would need to take it's current location and set Z = 0 to raise it above any parts on the pallet then retract to pallet perch. Before moving it had to check if the other robot was at the pallet or going to the pallet if it was then robot 1 couldn't move, and would require manual jogging as one couldn't tell if the robots were intertwined.
The program did this for 4 different zones. It would handle parking from about 90% of possible locations the robots could get into while running correctly and being just down abruptly. They would park themselves at the end of each program. I could have gotten it to work with all possible positions but it would have taken another day or two to write out all the extra error checking and location calculations.
That being said homing programs could be quite complicated depending on the complexity of the robot's work envelope.
I will most likely be using the DCS to check. I feel better about it this way.
Thank you all for the examples and function descriptions. This is helping me quite a bit.
Very much appriciated.