The only legal way to get it is from KUKA.
Posts by SkyeFire
-
-
No, those are comments. Someone added them as a reminder of which $INs and $OUTs were associated to that particular INB/OUTB block.
When I spoke of entering values into $ANOUT, I meant in your executable code. So that when your milling program is running, you'd have something like: -
Oooh, yes, good point. I forgot about that little detail.
-
A bit more generally, you can think of the $ANOUT value as being a % of the maximum voltage output of your analog device (although the scaling value you use in IOSYS also plays a factor there). If your analog output module had a maximum output of 5V, an $ANOUT value of 1.0 would cause a 5V output, and an $ANOUT of 1.0 would cause a 24V output on a module whose max output went that high. But 10V is usually the standard.
Some analog modules also swing both ways -- I've had spindle systems whose direction of rotation depended on the polarity of the analog output. So if your Wago module supported a range from -10V to +10, an $ANOUT range of -1.0 to +1.0 would scale to that range.
-
If you have a full Archive from this robot when it was in working order, simply do a Restore All of that Archive. All the unique settings for the robot should be restored. Your original problem was most likely that Windows had developed some fatal file corruption. Copying the hard drive of a working robot fixed that, but now you need to restore the robot's specific settings and programs.
-
Did you activate the ProfiNet driver? Post your IOSYS.INI and your PN config file in their entirety.
-
You didn't answer the question about error messages.
IOSYS.LOG is in the directory C:/KRC/ROBOTER/LOG
As for Telnet, use the Forum Search function, it's been discussed many times before.
-
-
What error messages are you getting? have you checked IOSYS.LOG? Have you tried the Telnet diagnostic tools?
-
That looks about right, although I think it should be INB33 = 3,0,X22. From 512 to 533 is 22 bytes, by my count.
Although, by my math, 533.8 should be 533.7, and connect to $IN[880]. Remember, any x.7 from your PLC side will connect to an even $IN number.
-
Also, part of this interface also appears in the Windows Network Connections as "VxWin RTACC Shared Memory Driver". It is a "virtual" network connection between the two halves of the robot's brain, and has a fixed IP address of 192.0.1.2. Tampering with this IP will cause the robot to fail to boot properly.
-
Also, some robots spend all their time moving very fast and violently and top accelerations, especially in Automotive. Robots from Aerospace or Medical applications might have spent the same amount of time moving, but much more slowly and gently. So the number of hours is only part of the question as to how worn-out the robot is.
Also, as Xerces said, it matters how well the regular preventative maintenance was carried out. Sadly, many Automotive companies simply work the robots to death, never do maintenance, and then sell the robots to the secondhand market. -
Please show images of the actual cuts. How far off are they from nominal? Also describe robot path during cuts. Robots have more backlash than CNC machines, so even a perfect setup can create "circles" that look more like ellipses, simply due to the nature of robot drivetrain backlash.
-
KRC internal I/O index starts at 1, not zero. So for any given byte mapped in the robot, the first $IN or $OUT will start with an odd number, and end with an even number. So, for INB100 in IOSYS.INI, the first $IN will be $IN[801], not $IN[800].
So, if Byte X in the PLC is mapped to INB100 in the robot (INB100 = PLC,X in IOSYS), the bitwise mapping will be:
X.0=$IN[801]
X.1=$IN[802]
...
x.7 = $IN[808] -
Did you search the forum archives for occurrences of PDAT_ACT, FDAT_ACT, and BAS.SRC? Many earlier discussions that no one wants to re-hash for the thousandth time.
-
Yes, you appear to have cleared Stage 2 adequately.
-
Robot model?
KRC model?
KSS version? -
Are you changing orientation during the milling path? Because that will exacerbate any minor errors in your TCP. It will also cause errors due to the change in how the robot flexes under load. A fixed vertical orientation minimizes these effects.
If you're running a fixed orientation during a cutting path, look for spots where one of the axes has to reverse direction in order to maintain the linear path. That's where you're most likely to have path errors show up.
Unfortunately, depending on your KR model, some play in the wrist may be inevitable. Getting the wrist maintained couldn't hurt, but without further testing there's no guarantee that it will help.Also... 13000 hours ?!? That's the equivalent of running 540 days, 24hrs/day. And the hour meter only measures motors-on time, not idle time. So most of that is time in motion. That's not a lightly used robot, that's well used!
-
Tracking the axis motion on A1 and A2 and projecting their planes is generally the most accurate way I've found so far, although you need large arcs to null out the noise as much as possible.
Depending on the model of robot, there are usually machined holes in the baseplate for dowels in addition to the holes for mounting bolts. These can be difficult to access, but should serve as good datum points relative to $ROBROOT/$WORLD, although you would have to find them in the virtual model as well first.
-
Try setting DEBUG=1 in DEVNET.INI. Then do an I/O-Reconfig.
After that, there should be entries in IOSYS.LOG that might help narrow things down.