ProfiNet is pretty easy from the robot side. Just activate the "Device" category, and set the I/O size (number of bytes) that the robot will appear to be to the PLC. Also set your IP address. Device ID might need setting if you're using ProfiSafe as well.
From the PLC side, I don't have any experience, but from what I've heard there's a GSD file for the KRC4 (it might be on your WorkVisual CD?) that is supposed to make adding the robot as a slave to the Siemens PLC fairly painless. At least, for people who know Siemens....
Posts by SkyeFire
-
-
Could be a scaling error. Measure the analog output for $ANOUT= 0.1, 0.2, 0.3, etc, and plot them in Excel as a Scatter chart, or something similar. If it's just a scaling issue, the plot will be linear, and we can figure out the scaling adjustment.
-
There is a major difference between precision and accuracy. For industrial robots, "precision" is more a matter of "repeatability." A stock (pre-Quantec) KUKAbot, with no additiona tuning, can easily achieve 0.15mm repeatability, but actual volumetric accuracy can easily be 10x that.
Also, since robots have inherently larger backlash issues than CNC-style machines, any CNC-style program requires additional tuning to null out the robot's inherent accuracy issues.
-
List your current error and status messages.
-
LWR is, by my understanding, slightly less accurate than "normal" robots of similar size (we're still talking a small fraction of a mm, however). This is b/c the LWR is intended to be a force-sensing robot -- instead of trying to achieve highly accurate positions "blind," the LWR is expected to simply get close enough to successfully use its built-in force sensing.
As such, the LWR places a lower priority on sheer mechanical accuracy and more on high-speed realtime force/torque feedback. It is essentially intended to duplicate the human hand's method of "feeling" it's way into place. If you imagine how you can place a pin into a hole with your hand by feel, without being able to see it, the LWR is intended to "feel its way" in much the same fashion.
The LWR also has some other amazing properties -- with 7 axes in the arm, in the correct mode you can have a situation where the elbow strikes an obstacle and "bends" away, while the TCP maintains its programmed path. The vector of gravity is internally adjustable, and must be tuned for your location -- it's so sensitive, it can feel the difference in gravity between Sea Level and, say, Denver.
-
Well, having never worked with SprutCAM or CAMROB, I can only guess. It might be that CAMROB is more accurately tuned to the robot's particular weaknesses, since they are both KUKA products. However, I know that other people on the forum have had good results using SprutCAM, so I can only assume that there is some way of tuning it in properly. Best suggestion I can make at this point is to trawl the forum archives for mentions of SprutCAM and see what more experienced users have said.
-
The only legal way to get it is from KUKA.
-
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]