Posts by SkyeFire

I copy&paste modules into /R1/ on a regular basis without any trouble, as long as I don't create linking errors by the paste sequence. I've never had a new file overwritten by the older one. There will be paste failures if the file being replaced is linked to the SPS, or if the new file does not have a fully valid syntax structure.

It is included on the install CD for the EKX package. Also on the robot D:\drive, under KUKA_OPT\EKX. There will be an Example directory under the DOC directory.

Ravi: are you attempting to perform real-time corrections to the robot trajectory based on the analog inputs? I don't think you're going to be able to do this with KRL. You need to research the "Function Generator" sub-system. Purchasing RSI or FTC would be an even better choice, but the FG should be sufficient for simple Cartesian corrections.

Are the sensors and outputs going to be connected directly to the robot, or to the PLCs? Are the PLCs connected to the robot directly in any way?

KRCs do not come with any built-in discrete I/Os. They are intended to accept any of a variety of FieldBus interfaces, and perform all of their I/O that way. The KRC2 comes with a built-in DeviceNet Master port, which makes it relatively simple to connect standard DeviceNet I/O devices as Slaves. However, this port is not so good for connecting to PLCs, unless the PLC can be configured as a Slave on the bus.

Something like this: http://old.turck.us/illustrations/B3025_B33.pdf is usually fairly simple to connect to the KRC2's DeviceNet port. The device must be configured in DEVNET.INI, and mapping it's signals to the robot's internal I/O table needs to be done in IOSYS.INI.

Other similar devices exist for other Fieldbus systems (Interbus, Profibus, ProfiNet, etc), depending on your preference. Personally, I've always found DeviceNet one of the simplest to use, but that might just be familiarity talking. In this circumstance, probably the biggest advantage to using DeviceNet is that it won't require buying any additional add-in cards for the KRC2.

http://www.robot-forum.com/rob…f-industrial-robots-only/

Any gripper, for any robot, must be designed for the item and material it is picking up. On larger robots, this is rather easy, but on Delta robots (like the ABB FlexPicker) the payload mass limit will be encountered very early. This is one reason that most Delta applications (at least, that I've seen) use just a small vacuum cup for an end effector.

If it possible to design a double gripper that does not violate the Delta robot's payload mass/inertia limits, one simply needs to provide sufficient I/O signalling to control each gripper as needed. For modern robots, this should not be an issue, although Delta robots may present greater challenges in running wires and hoses to the gripper, as compared to more conventional robots.

"work" directory? What is this? The robot's directory tree generally goes /R1/Programs/, or /R1/SYSTEM, or R1/TP, or R1/MADA. I don't recall a directory called "Work" anywhere in that tree.

The robot was both -- it was simultaneously a Slave to a local PLC, and the Master to this Siemens analog input device.

Given my time constraints, I punted -- had my (Siemens) PLC take over the analog input module, and pass the data through to the robot. Not my preferred solution, but it works well enough and I didn't have time to waste on it any further.

Still, it's a problem I'm going to have to solve later at some point -- if not for this robot, then for another project down the line.

The KRLXML package comes with example server programs.

I believe this has been asked before, but I don't recall ever seeing a positive reply. I'm wondering if KSS 8.x may have added such a feature.

Basically, I have a need to be able to call a Globally-Defined subroutine or function without hard-coding it's name into the calling routine. For reasons that don't bear going into, I need to have a top-level module that calls various other modules, depending on whether those optional modules are installed. The painful part is, this top-level routine needs to be identical across multiple robots, but these robots will have different options installed (or not). So right now, I don't see how to avoid creating Linking errors unless I put empty "placeholder" modules into every robot to cover every optional installation, or have all the optional modules installed on every robot. The latter is rather wasteful of memory and could create a real pain over multiple generations of this software architecture.

I'm not talking about using $CMD from the SPS to fired "SELECT" commands to the Level 1 interpreter -- I'm talking about something effectively like this:

DECL CHAR _SubName[24]
_SubName[] = "Subroutine1 (55,77.7)"
Execute (_SubName[])

Oh, yeah, did I mention I need to be able to pass arguments, too?

I suspect I'm going to be stuck using one of the less-palatable options, but I figured I'd give the Hive Mind a shot before I waved the white flag.

Well, we're going to need a lot more detail. The KUKA controller model, the KSS revision, and most especially what your hardware configuration is -- what are you trying to connect to the robot, using what means?

That sticker only has information about the robot. It provides nothing about the controller or KSS version.

Fortunately, your screenshot tells me that you're using a KRC2, which at least narrows things down.

The A5 limit error only means you cannot turn A5 further in the + direction. You should be able to jog it in the - direction to get off the soft limit. You may need to use MONITOR>POSITION>AXIS ANGLES in order to see the actual position of A5. It's possible that A5 is mastered improperly. If you jog A5 to 0, it should be pointing straight out, such that A6 and A4 are perfectly parallel. You can also use MONITOR>VARIABLE>SINGLE to check the value of $SOFTP_END[5], to see what the positive soft limit for A5 is set to -- it may need to be altered.

For I/O setup, you'll need to describe your hardware in much better detail. There are many options for using I/O on a KRC2 -- we would need to know which one(s) you have before giving you any useful advice on setting up your I/O.

Sounds like bad or disconnected motor cable.

What is the recent history of this robot? Has anyone worked on it, moved cables, changed parts? Was it working previously?

With Boolean type variables, like Inputs, you don't need to bother with the = check.

Also, for testing, you need to use "==", not "=". "=" is an assignment, "==" is a test. As Eusty showed.

KUKA Robot Language (KRL). Like most (all?) industrial robots, KUKAbots have their own brand-specific proprietary programming language. It broadly resembles Pascal.

What model controller and what KSS version?

Search recent forum discussions for C_PTP, C_DIS, and C_VEL.

You would have to contact KUKA Roboter directly for pricing and details. Provide them with the serial# of your robot and the version of KSS it is running, and they should be able to tell you exactly what packages are compatible and what they cost.

Yeah, one of the nice things about FTC is that you get RSI "for free" along with it. So creating an RSI object that only has monitor objects in it, and running it alongside your KRL program, should be pretty straightforward. RSI Monitor is great for collecting reams of data, although long recording runs can get pretty huge....

Every KRC2 shipped with a set of install CDs. Connect a keyboard and mouse, and boot with the Windows install CD. Then run the Setup program on the KSS install CD. Then install any and all Tech Package CDs. It's just about that simple.