Start with a kuka Robot

Yes you can... In fact you need to change them to be able to use EXT mode. You can use any free IOs although for EXT interface to work with your PLC, the Used IO range need to be whatever PLC can control. Normally one would use lowest IO so that user does not need to scroll much through HMI IO list. But .. there is nothing wrong with using IOs at the end of addressable space...such as 7800...7927 for example.

with Siemens you will need to swap bytes. normally this is done in WoV while mapping IO

For someone with a Fanuc background, you can think of $IN and $OUT as DI and DO. System signals like $DRIVES_ON and $MOVE_ENABLE are equivalent of UOPs, and need to be mapped to specific $INs and $OUTs. However, KUKAs don't have the Local/Remote or SIO types options that Fanuc does. In this respect, KUKAs are much simpler.

GI/GO equivalents are a bit odd relative to Fanuc. They're defined at the program level (using the SIGNAL declaration), rather than the system level,are declared by name instead of a number, and are "just" a group of DI/DO (any size between 2 and 32 bits) treated as a signed 32-bit integer. However, for multi-byte signals, any byte-swapping has to be handled in WorkVisual. One thing to watch out for is that any SIGNAL less than 32 bits will never trip the 32nd "sign" bit, and so will act like an unsigned SINT or DINT. Back when I/O tables were smaller, we did a fair number of programming tricks to get around this, but these days it's probably just simpler to declare everything as 32bit, even if that's a bit wasteful of byte space.

KUKAs also have no system level equivalent of PNS/RSR/etc. Instead, everythind is done at the program level. To facilitate this, every KRC includes the CELL.SRC module, along with a series of global variables that can be confgured through WoV or through the pendant menu (Config->I/O->Auto-External), mostly with names that include "PGNO" in the variable name. You replace the "example" lines in the CELL program with calls to your own programs. Or, you can ignore CELL and write your own "main" program from scratch.

OrangeEdit and other text editors are fine to manipulate programs but to configure KRC (this includes fieldbus configuration and IO mapping) you will have to use WorkVisual.

It is a free app you can download from KUKA.

next you will need to configure it:

- KOP integration. KOP files are KUKA Option Packages. WorkVisual may use them when compiling or transferring project to robot. So you will need to get them from D:\ of the robot and integrate them into WorkVisual.

- Any 3rd party devices will not be present in the DTM catalogs of WorkVisual. So you will need to import the device description files for each and every non-KUKA product into DTM catalog. than you may insert them from catalog into your project

WorkVisual workflow:

1. make backup(s) before touching anything

2. do not create new project from scratch. this is possible but cumbersome and you need to have some insider knowledge. just do yourself a favour and the get working project from the robot, and apply your changes there.

3. activate project by double-clicking on controller. this will allow you to see things differently (buis nodes can be expanded).

4. if your project does not have X44 bus, add it

5. add EK1100 (bus coupler) and any IO including profibus module(s) that you are palling to add. make sure type and order of modules is correct. usually PLC is master so robot would be slave and therefore need EL6731-0010

6. name IOs unders Symbol editor

7. map IOs, if needed do a byte swap

8. when ready to transfer project to the robot, make sure no program is selected and you are logged in as Expert or higher.

9. transfer project and activate it.

btw, it is possible to not have fixed IO mapping. for example one could remap the signals and do byte swap in Submit too. the advantage of this is that order or signals can be changed any time, even while robot is running. the disadvantage is that this needs program code that runs in Submit and therefore is slower and less practical for average user.

Quote from panic mode

btw, it is possible to not have fixed IO mapping. for example one could remap the signals and do byte swap in Submit too.

One working example of doing something like this can be found in the module P00, which is a support module for CELL and comes with every KRC. CELL's options include operations similar to PNS and RSR, along with adjustable size of the "word" for selecting programs, using negative numbers, and a few others I've never actually used. P00 is what steers through all those options and does different math on the PGNO values. It doesn't do byte-swapping, but there's a lot of other bit-manipulation it does that should provide some insight on what's possible and how to do it.

