Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Relative reference frame instead of calculated?

#1
Hi,
I would like to use a relative reference frame to my user frame in the robot (my case Fanuc). Due to that i can calibrate the user frame on the robot and make this work fairly easy.

   

But in this constellation, the post-processor calculates the two reference frames together in relation to the setup in RoboDK. This means that the frame 2 is not used as reference?

Output from above:
91:  PR[9,1]=1188.150 ;
92:  PR[9,2]=-51.853 ;
93:  PR[9,3]=-262.000 ;
94:  PR[9,4]=0.000 ;
95:  PR[9,5]=0.000 ;
96:  PR[9,6]=0.000 ;
97:  UFRAME[9]=PR[9] ;
98:  UFRAME_NUM=9 ;

But what i really needs is the positions to be relative to UFRAME[2]. Is there a way to do this?
#2
I believe it is not possible to make one reference with respect to another one on a Fanuc controller.

However, some robot controllers allow you to have nested frames. It would be possible to calculate this relationship in the post processor. This requires some customization to recreate the same dependency you have defined in the RoboDK tree on your robot controller.
#3
Hi Albert.
I´m looking for the solution in RoboDk only.

The output from above consist of a calculation in robodk by PR[9,1]=1188.150 this is Frame 2 (500mm approximately position set simulation) + 724.01-00 (688.15mm absolute position from CAD).
And then when i make the program. All movement are made in relation to UFRAME[9]. But UFRAME[9] is an offline theoretically frame in robodk. Not calibrated in the real world.

What would make sense, is that the post-prossessor used Frame 2 and then added 724.01-00 to each position. Then when we move the program to the robot it uses UFRAME[2]. And since this is calibrated in the real world all the movent would work out of the box.

In my case UFRAME[2] is used for 8 different fixtures, so when we change to another fixture. We calibrate UFRAME[2] to the correct fixture.
724.01-00 is the products that must be placed in the fixture.
To overcome the way RoboDK handle this behavior we need to put in frame offsets in the "Robot Machining Project" with the values from 724.01-00 and set the reference frame to Frame 2.
Then the output from the post is correct. But the graphics in RoboDK is showing something that is not correct and there are a lot of manually adjustments that is hard to hand over to the next person that need to operate this machinery...
  




Users browsing this thread:
1 Guest(s)