Posts by robotecnik

This works exactly as you say eusty and this is something I've always seen as a BIG constraint: our cells are usually complex and we offer the end user a big set of functions that handle all the main tasks automatically also we create some routines like:

- urWorkUnit1
- urWorkUnit2
- ...
- urWorkUnitn
- urPickFromPallet
- ...

And the operator must put the points and calls to other routines inside those routines.

The problem comes as we have a main routine that call the different routines in a specific order and inside a loop, and there are some calls to initializations and changes to some IOs in between that happen automatically.

Here when our user has to select one specific routine has to start the program first and wait for it to reach a routine that calls one of those functions, then line select that function and go inside there.

We've put the routine calls in the main program in this way:

INIT
mainRoutineCall(); this includes the main loop and all the program logic to control the right program flow for the cell.
HALT
urWorkUnit1();
HALT
urWorkUnit2();
HALT
urWorkUnit3();
HALT
...

This allows the user to call directly any routine without all the hassle, but it gives a lot of job to the robot programmers we have at our company...

But at the same time it is far from being ideal, this is not happening in other robot brands.

I've seen that when I tried to select a line inside a different function or module than the one the program pointer is at the moment...

Sent from my BlackBerry 9300 using Tapatalk

Nothing comes "automagically": you will have to create the io variables in the robot configuration (eio file) and in the plc, in both places you will have to adjust the addresses of those variables to ensure that they are correctlyt linked.

Then, when you will activate a logical output in your robot, this will activate a logical input in your plc (through profibus, devicenet or any other bus you have) and at the end the plc logic will activate a physical output.

Hope this helps!

Sent from my BlackBerry 9300 using Tapatalk

Kuka is extremely flexible when it's time to make exotic ways to input data from t'he operator's side.

But, IMHO ABB has the best software and help system.

ABB RAPID programming language is really well done from the point of view of the programmer and it is much more flexible than kuka's.

I.E.: abb allows you to create submodules that are capable to call functions from the parent module which is impossible in kuka...

But of course the best you could do here is taking manuals of every robot under the sun and comparing them...

Sent from my BlackBerry 9300 using Tapatalk

Not from a cam program, but, given the fact you've got a HIGH ACCURACY or ABSOLUT ACCURACY robot, you could use as an example a couple of programs like mastercam and robotmaster to get the programs done for you automatically from the 3D part model.

Another method could be using KUKA CAMROB, which is also used to do milling programs...

There are plenty of solutions like that (those are the complex solutions I stated in my other post).

Be careful if you offline edit any file:

1. You won't be able to copy the file directly into programs folder, you will need to put the file in any other folder out of the programs one and then using the robot explorer move the file into the programs folder.

2. Don't put a lot of files inside the program folder. All of them are being let's say compiled and are occuppying memory...

3. Be careful with folds, if you remove an endfold clause during any offline edition, you'll see fireworks of all kinds inside the robot.

Those are good notes to consider if you come from abb... I've suffered a lot with them.

Good luck!

Sent from my BlackBerry 9300 using Tapatalk

There are plenty of options to do that...

From a complex solution which includes a cam and a postprocessor software to a simple solution in which you store points using krl...

What do you want to do exactly?

Sent from my BlackBerry 9300 using Tapatalk

Given that your post is inside the ABB forum, you could do it by:

a) using painting robots which typically can be programmed by moving the robot arm while robot's software is storing the path automatically.

b) using "normal" anthropomorphic robots which must have installed a force sensor (ABB names it Force Control) which consists on a multi-directional load cell placed at the end of the 6th axis and which is connected directly to the robot controller.

Hope this helps...

As SkyeFire says it all depends on various aspects:

- Not all the robots are equal (even they manufacture the mech parts really well, all of them are slightly different).
- Not all the calibrations are equal (even you use the EMT the very same device has a little error).
- The load itself is a problem when trying to get the same paths and points (more if you change the robot arm type).
- Two robots that are exact can not be equal.
- There are two kind of robots: normal and high accuracy robots (last ones are the ones that have been better mounted and are adjusted also a little bit better).
- ...

Expect to touch up some points, probably not the ones at the air, but the ones that will be close to the part, tool, pallet...

Good luck!

It looks like you've started the name of the function with a number.

I can't remember it right now if this is against KRL grammar or not, but at least the naming conventions and keywords depicted in the "KSS 5.5 SI V2 en" manual explains that:

* Names in KRL can have a maximum length of 24 characters.
* Names in KRL can consist of letters (A-Z), numbers (0-9) and the signs "_" and "$".
* Names in KRL must not begin with a number.
* Names in KRL must not be keywords.

Apart of that I don't know if you've copied the file from an external computer, but if you've done that you should copy it in a different folder than PROGRAMS and move the files there using the same KUKA interface, if you make the copy process externally the KSS is not capable to adopt the pasted file as a KUKA program.

Good luck!

Great if they have disappeared.

In order to replace batteries, create a small routine which send all the axis to 0, this will save you from moving manually the robot to the right position where to adjust the revolution counters.

I've been always programming and the electrical details have been done by other people, but I think you could also replace them while the robot is on.

