Hi M3Power95,
this is possible. And one of the strengths of fanuc.
But you have to figure out what you really need.
In most cases I would not recommend ONE program with completely different and independent tasks. --> use RUN command and sync the tasks (or not, with flags)
I did programming with a 32 Axis controller( 4 6-Six axis robots on same rail with external axis at each tool. All with and without coordinated motion)
Check out : dual arm controller, coord motion..
best regards
PnsStarter
Display MoreHi M3Power95,
this is possible. And one of the strengths of fanuc.
But you have to figure out what you really need.
In most cases I would not recommend ONE program with completely different and independent tasks. --> use RUN command and sync the tasks (or not, with flags)
Check out : dual arm controller, coord motion..
best regards
PnsStarter
Could you elaborate on this? Also interested in this subject.
I've read that you can execute the run command and it would effectively run a 2nd TP program simultaneously to running the one you're currently on. I believe the motion group you're using for the RUN command has to be separate than the motion group for the motion group of the current TP progran that you call the RUN command from.
Is this correct? If so, is it possible to watch both TP programs executing simultaneously (ie from a double view on the TP)? Also how do you sync the tasks?
This applies to some work I'm doing as well.
I've read that you can execute the run command and it would effectively run a 2nd TP program simultaneously to running the one you're currently on. I believe the motion group you're using for the RUN command has to be separate than the motion group for the motion group of the current TP progran that you call the RUN command from.
This is correct.
And yes, you can monitor multiple programs.
This is correct.
And yes, you can monitor multiple programs.
Great, thank you! If both programs are performing motion, and I want to ensure that the programs are synchronized, can I just turn on a flag or DO in each program (for example, DO1 for PRG1 and DO2 for PRG2), and then turn those off at the end of each program's sequence?
Then I could look for the appropriate DO status at the start of these programs to ensure that the motion stays coordinated. Does that sound like the right approach?
You need to really think about if you need true synchronized motion. Synchronized motion means a single program where your points have position data for both groups and you move both robots with the same command.
If don't need that level of synchronization then I would keep the robots separate. It is much simpler to have separate robot controllers and programs.
Synchronized = single program moving both robots with the same motion instructions.
If all you need is a handshake to roughly run 2 separate programs at the same time, then I would keep them apart.
If don't need that level of synchronization then I would keep the robots separate. It is much simpler to have separate robot controllers and programs.
YES!
if you can solve the task with several robots(controllers) with just a few handshakes: buy several robots(controllers).
This is always easier to program: multi tasking debugging and monitoring is always ( on the pc as well as with robots around powers more stupidly and/or more annoying!
Multiple TPs is also always(!) better.
If don't need that level of synchronization then I would keep the robots separate. It is much simpler to have separate robot controllers and programs.
Unfortunately I don't have that luxury. I am making a change to an existing cell where both robots run of one controller, but I may need to do separate movements. I think I've figured out a way to do it with individual GRP PR updates with hard coded numbers prior to starting movement, but I'll need to test and see if it works.
Basically I'm trying to do two linear welds on a double robot cell, but I have to rotate the weld head away from a close proximity device near the weld seam. These close proximity devices are not in the same position for each robot, so I'm going to try creating PR's for each device's proximity for each robot, but only apply hard coded joint offsets on the robot that has the device nearby and leave the other robot's offset the same. I'll do the same for the other side and set the other robot's head offsets back to their normal position.
This is my preference since both of these are running in one TP program and I won't have to synch everything up, but I've never done anything like this before so wish me luck!
Good luck!
There are 2 ways to do it. Use 1 program with both motion groups, or 2 separate programs each with only 1 motion group.
You can use multi-UOP to start a PNS program separately for each robot if you choose the 2nd option.
Good luck!
There are 2 ways to do it. Use 1 program with both motion groups, or 2 separate programs each with only 1 motion group.
You can use multi-UOP to start a PNS program separately for each robot if you choose the 2nd option.
Can you elaborate on the multi-UOP option for this application?
If I understand it correctly, I believe this will not be necessary because the operator manually runs the robot each time, running a main routine and manually selecting the program to run all directly from the TP. I'll just be modifying one of these programs with either Option A (do everything in 1 program with both motion groups), or B (split the motion groups into two separate programs and RUN the 2nd one from the first one, synching the end of the 2nd group motion with flags or DO's so I don't run into anything with the other axes). These robots are on a 7th axis and there is an 8th turn table axis.
As far as I can tell, since these are synchronized robots, both motion groups are enabled for the already existing programs for Option A, the only way I know to make the robot do different things at different places using the same PR is to apply PR offsets to each group's associated PR (GP1:1,3 + 5 vs GP2:1,3 + 10 and so on for the other axie). They are both linear movements with basically just rotations about the TCP to avoid the obstacles, and currently done by single axis offsets with hardcoded numbers for the avoidance. I will just be modifying when each side does the avoidance. My current plan is to split the movement up from 2 PR's (one to start the weld, one endpoint linear move PR), into multiple PR's that are midpoints between the other PR's with more offsets. If I tell one robot to offset axis 4 at one PR but do nothing for the 2nd motion group and vice versa at the other waypoint, this "should" achieve what I need.
I don't like option B because of the other axes. If I use the RUN command for the 2nd robot from within the program of the 1st robot, I think I'd need to use flags or DO's to ensure that both motions are complete before ending the routine. If I didn't , the robot being ran in RUN could run into the turn table because it could finish its program after the program that called it, which then jumps into the table rotation routine.
Do either of these approaches sound reasonable? How would you do it, given the constraints I've mentioned?
You are right, if the operator is starting it directly you don't need multi-UOP. That would be used if you are automating the start up and select choice, for example with a PLC.
Either of your approaches could work. Without seeing the process it's hard to know which is better. With sync motion it may be difficult to get exactly independent motion, because even if you have no offset on the other robot, it could be affected by your termination (Fine, Cnt). With option 2 you may need multiple handshakes if there are several potential crash areas.
With option 2 you may need multiple handshakes if there are several potential crash areas.
Yes that is my fear as well. Effectively I'm mig welding on a V groove seam with two robots at the same time, but the customer is adding in requirements to avoid obstacles that are really close to the seam, so I have to rotate the TCP out of the way at specific points to avoid collision. Because these obstacles are in different positions for each different robot (motion group) but the original motion was synchronized without this intention in mind, that's my challenge.
The good news is that I was able to make it work once already by setting up arbitrary points along the path of the seam, but just applying hard coded TCP offsets by group for each PR. So Option A is fortunately working. Thank you for your advice!
Coord Motion is good if you have to work on the same part that is moving (by positionner or other robot), then it is necessary.
But if both robots work on static pieces and do not have other issue that being sync together, it is manageable by internal signals.
