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

Staubli TX200 CSH8C Cartesian Coordinate moves during Run On Robot

#1
Hi Jeremy,

When trying to execute a movel or movec command with Run On Robot, the Staubli instead moves in a different direction towards a pose out of the workspace.

The observable movement looks to be performing the path that would occur if the active Frame was the robot base. I.E it appears that the reference frame is not being set properly.

However, when trying to execute moveL commands to targets configured in the robots base frame, this behavior still looks to be occurring.
#2
I tried uploading the rdk file but the add attachment seems to make the page unresponsive for at least 5 minutes, and the file size is only 78MB.

My goal is to run CircleRefFrame, which is multiple move commands with respect to the demoframe. It works well in simulation.
However when running on robot, the robot can only perform the joint move properly.
When it executes a linear of c move, the robot moves in a different direction before stalling and displaying a pop up message on the teach pendant saying that it's trying to reach somewhere out of reach.

Specifically the robot appears to execute the path of the same program, if the setref command set the robot base as the active frame instead.

CircleBaseFrame was supposed to avoid this as it uses targets set from the base frame by default, however similar behaviour appeared there also.

At one point I believe I got 1 linear move to work correctly, I am not sure how to repeat that success.

I am still trying to figure out how to get the file to you....
#3
Here's a dropbox link to the rdk: https://www.dropbox.com/s/qosagt6stt4x0e...x.rdk?dl=0
#4
Hello, have you tried using the post processor, you can generate code to run by right clicking the program in robodk and choosing "Generate Robot Program", I know this isn't fixing the issue with the driver/Run on Robot directly however run on robot will always have timing issues because the robot needs to wait at each point in a program for the next point and it prevents the robot from correctly using the rounding feature, as such it's not ideal for machining programs and our post processors that are used to generate robot programs are far more adept for it.

The default post processor for staubli should generate a folder that you can copy onto the robot controller and select like any other robot program

Phillip May
#5
Thanks for the reply.

Unfortunately the program generated in the post processor (VALSimplified), then sent to the robot, resulted in no movement and a message on screen saying the destination is out of reach of software joint limits.

To remove speculation that blending might be a cause of issue, I rewrote a small program to draw a diamond instead of circle, using just joint and linear moves. Which showed the same behavior.

DiamondRefFrame is the program that I made as an example program we want to accomplish, it works perfectly in simulation, but not on the robot itself.

DiamondRefFrame_result (made as an example) shows, quite accurately, the true perceived motion that the robot performs.
Image below (and in dropbox): the robot was supposed to linearly move downwards, not in an arc to the centre of robot base.
[Image: Screenshot%202022-03-07%20142629.png?dl=0]
This supports my theory that the setref frame is not working as intended.
By the looks of it, I might be able to execute a Val3 instruction for setting the reference coordinate with the insert call instruction, which I will attempt to do next.

Cheers,
Dan
#6
Has any progress been made on this issue? I have the same problem.
#7
Hi Phillip,

I had success with the post processor some day later.

Maybe there was something still running from the driver when I first attempted a post processed application.


I believe I also tried using the online driver to execute just a few linear moves, with no blending, but it still went to the robot base.

From your understanding, would that mean if I reattempted to operate the robot online with the driver, not using any blending, it should be able to perform simple movements with cartesian coordinates?


Thanks for your reply detailing the drivers' appropriateness for machining with consideration to timing.

Kind regards,
Daniel
  




Users browsing this thread:
1 Guest(s)