Good luck!

Sent from my BlackBerry 9300 using Tapatalk

The error should have nothing to do with batteries as batteries only keep the rev counters on the smb card.

Who knows why this can happen, but I would try to reinstall the robot os, I don't remember which kind of start it was : xstart, pstart, istart, bstart... But one of those reinstalled it from scratch.

Batteries suffer when robots are unplugged (holidays...).
Lifespan changes depending on that. Contact abb and get a replacement, but usually you should get warning messages.

Sent from my BlackBerry 9300 using Tapatalk

As others said Notepad++ or Ultraedit work perfectly to edit ABB modules.

If you would like to be able to generate trajectories from a 3D surface using a complete offline programming system take a look at ROBOTMASTER. there are plenty of systems that allow you to program a robot offline.

Keep in mind that any of the avobe mentioned methods will have a problem:

If the robot is not an ABSOLUT ACCURACY robot or it has been calibrated using a fine calibration procedure the points that you will have written in your program will not be accurate in the real world and moreover the error won't be constant in the space. Doing palletizing is very important to have a good base/workobject and you can always put some correction functions to improve the results...

Good luck!

The best you can do to make a full clone of the compact flash card is to install a small Linux distro in any virtual machine and then, using a compact flash reader copy the entire compact flash contents.

As another option you could use any FTP client like the free FileZilla client to connect remotely to your service port and then pick all the files (programs and system modules); this would not give you the robot OS and other internal files, only your files.

Also you could use the pendrive and the backup operation in your pendant or use the RobotStudio Online to get a full backup of your files.

The only method that gives you a full clone of the CFCard is the first one.

Is this helping you? I'm not sure of having understood properly what you want to get.

Fluke is 100% right.

There are different ways to make the calibration, but when you calibrate one axis the reference point for the axis can change. Always depending on the methodology used, but even with the calibration tool from KUKA it can change.

Robots use single turn resolvers to know the inclination of each of their axes and a lap counter to know how many turns each axis have done.

When you calibrate one axis you are telling the robot that the calibration position it's the new home for that axis, therefore you are affecting all the programs. OF course it can happen that you can't appreciate the change as the previous calibration and the new one would be identical, but this is only one possibility. Given your explanations, you've remastered one axis and now the programs are not ok anymore. You can do several things:

- Recalibrate the axis until everything goes back to normal.
- Use an advanced mathematical software to recalculate all your points.
- Re-touch-up all the points in the old programs.

Last two options only if you are certain that your new calibration is better than the old one.

To calibrate the robot axis you should definitely use the KUKA specific device.

Good luck!

Due to the way kuka handle the compiling of the programs, you can't paste anything directly into the program folder.

What do always work is copying files into a shared folder at root (let's say c:toupload) and then, after copying those files there, you should go to the kuka hmi and using their file explorer cut the desired files from the toupload folder and paste them into the programs folder.

Good luck!

Sent from my BlackBerry 9300 using Tapatalk

If you are calling movements before the home position, then you don't have speeds and other data parameterized and the robot doesn't know how to move...

Open the ptp xhome fold and copy all but the ptp movement before anything else to ensure everything is parameterized.

Or use the ptp home position before starting to do any other movement.

Good luck.

Sent from my BlackBerry 9300 using Tapatalk

No flame war here 4u!

But I'm truly surprised to see how a robot (which is something complex) has those short manuals.
Also I'm surprised on the lack of manuals itself.
You are asking how to connect a PC to a robot. If you would have got a manual probably you would be asking something different like I've tested X but I can't continue for N reason, does anybody know how to...

Getting Windows in their robots is wonderful as you can get really nice applications created for "free" using any computer programming language. The fact they're planning to remove that for future releases is a pity. But at the end, if you don't document that or make it easier for everyone to get access to it, it has no extra value for anyone. When I was asked by one customer to create an interface the only answer I got from KUKA tech support in Augsburg was:

1. Send us the requirements and more or less it will cost you 6000€ per form/dialog.
2. You can buy the HMI_studio_don't_remember_the_name which will allow you to make that.

But never:

You can do it using VC++ or any other language and here's the manual.

i.e. using ABB force you to get a package to be able to do this kind of integration, moreover the pendant works using Windows CE and is connecting remotely to the control PC which works with I don't know which Linux flavour. KUKA has a great potential and advantage here, but IMHO they are not taking what they could from it.

The difference is that using eusty logic you start the output always and then you set it to false after two or three lines.

It should not affect, and for sure all the electrical devices in between the robot and the motor won't have even time to see the signal, but I like to think always in the worst case scenario just to ensure that even a small code change won't affect the result.

Using mine you get the output active only when it is needed.

But, truly, this is not important, you will get the same physical result using both.

Removing the conveyor = false inside the IF clause is not a good idea though:

Imagine you detect the input just after setting the conveyor = TRUE... you would leave the code block if A... without stopping the conveyor as A would be FALSE and you wouldn't come inside that IF block to stop the conveyor.

Only one = at the conveyorforward == false statement, but apart of that yes, you are ok.