tsk...tsk... no ENDIF after RowShift = 0?
...okay, fixed.
Of course, my indenting was bad too -- you missed that.
tsk...tsk... no ENDIF after RowShift = 0?
...okay, fixed.
Of course, my indenting was bad too -- you missed that.
Ah... that does make sense. Although... there are more than one .DAT file with retained variables involved in this stress test, and only one of them (and definitely not the one with the heaviest .DAT file re-writing going on) ever shows up in this error message.
Okay, that's your issue -- that 3COM card should NEVER be visible in the Windows Device manager.
Short history lesson: the KUKA controllers from KRC1 on to the KRC4 are split-brained -- basically, they run Windows for the user interface, and VxWorks in a virtual machine for hard-realtime robot system control. The two sides of the KRC's brain communicate through a virtual network connection, which shows up as the VxWorks Shared Memory Driver in Windows, with an IP of (IIRC) 192.168.1.2. DO NOT EVER MEDDLE WITH THIS, YOU WILL BREAK THE ROBOT.
In Windows Device Manager, there is (or should be) another network adapter. This is the one whose Ethernet socket is on the MFC card. This port is "owned" by Windows, and can be used for VNC, RDC, and file transfers.
The 3COM card is an entirely separate beast. When installed properly, the KUKA driver for that card should make it invisible to Windows' plug&play search. That's because the 3COM card is intended for hard-realtime data tranfers, and is supposed to be "owned" only by VxWorks. But Windows, being Windows, tries to search out all the hardware IRQs and take ownership of them during boot, so the KUKA driver has to prevent this.
Basically, this setup gives each side of the robot's brain it's own ethernet port, which cannot be seen or accessed by the other side.
Robot - KUKA IIWA 7 axis ( IO ELECTRICAL)
gripper - Robotic Gripper
Cognex - ISM-1402-11
Still not enough detail. What communications fieldbus, if any, are you using? Do NOT say "ethernet" -- Ethernet is a cable, not a communications protocol.
No details on gripper at all? What powers it? What communications bus is it configured for? Does it have an on-board controller? Motors? Sensors? Pneumatic actuators?
The Cognex ISM cameras are PoE, so you'll need a PoE power injector inline. The iiWA IO-Electrical option provides cabling for 2 ethernet cables through the arm, one 100Mb (4-wire) and one Gigabit (8-wire). You'll probably need to use the Gigabit cable for the Cognex.
Assuming you set Base 1 at the lower left corner of the plate, with X+ pointing right and Y+ pointing "forward", and Z+ pointing "up" orthogonal to the surface of the plate:
DECL REAL XShift, YShift, RowShift
DECL INT XIndex, YIndex
DECL FRAME FrameShift
XShift = 10 ; 10mm column spacing
YShift = 10 ; 10mm row spacing
RowShift = 0 ; init shift value for every other row
FOR XIndex = 0 TO 99 ; 100 columns
FOR Y = 0 TO 99 ; 100 rows
IF ((YIndex/2) <> (YIndex/2.0)) THEN ; odd or even row
RowShift = 5 ; 5mm shift every other row
ELSE
RowShift = 0 ; no shift on Even-numbered rows (including Row 0)
ENDIF
FrameShift = $NULLFRAME ; init to all 0s
FrameShift.X = (XIndex * Xshift) + RowShift ; row number times shift-per-row equals total shift. Add RowShift to shift every other row back and forth
$BASE = BASE_DATA[1] : FrameShift
PTP AboveDrillPosition ; move to position above drill point. This point needs to be taught at the first drill point at the lower left corner of the plate, while $BASE = BASE_DATA[1] (no shifts)
; insert drill subroutine here
LIN AboveDrillPosition ; pull straight up to clear position
ENDFOR
ENDFOR
Display More
From the description, Handguiding sounds most similar to the LWR's "Gravity Compensation Mode." Since I've yet to use an iiWA, I don't know if it has that same mode, or if HG is just a new name for GCM. But as long as the payload data was (very precisely) correct, GCM would cause the LWR to be "limp" to any external forces except those cause by gravity.
"Three connection cables"
Suggest you install Wireshark or similar packet-capture software on the remote PC, and log all traffic the the EKI port. This will allow you to see the packet-level TCP/IP traffic.
Possible issue with your PC firewall -- try turning it off temporarily. May be necessary to create explicit exception for the Server program.
Like Panic said, the MFC DeviceNet card is the low-cost minimal I/O option that all KRC2s came with.
Yes, you can do it with Profibus, but one robot will have to be the slave, and the other the master. But be aware, Profibus can be a pain to set up if you're not familiar with it.
Hm! That is weird.
But, no zip files in the /R1 tree in this case. And the program is running fine, without stopping, which is what leads me to believe that this is a bogus message. But I'm still curious as to the root cause.
Speaking of weird errors, I've got another one (different machine, different test, same KSS rev): while writing test-log information to a text file in /USERFILES using CWRITE FPUTS, I keep getting error codes back from CWRITE that (according to the manual) indicate that the "directory size limit" has been reached. But the writes keep happening, and the programs keep running. So that response code must be bogus.
KSS version? Network Configuration? XML file configuration? Is the robot server or host? How is your KRL program configured?
(Gee, what is it with all these ex-GM KRC2s all of t a sudden? Someone must have had a fire sale )
Anyway, your best option will be to contact KUKA with the serial number of your controller, and the serial number of your robot, and ask about available upgrade paths. There have been several threads here recently about upgrading robots of this generation.
Off the top of my head, your options are generally:
1. Update KSS to the highest level compatible with your current hardware ("vanilla", non-GM)
2. Upgrade the PC rack (possibly a few other components also) to allow KSS update to 5.6 (or thereabouts) and WinXP (again, "vanilla")
3. Get a KRC4 compatible with your robot (probably requires replacing the RDC card, but that should be about all, I think)
As KR16_2 said, you're unlikely to get away from the GM safety hardware without a major hardware overhaul. The good new is, you should be able to get away from the GM software with less extreme measures. But that is an old controller, so you're going to be stuck at a relatively low revision of KSS without at least some hardware upgrades to the PC rack.
The good news is, even the older revs of KSS are pretty solid. You're only going to run into their limitations if you're trying to do something exotic, like gazillion-point CNC programs, realtime remote control, motion coop, that sort of thing.
Yeah, so the only way to do direct robot-to-robot communications would be to wire (some of) their respective slave Inputs and Outputs to each other. Crude, but effective.
A PLC would make things easier (as long as it could be a DeviceNet slave to both robots simultaneously), but for a small, simple cell, might not be worth the expense.
This is an odd one. It's on an OfficePC currently running KSS 8.3.16 B112. I've got a math-heavy program that I'm torture-testing by running it for several thousand cycles, throwing random numbers at it each cycle.
Overnight, I got this message about 120 times. Each time the error is the same: the .DAT file of one of my math support modules "cannot be accessed". It's obviously not a regular occurrence, b/c that module would have been accessed several thousand times overnight, and the message only occurs a small % of those times.
It's a Notification message, and it doesn't stop the program execution. The message source module is shown as "CheckArguments," and the number is simply "21" -- no "KSS" prefix.
As far as I can tell, nothing is actually going wrong, but this puzzles me. Since I'm reading/writing some of the .DAT file static variables every cycle, I would expect that if the file really could not be accessed, the program would be halted.
At the moment, I'm guessing that this is just a bogus message being thrown by KSS. But I'm curious as to whether anyone else has ever stumbled over this one.
Ah. It could have been a single-channel fault. Remember what I said about the interlocking relays? One of the things that can happen, especially when removing/replugging CC1/X11, is that, if you do it slowly, the various pins make contact with enough time delay between them to cause this to happen.
VW? Crap. Those things are terrible -- why VW insisted on taking a good robot and completely mucking it up, I'll never understand.
KSS 5.7 with Win95? That's... an odd combination. I can't recall ever seeing KSS 5.x running on anything but WinXP. Hm.... Well, it shouldn't make to great a difference.
Okay, XS2 is probably the VW equivalent of X11. But I don't have a wiring diagram for a VW-specific override jumper. Still, if you have the full wiring schematic for XS2, that'll help. Assuming the nomenclature for the signals is still similar to the X11 standard, there should be two inputs labelled E-Stop (usually A and B). You need to bridge them to two of the "test outputs", ensuring A-to-A and B-to-B. That should clear the E-Stop error.
The Interbus error... normally, I would simply edit IOSYS.INI and comment out the Interbus driver. But I think the VW may block you from doing that. Unfortunately, I haven't touched a VW KUKAbot since KRC1/KSS 2.2 or so, before VW made a lot of their "improvements".
Well, the advice you get here on the forum is going to be worth, at best, slightly more than what you pay for it.
Less facetiously, there are a lot of variants of KRC2s, and without a lot of back-and-forth, we have no way to be certain we're not steering you down a blind alley. Or into a wiring change that will fry your controller. Especially if your robot is second-hand, which most KRC2s these days are. We also don't know how much knowledge you have of robots in general, and KUKAs in particular, and how much information you have -- for example, your KRC2 should have a complete set of electrical drawings, on paper, inside. But often these seem to be the first thing that goes missing from any 2nd-hand controllers. The only people who could be certain to get you copies of the correct drawings would be KUKA Service, working from the controller serial number (and even then, if the KRC2 was modified by someone post-factory....)
The service charges are for the specialized knowledge (generally demand exceeds supply), travel costs, and the confidence from having someone hands-on with the controller to see the things that we, on the forum, could miss. Plus, if you pay them for the work, it's generally warranteed to some degree. If you try to do it yourself with advice from a gang of people just spitballing over the internet...
So, first question: what variant of the KRC2 is this? Volkswagen? GM? "Vanilla"? Ford? Normally the standalone jumper is placed on X11 -- I'm not familiar with XS2, offhand (granted, it's been over ten years since I did a KRC2). Win95 or WinXP? ed-2005, or earlier? What version of KSS is it running? What option packages does it have installed? Does it have a servo disconnect? When you acknowledge the error messages, which messages remain that won't clear?
A lot of what you need is available in the Manuals, Software&Tools sub-forum next door. KRC2 manuals are pretty plentiful, although electrical schematics are a little harder to come by (all those sub-variants...).
The system variable $MOVE_BCO indicates if a BCO motion is required or not.
These lines set the system parameters for any PTP motions afterwards, until the values are deliberately changed.
The variables PDEFAULT and FHOME can be replaced with variables of your creation, containing the values you select.
BAS can also be called with #CP_PARAMS, to set the values for LIN motions (and uses LDAT rather than PDAT)
FDAT variables contain the information for the Tool and Base to use, as well as whether the tool is fixed or carried.
PDAT and LDAT set the acceleration and approximation values.
How is your robot-side program structured? What you're describing doesn't make sense -- if an absolute position is sent to the robot, it's going to go to that position, and it's not going to go anywhere else until it receives new coordinates.
That said, if the PC sends a position and then loses communications, the robot is still going to complete the last motion command it received, unless you add additional KRL programming to handle that scenario. Which is not easy, but entirely feasible.
Are you sending the robot absolute positions, or relative positions? If relative, you need to keep in mind the Advance Run Pointer. There's also potential issued where the robot would keep applying "stale" data if communications was halted, unless you handle your garbage collection carefully on the robot end.