Posts by Gilldur

There are a few ways to do this in my mind.

PERS string sProcs{7}:=["Proc20", "Proc21, "Proc22", "Proc40", "Proc41", "Proc42", "Proc10"];

Lets say you have the names in a string array.

You could call them through late binding.

The syntax for proc call is a string inside % symbols.

%"Proc22"%;
But you could also write it like:

%sProcs{1}%;

You could also combine a base string with a number.

%"Proc"+ValToStr(22)%;

There is also an instruction that does this in the system called CallByVar

From the manual:

Example 1
reg1 := 2;
CallByVar "proc", reg1;
The procedure proc2 is called.

Hope this helps.

The friction values in the MOC are nm values for motor+gearbox friction. You can think of it as the minimum torque to move the axis.

In the rapid code the values are stored as a percentage of the values in the moc. So for a spesific move the friction values might look something like this: friction4:=[217.4,95.6,202.5,152.5,61.7,122.9];

Usually the values for an axis that more or less does not move during tuning can be very high or low and is basically an error but does not matter for the move.

The movement should repeat 20-30 times normally before the values are stored in your "R1_Cut_FricLevels" levels.

If you have waves in your cutting lines i recommend lowering the DH filter to around 50%.

You can change this in your motion process mode or byt adding these lines to the start of your code

        WaitTime\InPos, 0;
        TuneServo ROB_ID,1,50\Type:=Tune_DH;

This is very safe and wont break your robot.

Use TuneMaster to auto tune your arm resonance, this helps with vibrations and waves.
TuneMaster can be downloaded for free from ABB: "https://robotstudiocdn.azureedge.net/install/RobotWare_Tools_And_Utilities_6.15.02.zip"

If you are running RW6.x i would go into Motion > robot > motion process mode, and switch it to "stiff mode", this helps a lot when milling. You can edit the DH settings for that motion mode to 0.5 instead of using tune servo command.

IRB6660-205/1.9

1: 219.946

2: 171

3: -171

4: 104.286

5: -103.03

6: -125.8

Apart from the ratios the system will also modell based on the on the motor inertia, gear box inertia and static torque, After that comes the arm parts and their respective inertia. Most of these are really secret and ABB will protect them.

I cant remember where right now but you can find the motor inertia in the RobotWare files for each motor since any motor has files if you want to use it as an external axis.

The listed standstill torque for this robot modell is listed as:

1: 0.8nm

2: 1.5nm

3: 1.5nm

4: 0.4nm

5: 0.7nm

6: 0.3nm

The standstill torque is usually inaccurate.

Go to config "Motion > Robot > Motion process mode" Switch it to low speed stiff mode.
Also download tune master (free abb software) and perform the mounting stiffness calibration.

You set routines as hidden in the MMC config. This will keep them from showing up in the lists with pp to routine or ProcCall.

This is the correct way to do it.

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.

This kinda sucks, i really often need the gear ratio for things like proportionate torque and when mounting motors to see if the gearbox has a lot of friction.

And seeing is how this is information programmers actually need form time to time i decided to make this.

Quote from innebandy

Hello Gilldur,

I followed the step you mentioned to read the gear ratio.

However, I can't see any value there. More tips?

Use the Virtual Teach pendant.

Edit:

I noticed now that they have actually locked it out of the VC teach pendant as well. You have to boot the robot as 6.07 or earlier to still be able to see it in the VC teach pendant. Guess they finally decided to fix it.

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.

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:

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.

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.