That is not familiar. But if it is a KUKA Tech Package, the manuals for it should be present on the robot's D:\KUKA_OPT directory.
Posts by SkyeFire
-
-
Hm. That's a good question. My first thought is to plug in an external keyboard and use the PrntScrn key. But would you need to plug into the SmartPad, or directly into the KRC? As long as you plug into the correct unit, PrntScrn should work, after which you can shrink the HMI, open up Paint in the Windows menu, then use Paste. Save the resulting image to a USB memory device, and that should do it. But I haven't tried this.
-
OK I'm going to do this test. Besides I can accept that the mainboard has been specially done for KUKA but the CPU seems to be just a commercial one. I seriously doubt that KUKA has it's own manufactoring Company named Intel... he he he.I'll report my results... thanks a lot...
You'd be surprised. For example, in the days of the 486 processor, Intel sold the 486DX (with an internal math co-processor) and the 486SX (no co-processor). Thing was, the SXs were mostly DXs which had failed the quality-control checks for the co-processor but passed the other quality checks, and so got re-marked and sold as a lower-end market item.
So it's possible that Consumer-grade and Industrial-Grade processors come off the same assembly line, but the units earmarked for the Industrial market have passed a higher level of quality-control testing. -
Given those numbers, you could simply use $ANOUT[x] = DesiredRPM*(10/24000). You just need to extract the DesiredRPM value from the GCode, and pass it to a subroutine on the fly, as Wes mentions. Probably using a Trigger command for synchronization. You might have to watch out a bit for how fast the spindle can respond to new speed commands, but aside from that it should be fairly straightforward.
-
Well, I remember when the KRC1s were at the same stage of development -- Blue-Screen of Death on the KCP all the time. Of course, back then VxWorks and Windows were so isolated that the robot would keep running perfectly well, unless you needed to use the user interface. Those problems got resolved as the controller matured, and I'm sure the KRC4 will follow a similar trajectory. But I imagine it'll be a PITA for the next 2-3 years, though. Ah, well, that's the price we pay for technological progress, I guess.
-
-
I've never tried replacing the CPU with a non-KUKA CPU. Technically, it should be possible, as long as the CPUs are compatible, but it's not a sure thing. I have, for example, seen people attempt to add non-KUKA RAM to KUKA motherboards: sometimes it works, sometimes it fails badly, and sometimes it creates random issues that are very hard to track down.
Basically, while the motherboard and components of the KRC2 controller are technically the same as an average PC, in fact they have been heavily tested and certified, and are made to tighter tolerances. Average PCs, for example, are much more tolerant of minor memory timing faults, b/c a consumer-grade OS like Windows can tolerate such things. But with a hard-realtime system like VxWorks, which is what actually runs the robot (the Windows on the KRC2 only runs the user interface), minor timing faults in a RAM chip result in fatal errors that stop the robot immediately for safety.
Bottom line: replacing a KUKA part with a non-KUKA off-the-shelf equivalent shouldn't actually damage anything. But it might work, or it might result in a robot that runs poorly, if at all. BSODs, freezes, random spontaneous reboots, etc.
-
Just keep in mind, when you make a change to one of the I/O system .INI files, it has no effect until you either cold-boot the robot, or perform an I/O re-initialization (under the Config menu), which basically reboots the I/O subsystem without taking the time to reboot the whole robot.
Also, for DeviceNet, there's a couple of things to keep in mind:
the DevNet.INI file contains the mapping for all the Slave modules connected to the robot, including their addresses (MAC IDs) and the number of input/output bytes produced/consumed by each Slave address.The file IOSYS.INI manages all of the KRC2 FieldBus systems, and how they map to the robot's fixed internal I/O table of $IN and $OUT signals and also the $ANOUT and $ANIN analogs. If you use the $ANxx signals instead of using integer math, IOSYS.INI is also where the scaling and configuration of these analog signals is carried out. Most versions of IOSYS.INI include extensive comments that are probably even better for explaining how to use the file than the manual is.
An analog I/O device will consist of one or more bytes that represent a binary "word" which scales to the analog side of the device. So, for example, if you have a 12-bit analog output card whose analog output scales from 0 to +10V, with no negative voltage, setting those 12 bits to an integer value of 4095 will result in a 10V output, 2046 will result in a 5V output, and 4 would result in an output of about 1mV
-
No resource forks, but there are certain formatting codes at the top of any .SRC, .DAT, or .SUB file that can be tricky to make correctly by hand. The simplest approach is to create a new .SUB file on the pendant, using the "New Submit" template. This will create a .SPS file that already has the header and footer defined for you. Then copy that file to an external PC and make your edits there, leaving the header and footer untouched -- just make your modifications in between. Then copy the new version of the file back into the robot.
-
T is a 6-bit binary value (normally represented as an integer), with bit 0 representing Axis 1, and bit 5 representing Axis 6, and so on in between. The bit is set to 0 if the axis is >= 0deg, and 1 if the axis is <0deg.
S is a 3-bit binary value, which is a bit more complex. Bit 0 is False only if the intersection of the wrist axes (center of A5, essentially) is "forward" of A1 (that is, imagine the YZ plane of RobRoot rotating with A1 -- as long as the position of the wrist center has a positive X value in this rotating coordinate frame), and is True otherwise.
Bit 1 is False if A3 is less than a certain angle (which varies depending on your model, you may have to determine this experimentally -- the angle is 0deg if your A3 and A4 are co-planar), and True otherwise.
Bit 2 is False for ((0<=A5<180) OR (A5 < -180)), and True for ((-180<=A5<0) OR (A5 >=180)) -
If you are using KRL-XML (which is, as far as I know, the only way to transfer data to/from the robot using TCP/IP), it is necessary to insert the data into an XML form and transmit it to the robot. The example programs that come with the KRL-XML package demonstrate a minimal application for doing this. You said that you've already succeeded in transferring data between the PC and the robot in the past, so what is the specific nature of your current difficulty?
-
I assume that a variable exists that controls how different the actual metal thickness can be compared to the programmed metal thickness. This would probably be a global setting, rather than a setting at each weld point. However, without direct knowledge of your system configuration, I cannot offer any assistance more detailed. If your robot has KUKA ServoGun installed, I would recommend studying the relevant manual (which should be on the robot in D:\KUKA_OPT\ as a PDF file) and searching for anything related to thickness tolerance.
However, making the tolerance larger will make it harder for the system to accurately detect tip erosion.
I would also recommend measuring the metal thickness on points where the gun fails, before welding, in order to compare the actual thickness to the programmed thickness. Confirming the weld gun calibration would also be wise.
-
"binary string" is even more confusing. Usually those two terms are mutually exclusive. "String" normally refers to data transmitted in ASCII, and "binary" refers to non-ASCII data. What exactly are you trying to do?
-
Define "binary stream."
-
My KRC4s seem to have a real problem re-connecting to the SmartPad after cold boots. Often it requires 2-3 reboots before the two will work together again. This has nothing to do with RSI -- it seems to just be a KRC4 issue.
-
I'm guessing that this robot is using the KUKA ServoGun tech package.
I agree that gaps between the layers of sheet metal are the most likely explanation. You may need to increase the part thickness tolerance -- there should be a setting to control the tolerance window, but I'm not familiar enough with this version to tell you where it is.
-
Stupid question, but: what about the Stop button on the SmartPad? Not the E-Stop, the small button with the red square icon next to the Step Go/Back buttons. That's what normally works for AUT mode.
Now, if you have multiple robots in AUT that you want to stop from a single point, that's a bit harder. I'm assuming you have the X11 safety setup, as opposed to ProfiSafe or something else? -
Is this network page the best (or only?) interface/method for determining the network configuration (IP address, etc.) for the KLI and RSI?I'm trying to diagnose a network issue (can ping external PC from KRC4 command line, but not KRC4 from external PC). I've read that KLI and RSI need to be on different subnets, but I have to be able to identify KLI first.
Again, any help is greatly appreciated. Thanks!
KLI is virtual network 5, by default. And 172.31.1.147 is its factory default IP address.
You're using RSI v 3.1? Section 5.2 of the manual covers how to set up the RSI-specific virtual interface.
-
In RSIVisual, do you have a StopDistMon object? Are you using RSI or FTC? I ask b/c FTC includes a StopDistMon object automatically, attached to the State output of the POSCORR_CTL object.
-
The LWR and FRI are pretty rare items, so very few people have experience with them. I know I don't. However, I can suggest a few generalities:
What is your KRC hardware config? I assume you have a realtime Ethernet card in addition to the motherboard ethernet port?
You say you've changed the IP in VXWIN.INI, but what "Ipconfig" command are you referring to? VXWIN.INI sets the IP address of the realtime ethernet card, but it can't be set to the same IP as the Windows IP that would be shown by an IpConfig command on the teach pendant. You should also avoid setting the realtime card to anything on the 192.168.1.* subnet, as that will conflict with the Virtual Memory Network Driver. VxWorks and Windows inside the KRC communicate with each other over this virtual network and pretty much have that subnet. NEVER TAMPER WITH THIS DRIVER -- it will completely break the robot. Instead, I would recommend putting the realtime card onto a 172.*.*.* subnet, so as to guarantee no interference.On your laptop: I know some other KUKA "sample" server programs select which network interface they're using at random. So, for example, if your laptop has a WiFi connection and an ethernet connection both active, the server program might bind to the WiFi, which could cause what you're seeing. The ping command would not reveal this, since the ping would automatically direct to the correct interface based on the IP address. Try disabling every network interface on the laptop aside from the one connected to the robot.