Well, this looks to be fun. I'm looking at a near-future assignment to retrofit ProfiNet into some KRC2s (ed2005) in the field at a customer facility. Now, I've never done this, but I've heard lots of horror stories about it. I have a copy of the manual, which I plan to read thoroughly, but what I'm hoping to learn from the forum is all those little niggling details that never seem to make it into the manuals -- the gotchas, the little tricks, the incorrect key sequence that sets the robot on fire... you know, those things.
Posts by SkyeFire
-
-
Well, the first thing to check is whether the remote share is available at all. Minimize the HMI on the SmartPad and use Windows Explorer to browse to the remote share. If the remote share is not visible from Windows, it will not be available from KSS either.
And, of course, check IP/netmask matches, do a ping test, etc.
-
Are you running the INI fold? If you skip over that code with Block Select, the Interrupt will not be declared.
-
First off, I'm pretty sure the analog input LED on the Wago module should not be changing luminosity with the voltage of the input. Are you using a voltage source, or a current source? The latter is not going to give you good results. You also need to look at the input module type -- if it is intended to work with a potentiometer-type (two-wire) sensor, then the module is supposed to supply its own output current and feeding it an external voltage source is likely to give very bad readings, and quite possibly damage the module. The module documents should have, somewhere, a diagram for a basic test circuit that can be used to check its operation.
The $ANINs can be a bit tricky, sometimes. I usually map the input digitally to a (in this case) 16-bit digital $IN block, and "reverse-engineer" the analog input by building a graph of the input voltage (tracked with a meter) vs the decimal value of the $IN block.
-
I do not believe this can be accomplished without SafeOperation. Attempting to do so without SO will almost certainly violate RIA specifications, and very likely your local OSHA equivalent regulations.
All the non-SafeOp methods for limiting the robot motion velocity that I can recall at the moment are not safety-rated -- they are too easily circumvented.
-
It is primarily to avoid singularities, as I understand it. Paint robots prioritize long, smooth, constant-velocity plans much more than most industrial robots, as opposed to strength and speed.
The paint-style wrist (I've never heard the technical term for this type of wrist), as I understand it, is slower, weaker, and more mechanically complex (and as such, more prone to wear and/or mechanical failure) than the "normal" triple-roll wrists.
One other advantage the "paint" wrists have is that they can be completely hollow through the center, which some robots (Reis laser-welding robots are one example, IIRC) make use of to avoid running complex hose/cable bundles down the outside of the arm.
-
No, the system variable $STOPNOAPROX. This controls whether there is a message if your program encounters a situation where continuous motion is disallowed.
Why are you altering MACHINE_DEF? That's for conveyor tracking.
Is E1 kinematically integrated? Is the robot TCP following the motion of E1?
-
When the robot performs this "stop and go" motion, does it produce any error messages?
What is the value of $STOPNOAPPROX? -
Variables declared in .DAT files with an initial value are retained essentially forever. So:
CodeDECL INT MyCounter ; variable is "forgotten" when this .DAT file's module is not in the Call Stack DECL INT MyCounter=0 ; this variable will be remembered even when the robot is cold booted, and the value in the .DATA file will be updated. So looking at an Archive of the robot will show the value of the variable at the time the Archive was made.
-
...??? ALL of the String system functions are fully documented in the KRL programming manual, copies of which are openly available in the Manuals, Software and Tools sub-forum: https://www.robot-forum.com/robotforum/man…or-kuka-robots/
-
I am having the same error "276-wrong MADA",but i have only that error, how can i fix this issue? -
The KUKA servo motors are simply re-branded Siemens motors, and the electrical characteristics of the Siemens resolvers are pretty well documented, IIRC.
KUKA also has a document for people attempting to integrate off-brand resolvers with the RDC, but you would have to request it.
The resolvers are, IIRC, analog (sine and cosine waves), non-absolute, and 4096 "pulses" per rotation, as a general rule. The RDC card performs the analog-to-digital conversion and busses the count data to the KRC.
-
Look up the STRCLEAR function.
One caveat -- the way KRL handles "string" variables is a bit odd. I discovered the hard way when sending strings over TCP/IP that STRCLEAR does not "erase" the string, but somehow marks the string as "empty" to KRL. So I had the strange situation where I could use STRCLEAR on a string, then send that string, and the old data was still there. But in KRL, the string showed as empty.
Now, I don't know if the CWRITE-file functions suffer from the same vulnerability (never tested for it), but if they do, my workaround was to use the declared length of the string and fill each position in the array with an integer (not string) value of 0.
Generally, though, I did all my File-Open operations in a dedicated subroutine that built the filename string with a locally-declared variable, so that every time the subroutine was called, the variable was declared anew. This guaranteed no "stale" data could ever be left in it.
-
No, the MFC doesn't have anything to do with ProfiBus. The MFC is the dedicated Multi-Function Card plugged into the motherboard's PCI bus, that manages the low-level realtime interaction between the motherboard and the servo modules. You can ID it by tracing where the white Ethernet-looking cable runs from the MFC to the KPP module (and then daisy-chains to the A1, A2, etc in sequence).
MFC2 and MFC3 are just different hardware generations of the MFC card -- you don't need to worry about the difference unless you're ordering spare parts.RoboTeam relies on two connections between the KRC2 cabinets -- an ethernet connection for the "remote" KCP, and a special cable (usually white, has round multi-pin ends that look just like the resolver&RDC cables) that daisy-chains from one controller to the next. There has to be a special "terminator" plug in the "incoming" socket of the first robot in the daisy chain, and another in the "outgoing" socket of the last robot in the daisy chain -- these terminators define the length of the realtime bus that allows the cabinets to coordinate their motions at full speed.
I was never an expert at RoboTeam, but when I worked on it, the boot order of the robots often seemed to affect whether the team re-connected successfully (RoboTeam on the KRC2s could be very fussy). You may want to try booting the master first, waiting for it to fully boot, then boot the slaves. And if that doesn't work, try it the other way around: slaves first, then master. In extreme situations, you might boot the robots one at a time, in sequence, waiting for each robot to fully boot before booting the next.
-
When A5 reaches around 0 A4 does a 360 turn and A6 remains the same. If A6 rotated the opposite of A4 to keep the tcp orientation constant then it would be no problem.
...what? I'm sorry, that makes no sense -- it is entirely abnormal behavior for a robot. If you are performing a LIN or CIRC motion that passes too close to A5 signularity, both A4 and A6 will counter-rotate relative to each other at high speed. If only A4 is behaving this way, then you must either have an unconventional robot configuration, or you are performing PTP motions with incorrect S&T values.
-
-
You may run into an issue here -- the file-write functions may not execute quickly enough to perform within that time limit. Or they may not execute with a reliable degree of timing. I've never done a detailed speed test on them, but I don't think they're terribly quick. And their timing can probably change unpredictably if they happen to "collide" with, for example, the regular write-down of the RAM drive to the hard drive.
You might be better off recording your data in a .DAT file array realtime, and then transcribing the array to your text file once it's complete.
-
"data_log.txt" can be replaced with a string variable (or, more correctly, a CHAR array).
As Panic says, you will need to dynamically re-write the variable using SWRITE to generate the string equivalent of the date&time you wish to achieve, before feeding that string variable into the CWRITE command.
-
$STOPMESS is a write-protected system variable.
-
Well, any method for measuring the robot's motion in space, precisely, can be used. A laser tracker is among the easiest, due to its range and lack of any physical obstructions.
TCP calibration with a laser tracker I performed by:
1. Mounting multiple SMRs (reflectors) to the Tool
2. Placing the robot at a known starting position and orientation
3. Measuring the TCP location and orientation with the laser tracker
4. Perform a LIN move along Z axis of the TCP
5. Measure the new location and orientation of the TCP
6. Determine error between actual TCP location&orientation and the programmed location&orientation
7. Adjust TCP B&C values to correct Z motion error
8. Goto Step 2 until Z motion error is within tolerance
9. Repeat steps 2-8 for Y, then X, then A, then B, then C -- each axis must be calibrated one at a timeThis achieved quite good results, but:
1. The measuring location&orientation had to be close to the production location&orientation. The greater the difference between the two, the greater the final accuracy error
2. Past a certain limit, reducing the error on one axis increases the error on others, so it was necessary to repeat the entire process multiple times to find a reasonable compromise. In my case, A error could be ignored, and Z error was less important than X or Y.Now, calibrating the [r]robot[/b] was done after the TCP was fully calibrated, with an SMR attached exactly at the TCP (sometimes, this required creating an extra TCP that matched the physical center of the SMR)
Calibrating the robot was a process of:
1. Create a set of calibration points that spanned the critical working volume of the robot, in both location and orientation -- the density of this pattern depends upon your accuracy requirements. In my case, I had approximately 8000 working positions, and used 1200 reference positions.
2. Move the robot to each reference point and measure the error with the laser tracker
3. Add corrections to each point and goto Step 2 until sufficient accuracy is achieved
4. Build a weighted-sum algorithm that can take each working position, find the nearest matches among the corrected reference points, average their corrections, and apply that average to the working position.