I'm told that it is, although I have not done it myself. There's a limit of 3 or 5 simultaneous active connections, I don't recall which.
Posts by SkyeFire
-
-
-
Well, your SEND portion of the XML config file is definitely wrong. You have missing tags, and you aren't supposed to fill values in there.
-
That suggests a problem with the mode key, or the wiring. Is the key on the KCP, or on the cabinet? If the latter, it is possible to re-wire the key switch. If the former, then you either need a KCP repair, or a new KCP.
-
What are the results from EKI_INIT and EKI_OPEN, before you use EKI_SEND?
-
What mode does the robot display when the key is in T2, AUT, or EXT? "Unknown Mode" can be caused by a lack of power to the safety board, but that would affect all modes. If only one mode is affected, then the key switch or wiring could be at fault.
"Drives Contactor off" and "Active Command Inhibited" are merely side effects of "Unknown Operation Mode."
-
Process of elimination. Try each component -- motor, power cable, resolver cable -- one at a time, swapping in and out of a system that works. If the issue is hardware, this should determine which component is the issue. If all of the hardware checks out, then the issue has to be in the controller cabinet -- possibly the PM1 module, or software.
-
Hard to say, but my guess would be that it's still a pre-ed2005 system. Although the check mark on the "Interbus PCI" selection makes me wonder... Pre-ed2005 kRC2s had mostly ISA slots in the motherboard, if I recall correctly -- things got a bit weird during the entire ISA/PCI transition. If the MFC card is in a PCI slot, then it's probably an ed2005.
-
I can't visualize your setup from your description. However, if you want to shift/rotate a FRAME or POS type variable along/around its own XYZ axes, you can use the Geometric Operator (many discussions in the forum archives).
For example, $BASE = $BASE : {X 0,Y 0,Z 0,A 5,B 0,C 0} will rotate $BASE 5deg around its own Z axis.
-
Do you need to perform a simple XYZ shift, or do you also need to perform rotations?
If the stack you are trying to follow does not rotate, only shifts in XYZ, you can use TouchSense or some similar means to measure the position of a "reference" pipe, and simply shift the Base data based on the results.
If there are any rotations, KUKA used to provide a file called KUE_WEG with the KRC2 (KRC1?) that had an algorithm to replicate the 3-point Base creation.
-
Usually more than just a motherboard is different between an ed2005 controller and the earlier KRC2 versions. Was it just the motherboard, or the entire PC rack unit?
-
If I recall correctly, "Regulator Limit Exceeded" occurs when the difference between the commanded motion and actual motion becomes too large. If you watch the Axis Position monitor while you try to jog E1, do you see the value for E1 begin to move, and then "snap back" to the original value once the error message occurs? This would indicate that something is preventing the motor from moving, but most likely a software issue rather than an electrical or mechanical one. The last time I had something like that happen, the $RAT_MOT_AX value was 0.
-
DirLoader is an option you would have to buy from KUKA. They will need to provide a version matched to your robot and KSS revision.
Sending data to a TCP port is generally considered to be a fairly simple exercise. The KRL-XML install package includes some sample code for writing your own Windows server for sending data to a KUKAbot running EKX.
-
Probably the best way to go about this is to use the KUKA option package DirLoader.
I'm not familiar with the "libevent" you refer to. Is this related to KRL-XML?
Cyclically polling position data over Ethernet is possible, but not easy -- getting the data and applying it on the fly can be tricky, although EKI 2.2 (only available for KSS 8.2(?) and up) appears to make it easier.
You could make a very large array of E6POS points, pre-fill the array before you begin moving via Ethernet, and then run the array using a FOR loop. But for KRL versions below 8.3, there could be issues with array size (8.3 makes some very big improvements in memory handling over 8.2).
-
If you want to stream data continuously, you might want to consider not opening/closing the port for each transaction. You can do it, but it's cleaner and faster to hold the port open. You will, however, need to have error trapping to detect if the connection is lost and automatically re-connect.
-
MADA files for all robot types are on the robot's D: drive.
-
What, exactly, did you do to configure the E1 axis? What values did you change in $MACHINE.DAT?
Are the brakes opening?
What's the value for $RAT_MOT_AX[7]?
-
Now we have connected one barrier to X11 connector pins 7 & 8, and the other one to the pins 38 & 50. Our KR C2 version is "edition 2005" (so it use an ESC board). We don't see any button as the one you described SkyFire, we have the next KCP:No, the ESC board is inside the cabinet. Should be on the bottom of the right interior wall, near the front.
-
(Fluke beat me to it while I was typing) Are you utilizing the dual-channel safety signals properly? Each safety barrier should be interrupting an A channel and a B channel. If both channels are not interrupted simultaneously, you can create a single-channel situation that is difficult to clear.
Also, what generation KRC2 is this controller? Does it utilize an ESC board, or one of the older relay-safety boards?
If it is an ESC board, there should be a small blue object that looks like a very small relay on the ESC board, with a small black button rising out of it. Pushing this button will reset any single-channel faults. If using this button fixes the error, then the root cause is definitely your channel wiring.
If you don't have an ESC board, then interrupting the power to the safety-relay board will usually reset single-channel faults.
-
"Status and Turn." Documented extensively in the KUKA manuals, and many discussions in the Forum archives as well.