Posts by Teacrab131

    There are 3 things you have to make sure for a robot to go where it's meant to go and how it's meant to go there.

    Correct Zero Mastering ("Home Position" for Motoman)

    Using Correct Tool and User Coordinate.

    Using Correct Motion Instruction/Jogging mode.

    User coordinates should be perfectly aligned with the physical object in space, with the Z axis perpendicular to what you have calibrated it to. If it isn't, check if you are jogging in "UserCoordinate" mode and if you are using the correct User Coordinate for that object.

    FTP functionality on Motoman robot can be a bit wonky.

    There are numerous parameter related to this function and even after following strict procedures given by Yaskawa I was not able to successfully FTP some of the robots I've worked on.

    Though, on my last project, I'm able to do so without altering any settings on the robot. But, you need to ping the robots before starting the FTP process, and only start the FTP process once pinged successfully, and it will generally work.

    I used Python with its ftplib package. Not sure if you are using other forms of FTP.

    If your robot is equipped with SUB interpreters, you can use PSTART and PWAIT instruction in your robot jobs to manage multiple running programs - which can be used to simulate the "background" job. Multi-Threading, have you.

    I believe YRC1000 is equipped with 7 SUB interpreters(can execute normal robot job) by default. "Background" Jobs are called SYSTEM JOBS(only capable of executing logics) and is usually not included by default.

    thank you for your fast answer.

    actually, I don't need to edit the TCP. and yes you are right they are all TCP with respect to...

    But for example in KUKA there is the ability to show the actual position with respect to TCP. in other words my TCP will be the reference. and that is very helpful in teaching some difficult objects.

    I don't think you are asking the right thing.

    When you reference your TCP as the coordinates system... what then, is going to be the point in that coordinate system, that gives you its position data as the feed back?

    Are you asking for something like "Remote TCP(Fanuc)" or "External Reference Point(Motoman)" that's a point in space that is not connected to the robot? If so, you are looking at "User Coordinates" based on robot's world position. I forgot what it's called on KUKA.

    The point is, THE TCP, is often referring to a point that will be moving with the robot. And if that is going to be the reference coordinate system, you would have to pick another object of reference somewhere to give you the position data relative to it.


    On Motoman, you will have to create a "User Coordinate" and then program the robot with EIMOV* to enable the robot to move as if this "User Coordinate" is the center of reorientation. (A special coord mode need to be selected for this interpretation to work when jogging, the icon look like the Joint mode but crossed off with a red line)

    If you already know Python, it's not hard at all to read (ex)ioname.dat and re-organize its content into a csv(or any format for your liking) and then another script to reverse such function, taking the csv and re-organize its content back into the exact format of (ex)ioname.dat.

    The format inside of (ex)ioname.dat is very simple. They are all just text files after all.

    From experience I can tell you xlrd and pandas packages are not needed at all to achieve it. But I strictly did it to read/load the files into/from robot controllers, not sure what needs to be done for MotoSim.

    Is it tugging on its own cables/accessories?

    Is there anyone observing the robot while the issue happened of if it's filmed?

    Is there a safety box that's being suddenly activated while the robot's in it at 100% speed?

    traditional motions LIN.PTP,CIRC are part of "legacy" motion planner. KSS5x included spline blocks. KSS8.x had more additions. the most recent one was SPTP which allowed to stay within new motion planner because switching back and fort between old(legacy) and new (spline) motion planner resets motion planner and result is advance run stop.

    This is preventing me from using S-motion on many spot welders my company deploys. It kills cycle time.

    I hope KUKA makes a servogun package that supports SPTP/SLIN spot weld commands.

    But then, I wonder how well the asynchronous motions would work with S-motions...