"the CELL program must be execute"

no...

Cell program is what KUKA supplied to make use of EXT mode easier and consistent. but you CAN remove it and make your own implementation if you know what you are doing. CELL is used in particular when PLC need to be able to choose between several robot programs. if you only have ONE program, then this can be run directly, without CELL.

"Have The operator have to execute it manually and then select the automatic extern mode?"

sort of...

The default is that operator selects the CELL, runs it in manual until BCO is complete, then change mode to EXT to let PLC take over.

Quote from wag_FFU

I can swap byte with the SPS, no problem

If you want to use CELL with a multi-byte PGNO, you don't want to rely on using the SPS for byte-swapping, due to the way CELL and P00 handle reading in the PGNO values (unless you want to start re-writing parts of P00). On modern KRCs, the best way to handle byte-swapping is through WorkVisual.

Quote from wag_FFU

So I´m planning to change my plan, and don´t change the signals address in $Machine.dat but simply mapping the $in/$out to the desired PLC In/Out number

Usually we edit both. The default addresses in $MACHINE.DAT are just there as placeholders, and tend to be a bit scattered around in the $IN/$OUT arrays. You could keep $MACHINE.DAT unchanged, and just do bit-by-bit addressing in WoV, but anyone who works on that robot in the future will curse your name.

WoV address mapping is best handled in blocks (say, 1-1000 to the PLC, 2001-2100 to the EOAT, 2201-2300 to the fixture tooling, etc). Then you edit $MACHINE.DAT (or, really, don't directly edit that file, use the Configuration menu instead, let the system edit the files for you) to connect specific bits to specific $IN/$OUTs inside those blocks.

Quote from wag_FFU

Another questions, what about the calibration? Are the kuka Robots already calibrated or I have to execute some sort of "first calibration"?

KUKAbots are usually Mastered (have each axis zero'd) at the factory, although doing a Check Mastering is always good on first powerup. Mastering is done using a tool called the EMD, which plugs into the robot's electronics and touches off a special precision-machined target inside each axis. DO NOT USE THE PAINT MARKS -- those just indicate the start point for the EMD motion.

Do this before mounting any tooling to the robot. Then, you have the option later of doing an updated Mastering with the load mounted (and Payload data entered), which will attempt to "tweak" the Mastering to account for any sag caused by gravity on the payload. Then there's some extra steps if your robot is an Absolute Accuracy or High Accuracy model, which have had extra calibration at the factory.

Most of the time, a simple Mastering and entering correct payload data is all that's needed for a KUKA to be very precise and repeatable. The extra steps are usually only necessary for applications that rely on accuracy rather than precision (they are NOT the same thing).

Quote from wag_FFU

Thanks, I´ve planned to use the first bytes to map the communications.

Note: as a general rule, avoid using the byte that contains $IN 1026 and 1025. I also usually avoid the matching $OUT byte, just for symmetry. For historical reasons, back when KRC1s had exactly 1024 I/O and no one thought we'd ever need more because the "best" on the market was usually 128, $IN 1025 was assigned as an "always True" bit, and 1026 as an "always False" bit. Then they couldn't change that when the KRC2s started shipping with 2048 I/O (without breaking backwards compatibility), so now everyone just avoids those bytes.

KUKA robots come mastered from the factory. however if you do have access to EMD, it does not hurt, in fact it is a good idea to remaster it. if you do not have mastering tool, stay away from this.

Quote from wag_FFU

I worked only one time with a KRC1, the 4 line black and white display was horrible!

...the KRC1 had a color VGA (800x600), 256-color display. The only KRC that matches your description was the KRC32, with the triangular-key keyboard where each corner of each key was a different letter/number.

Quote from wag_FFU

No, I don´t have an EMD, in fact I should buy it, but the factory where the robot should be mounted use only kuka robot, they will have plenty of EMDs ( I hope...).

They should. If they don't, you can do it by feel -- several forum threads talk about field-expedient mastering. It's an old trick for dealing with customers who don't have an EMD (or lost it, or broke it, or....)