Posts by Gilldur

    I have done variants of what you are describing many times. It all depends on what functionality you want. If its just a series of MoveL you could just load the x,y,z data into a pos array and use that for movements later. If you want orientations you could use a Pose array or robrarget array to save the data. Then just make what ever instructions required to move along the data, or even a for loop could be used.

    Can you share an example of the data you need to read, are you in control of how the file is designed that you read from?

    I think the RETRY will just jump back to the RAISE. So you just do a loop.

    You can check the IO in the error handler instead and if it is solved you can jump back with a TRYNEXT instead and it would work.

    You need to configure the Gravity Alpha or Beta depending on how you position the robot. Otherwise the system does not know where gravity is in relation to the manipulator and gravity will be registered as an external force and you will get collisions and stuff.

    Configuration > motion > Robot:


    Read more about it in the attached manual.


    Not sure if you can adjust the base frame jogging directions, no one ever bothers. Just do workobjekts to be able to jog in the directions you want.


    Also make sure the robot you wanna use is ok for the type of mounting you want to use. Most are ok for floor and ceiling but not tilt or wall.

    If i remember correctly, EGM is like the most expensive software option. something like 2-4k dollars. But i could be wrong. If its not a time critical thing it should be just fine to read the current joint position with CJointT and send it as io's.


    You could just go to the position and from there read and send the data and wait for a response to accept or refuse the position.


    If you want a signal that constantly updates you could do it like palmedia says. use multitasking to set up a background task that just reads and sends constantly. The difference here compared to EGM would be the CPU usage. Not sure what update frequency you could get, if the limiting factor would be the IO communication or the CPU usage.

    Usually i use either EGM or RRI to get that kind of data our of the robot. Will also let you control the robot from a remote controller.

    Though i use TCP/UDP for the info stream.

    Look at option Externally guided motion 689-1, Robot reference interface is included in that option as well.

    Usually you see this error when there is something wrong in the EIO or MOC config. If you added a signal and the name of that signal i to long then that is enough to cause this error.

    So this is a little funny. The gear ratio is hidden. Its an ABB secret. So you can't see it in the controller unless you know how to read internal MOC data. But they didn't hide the gear ratio in the VC so you can see it in robotstudio.
    You can find it under Control Panel > Configuration > Motion > Transmission.


    I checked a 7600-500/2.55 and it's:

    219.946

    -418.772

    418.772

    -217.927

    -217.927

    -178.412

    I want to give some input here on robot motion.

    I am 35 started working with robots when i was 18. I have most of my life worked with applications like milling and water jet cutting requiring high accuracy. I moved on to laser cutting with robots. For the last 3 years i have worked in a lab for a large international robot company doing research on robot accuracy. And it is absolutely possible to get robots as accurate as cnc machines. However it requires a lot of knowledge and software that you are going to develop yourself because no company is going to share them with you.


    On that note it seems you are just trying to get the most out of standard robot accuracy. And the most important thing for you is going to be picking the right robot modell. Parallel arms are always a plus for robot accuracy, (example ABB 4400). Double bearing joints also improve path accuracy a lot, see Fanuc m20IA and M20IB for single vs double. Just general rule of thumb.

    So how do you get a quick overview on how well a robot performs? Well all robots are tested according to ISO 9283.

    You can usually find the results for each robot modell according to ISO 9283 by googling or by looking into their respective product manuals.

    The number you want to look at is "AT". That's going to be the general path error you will encounter.


    Also, most robot manufacturers offer optional extras when you purchase a robot. These are extra software's or improved mastering aimed att increasing the robot accuracy. These can offer huge improvements depending on make and modell so always make sure to get those when you buy a robot.

    Amanda.


    Looking at this code and from the Swedish comments in here i would think that this is code from a SVIA pickvision system,

    If you need help with this system the best thing would probably be to contact SVIA, now known as "ABB - Machine Tool Tending".

    Hello Gil.


    I have only worked with external axis when we have built turntables so i have limited experience. I have never seen anything that lets me set amp limits to the motor. Normally in your robotware you go to \RobotPackages\RobotWare_RPK_<version>\utility\MotorUnits\ and you find the configuration files for the motor. After that you can set torque limits on the motor and tune servo parameters but i have never seen amps... Why do you need to set an amp limit?

    So it seems there is no error in your tool. I entered your quaternions into a robot studio station and tried to normalize them using this code.


    Code
    tWeldGun.tframe.rot:=NOrient(tWeldGun.tframe.rot);

    But the function does not update your quaternions so i will assume that they are correct.

    And if i read the manual it seems that as long as the normalization error is smaller than 0.1 the tool should be usable.


    If ran your querternions like this:


    Code
    ABS(Sqrt( (tWeldGun.tframe.rot.q1*tWeldGun.tframe.rot.q1)+(tWeldGun.tframe.rot.q2*tWeldGun.tframe.rot.q2)+(tWeldGun.tframe.rot.q3*tWeldGun.tframe.rot.q3)+(tWeldGun.tframe.rot.q4*tWeldGun.tframe.rot.q4))-1);


    And the normalsation error was 0.000000059 so again i assume that your tool is actually good.


    Have you run all the BullsEye setup routines correctly on all robots?


    Try to run this code anywhere in the robot where you get the error and see what happens. The controller might act differently to my robotstudio.

    Code
    tWeldGun.tframe.rot:=NOrient(tWeldGun.tframe.rot);

    If you have just created some random tools without any orientation make sure your quaternions are [1,0,0,0] or you will have an error. They can not be [0,0,0,0].

    I have seen that error a few times. It has always been related to something in the config, usually MOC or EIO. Normally to find where the error is i would reinstall the system in its most basic form. Just a robot and robotware. No options. Then you start adding things step by step. Until it fails. This usually point you to the problem.

    Hello again.


    The S4c+ systems are nice and bullet proof but they are getting quite old. The problem with that is that most of the tuning possibilities that exist in a modern controller where not implemented yet. Pretty sure tune master won't work for that old controller.


    The 4400/L10 is a good robot and normally has some really good path performance. I am actually getting nostalgic thinking about tuning those old systems and robots. Now most likely you are having some issues with friction or axis resonance. I am thinking that you cant use tune master to fix any of that so instead i have something you can try.


    Copy paste this code into the start of your cutting routine.

    Code
            WaitTime\InPos,0.01;
            PathResol 70;
            AccSet 50,50;
            TuneServo ROB_ID,1,60\Type:=TUNE_DH;

    WaitTime\inpos will force the robot to be in compleate stop for 0.01 seconds. This is important, the robot will not like it if you tune servo parameters when its moving. (it wont break, but it will hate you).


    PathResol will change the path resolution time to 70% of its original value, this will increase the path resolution. If this value is to low you might se an error saying something along the lines of "corner path failure", you can ignore that error as long as the path is good.


    AccSet lowers acceleration and acceleration ramp. Instead of using PathAccLim it is better to use AccSet on a 4400 robot since they respond really well to the increased ramp. Values are %.


    Tuneservo command is used to change servo parameters, this is ok to do and it is well documented in the manual. "DH" tuning is the robots finite impulse respons filter, lowering the value will increase the amount of filtering, This should smooth out your path a lot. If the value is to low you will see the robot taking smal shortcuts in zones.


    This tuning is 100% safe and won't damage anything.


    As for the zones, this is data declarations.


    Code
    CONST zonedata zone0:=[FALSE,0.3,20,0.3,0.03,0.3,0.03];
    CONST zonedata zone1:=[FALSE,1,20,1,0.1,1,0.1];

    You can copy these lines into your base modules in your tasks. This will make them available to all programs in the system.


    This will allow you to use these custom zones in you movement instructions.

    Code
    ! Go from this
    MoveL p10,v200,z0,tool0;
    ! To this
    MoveL p10,v200,zone0,tool0;

    It should help you keep the speed up int he small zones.

    The abb robot will let you create custom data of more or less anything so you can get it to do exactly what you want it to do.


    And as you stated the abb "fine" zone is the one that will force the robot to stop completely, all the other zones including z0 will not force the robot to stop. But z0 is a zone of 0,3mm and the robot is quite big so its hard for it to maintain speed through the zone.


    Don't worry about your lack of experience, everyone in this forum was in your shoes at some point. Just see every day as a chance to learn something new and you will ace your job.

    What robot modell are you using? Who made the system?


    There could be a number of things causing this. I am guessing you are using the industry standard with some hanging robots, probably 1600/2400/2600. If that is the case then you should be able to go way faster then what you are right now. I normally cut with 400-600mm/s in waterjet applications.


    Its been like 20 years since i programmed motoman robots but i seem to remember them handling zones way different then ABB. I guess your cutting something other then carpets since your are using such small zones. There is a behavior in the robot when using such small zones that will cause the robot to slow down in each transition from L to C and vice versa. This will happen if you are using small zones and there is some kind of reorientation in the movement. You can get around this by making your own zonedata and increase the oriantation zone.


    Code
    CONST zonedata z0:=[FALSE,0.3,0.3,0.3,0.03,0.3,0.03];
    CONST zonedata z1:=[FALSE,1,1,1,0.1,1,0.1];
    
    CONST zonedata zone0:=[FALSE,0.3,20,0.3,0.03,0.3,0.03];
    CONST zonedata zone1:=[FALSE,1,20,1,0.1,1,0.1];


    I assume you know this but i am going to say it anyway just in case. The first two entrys in your speed data are linear speed and orientation speed for the robot the second two are for external axis. The orientation only applies when you re orientate the tool and the value is degrees per second. Now if you are using the small robots 16/24/26 then you should not have to go below 120°/s. If you need to go lower then that the problem is usually something else in the system.

    There are a lot of things you can change in the system to go faster with perfect quality. Some things are complicated and some are hard. I would recommend trying a lower acceleration and see if you can get the speed up.


    Code
    ! On
    PathAccLim TRUE\AccMax:=2,TRUE\DecelMax:=2;
    
    !Off
    PathAccLim FALSE,FALSE;

    You can play around with accelerations, valied values are 0.1 to 20 and the value is meter/second².

    You can take a look at a software from ABB called TuneMaster it is free and can be downloaded from ABB's web page. It can be used to tune foundations stiffness and resonance depending on robot modell and robotware version. This tool will usually help the 1600 and 2600 a lot.