Do you have an Archive of the robot from when it worked properly? I would suggest running the contents of that Archive through a comparison program (KDIFF3, UltraCompare, etc) against a new Archive. That should at least show you anything that's been changed.
Posts by SkyeFire
-
-
What command are you using to decouple?
-
The ABC angles of a point in space represent a sequence of three Euler rotations (in the case of KUKAs, sequence Rz, Ry, Rx) to achieve that orientation starting from the orientation of the currently active $BASE value.
This means that, at any given TCP orientation in space that does not perfectly match the active $BASE, rotating around one axis does not result in a $POS_ACT value that only changes around that axis. And since Euler rotations can achieve a given orientation through many different angle combinations, the solution space is deliberately limited to +/-180 in A and C, and +/-90 in B. There is additional disambiguation using the S and T elements of an E6POS structure, but that's a bit beyond the scope of this conversation. -
Now that's odd. Check the value of $SOFTN_END[5] -- it should be something like -100.
Failing that, I would suggest deliberately un-Mastering A5 and then re-Mastering it. Ah, you do have a Mastering tool, correct?
-
Can you describe this vibration? Is it a "pause," or is it an actual vibration? Is it limited to certain motions and angles? Does it occur when one of the axes is experiencing a reversal of direction?
-
Two unrelated, unconnected robots both do this? Wow, that's... REALLY strange. Do both robots go through these "phases" at the same time?
Can you identify any common factors between the occurrences? I mean, does one particular axis of the robot always "wild orbit," or is it any axis, or multiple axes together?
Are there any particular error messages left in the log when this happens that hints at any root cause? Have you taken Archives of the robot(s) immediately after one of these incidents for later analysis? Do you have any Mastering issues immediately following one of these incidents, and if so on which axes?
The tooling the robots collide with -- is it within the reach envelopes of the robots' soft limits? Have you tried setting up workspace monitoring?
-
I think it's best documented in the KSS 5.2 manual, which is available in the Manuals&Tools sub-forum. You can also find relevant discussions by using the forum Search tool.
-
I can't speak to the WorkVisual code -- my knowledge of EKX is limited to pre-KRC4 versions. But typically, KUKA always includes some example server code. I was incorrect about it being in the /DOC directory, however -- at the same level as the DOC directory, there should be a Directory called Demo, which (at least in the old versions) contained example code for both KRL and the C code for a matching server program.
-
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.
-
-
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:
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.
-
-
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.