If your KSS version is 5.5 or higher, the USB drive should show up in the KUKA Navigator when you plug in the drive (as long as you are in Expert mode). Simply navigate to the modules you want to copy on the USB drive, hilight them, and do EDIT>COPY. Then navigate to the appropriate robot directory under /R1/Program and do EDIT>PASTE.
Posts by SkyeFire
-
-
In what way is the image horrible? Is it badly fitted to the resolution of the external monitor, or is it disrupted in a way that suggests signal interference?
If the former, you might need to go into the Windows dual-monitor display settings (assuming this is a KRC2 running Windows XP) and adjust the resolution settings for the external monitor. If the latter, I would suggest changing cables, perhaps to a better-shielded version.
-
As Mookie says, those are two completely different systems.
The DirLoader is for loading a fresh set of modules (.SRC and .DAT files) into the robot, so that it is not necessary to carry the programs to the robot by hand and load them manually.
RSI (the newest versions of which contain XML functionality natively, so there is no separate RSI-XML package anymore) is for doing realtime transfer of data, and controlling the robot's motion with that data -- this is for connecting sensors directly to the robot motion in a constant 12ms loop.
RSI cannot load program modules. DirLoader cannot act in realtime.
-
XML isn't a programing language, it's a markup language. The only thing I can think of is that the KUKA-Spain tech was suggesting you could use KRL-XML and stream data in from an external source to populate (for example) an array of E6POS variables inside a .DAT file. But that doesn't seem like what you need. As I understand it, you need to load entire .SRC/.DAT files from a disk on demand, even in automatic mode. I don't know of any way to do this using XML. However, my knowledge is hardly encyclopedic. I would ask this tech to send you a manual or other documentation describing what he's referring to.
-
A PLC is not necessary to use DirLoader. And as far as I can recall, the DirLoader commands will work in any mode.
What you do have to have is the directory where the new program directories are stored. These could be on the robot's own hard drive, or a remote network share, or even a USB or CD unit. If the directories are not availabel when the DirLoader command runs, the commands will error out.
-
I had a chance to try out a Beta version of the DirLoader a few years back. I assume that it is now available for sale, but I have not checked into this. (edit: well, if MeanRobot's used it, I guess it must be available)
KRL has no built-in capability to copy, move, or delete program files. The DirLoader tech package partially addresses this by, on command, loading the entire contents of a directory (any directory available to Windows on a local drive or a remote network share -- anything that shows up as a drive letter to Windows) into the robot's /R1/Programs/ RAMDrive. These programs will be copied into the robot, compiled, and made ready for use, and this can happen while the robot is in automatic and running.
The root concept behind the DirLoader, as I understand it, was to allow users with high-precision Simulation systems or CAM-conversion programs like RobotMaster to load new motion programs into the robot on the fly, without stopping the robot.
-
Without using the KUKA DirLoader, or some serious hacking, the only way I know of to move programs from a computer (such as one using OfficeLite) to a robot is to copy the .SRC and .DAT files onto a removable disk (Floppy, USB, CD), then using the KCP on the robot to Copy&Paste those files into the /R1/Programs/ directory, manually.
-
-
Okay, something is not right here.
KRC controllers run two Operating Systems in parallel: Windows to handle the user interface, and VxWorks to handle the critical realtime functions (I/O, motion, etc). Think of them as the left and right hemispheres of the robot's brain. These two OSs are not aware that they are running on the same machine -- they think they are running on separate machines, and communicate with each other using the Virtual Network connection, which acts somewhat like the Corpus Callosum in a human brain. Without the Virtual Network connection, the controller cannot function.
OfficeLite works the same way, except that it has been modified to use your computer's pre-existing Windows install as the Windows "host", and the VxWorks engine has been modified to work without KRC hardware or a connected robot arm. But under no circumstances should installing OfficeLite affect a computer's pre-existing hardware network interfaces. Also, the Virtual connection is not for connecting OfficeLite to KRSimPro, although it does serve that purpose as a secondary function -- it's primary function is the same as on a physical KRC controller.
There is one circumstance where a possible traffic conflict could arise: if your computer's hardware network connection uses a 192.0.1.* IP, traffic you're trying to send via that connection won't know which network connection to use. You should probably used a 192.168.*.* IP for the non-Virtual network connection. Modifying the Virtual connection on OfficeLite, or on the KRC, will cause the unit to stop functioning.
If, somehow, your OfficeLite is breaking your laptop's pre-existing network connection (I've never seen it happen, but nothing is impossible), I see three possible solutions:
1. Contact KUKA service -- they may have encountered this before and know a work-around.
2. Install OfficeLite on another computer.
3. Create a Virtual Machine using VMWare or VirtualBox, and install/run OfficeLite inside that virtual machine. I'm using OL inside a VMware virtual machine right now, and I know other forumites have had success using VirtualBox (which has the advantage of being free).Transferring programs from an OfficeLite to a physical KRC is as simply as copying the files onto a USB drive, and carrying them to the KRC and pasting them into the correct /R1/subdirectory. A network connection is convenient, but not required.
-
MeanRobot is correct. Your laptop's hardware ethernet port should not have been affected by installing OfficeLite. Is it possible that the port was simply disabled somehow in Windows settings? If you use Windows Hardware Manager on your laptop, does the port show up? What is its status? It's possible that an obsolete or corrupted driver could cause the port to cease functioning.
Do you have to use your OfficeLite laptop to connect to the KR60? OfficeLite is not required to connect to physical-world robot -- any regular computer with a working ethernet port should be able to make a simple network connection to a KRC.
-
Yes, but what model is the controller? Since this is an HA robot, I suspect the controller must be pretty new, which makes it most likely a KRC2, 2005 edition. On this controller, the standard ethernet port is on the motherboard of the internal computer. How many physical ethernet ports does your controller have?
At any rate, the Virtual Network connection is NOT the issue. That connection is absolutely necessary to the operation of OfficeLite and the KRC, and has no effect on the hardware ethernet connections.
Now, if there are no LEDs illuminated on the ethernet ports when you connect the cable, that is very strange. I would recommend obtaining an ethernet hub, and connecting the robot and the external computer to this hub. After doing this, the port LEDs should help determine whether the problem exists on the KRC, or on the external computer.
It is possible that the hardware ethernet port on one of the machines has been disabled in Windows XP. I would recommend checking both machines in the Windows Control Panel, or by using IPCONFIG in a command-line window.
-
Just to be clear: you have an actual, physical KRC unit, not an OfficeLite installation?
The trick to connecting a KRC to a network is to adjust the correct network interface.
In the KRC, if you go into the WindowsXP Control Panel, Network Connections, you should see two network connections. One of these is an internal virtual network connection that makes the contact between the Windows and VxWorks sides of the robot's brain, and has an IP of 192.0.1.2. DO NOT EVER TAMPER WITH THIS CONNECTION, it is a system-critical item and changing it will prevent the robot from booting.
The other connection is the physical Ethernet socket in the robot controller (this varies somewhat between different controller models, and you haven't said which one you have). This is usually defaulted to using a DHCP address. If you are just connecting your computer to this robot, you'll need to set this IP address to an IP compatible with your computer (do NOT use any IPs in the 192.0.1.* subnet, however), and use a Crossover ethernet cable (unless you have a hub/switch/router).
-
That's an interesting pattern. Normally a "Unknown Operating Mode" error is cause by a missing or mis-wired X11 jumper, but in this case it really sounds like the problem is in the KCP. As Mookie noted, this could be explained if the mode-select key in on the KCP, rather than mounted directly to the cabinet bulkhead.
However, the fact that you need to keep hitting the ESC reset button suggests something more than a simple keyswitch problem. The KCP is included in the safety circuit which the ESC board monitors, thanks to the E-Stop, Enabler, and (on some models) mode-select keyswitch.Hm. Having to use the ESC reset button often results from a single-channel fault in the dual-channel safety architecture, in my experience. The E-stop, for example, has two pairs of contacts on the same physical switch. If the two contact pairs disagree for longer than a very small time window (a few dozen milliseconds, if I recall), that can put the ESC board into a condition that requires a reset. There could be a bad contact in the KCP, or a partially broken wire in the cable.
-
Hello SkyeFire,I thought about one more possibility: using the cross interface (for example, the cross.ocx). There are nice functions, which seems to do exactly what NiamoR42 needs (Copy, Select, Run, etc.) Disadvantage: theses functions are not documented. Anyone tried them?
Greetings,
Tilman/FranceHm! That's actually an idea worth pursuing.
The problem, of course, is that KUKA guards that software quite jealously, for multiple reasons. I know Mookie has done quite a bit of work into building VB/C# plugins that work with the KCP HMI, but I don't know if he (or anyone) has ever tried reverse-engineering the Cross OCX as you suggest.
Of course, this would require someone with nerves of steel, exquisite programming skills, and a KUKAbot (or OfficeLite) free for doing lots of experimentation on. Not to mention lots of free time. -
It is, unfortunately, the nature of the big orange beasts.
During boot, KSS loads the /R1 directory from the hard drive into a RAM drive, and runs from the RAM drive. This makes it possible to make alterations to the files on the hard drive while the robot is running, without affecting the robot's operation. During shutdown, KSS saves all files from the RAM drive back to the hard drive.
So, adding modules to the /R1 directory on the harddrive has no effect until the robot is rebooted.
The Tech Package to allow program files to be loaded from the hard drive while the robot is powered up is called KUKA DirLoader (it actually loads an entire directory). That's probably the safest and most effective approach.
Now, I have done a very small bit of experimentation in using Windows scripting to duplicate the sequence of button pushes on the KCP that perform the manual copy&paste module operations, and I've gotten it to work in AUT mode in OfficeLite 5.6. No idea if it'll work on a production robot, and frankly I'd be nervous about trying it without very thorough testing.
Alternatively, if the programs you need to run have the same structure, but just different positions, you could create a large array of E6POS in the DAT file, then do something like this in the SRC file:
Code
Display MoreFOR i = 1 TO ArrayLimit Array [i] = {X -1, Y -1, Z -1, A -1, B -1, C -1} ; init array ENDFOR i = 1 WHILE ((i <= ArrayLimit) AND (communications check)) Array [i] = E6POS variable from communications subroutine i = i + 1 ENDWHILE 1 = 1 WHILE ((i<=ArrayLimit) AND NOT ((Array[i].X == -1 AND Array[i].Y==-1...and so on))) LIN Array [i] i = i + 1 ENDWHILE
That's a very rough example, of course, but it can be made to work.
Alternatively, you can create a loop that simply keeps asking a remote device for the coordinates of its next move, and executes said move.
RSI isn't the right tool for this -- RSI is really intended to allow the robot's motion to be influenced in realtime by sensor devices, although the "sensor" could easily be a robot simulation engine like RobCAD. People have used RSI to turn KUKAbots into real-world realtime "slaves" of virtual robots inside a computer.
So, the solution that would work for you depends on what your program toolchain looks like -- what your process is to generate a program, and what the program looks like before loading into the robot.
-
KRL unfortunately has no file-handling functions (a distinct oversight). So unless you buy the Tech Package that Mookie mentioned, there's no way from within KRL to order the robot to load a module from a hard drive location into the /R1 RAMdrive.
There are ways to do this manually -- in the KUKA Navigator on the KCP, you can (if in Expert mode or higher) navigate to any drive visible to the KRC's Windows system, and perform an EDIT>COPY from the menu buttons. Then navigate to the /R1/Program directory and perform an EDIT>PASTE from the menu buttons. This can even be automated to an extent using Windows scripting, like AutoIT.
I suppose the question is, just how automatic does this process need to be?
-
Just to amplify a bit: 100mm is the offset along the X axis of the A1 reference frame between A1 and A2. For the purposes of this calculation, the Y and Z values would be irrelevant, since we're only interested in the wrist's position relative to the YZ plane of the A1 frame. Of course, the X offset could be negative for some robot models, although I can't recall ever seeing a robot arranged that way in real life.
So, for a more general case of MeanRobot's formula:
Bit 0 = ((dA1A2 + (COS(A2) * dA2A3) + (COS(A2+A3) * dA3A5) <=0)Where A2 and A3 are the joint angles of Axis 2 and Axis 3, respectively, and dAxAy is the distance between Axis X and Axis Y (for most wrist models, the distance between A3 and the wrist should be the same as the distance between A3 and A5). This of course assumes a fairly standard kinematic configuration for a six-axis robot.
-
Well, the error messages are being generated b/c your IOSYS.INI is set to activate the MFC's DeviceNet port, but you don't have the port configured properly. You may also not have power routed to the port.
The simple way to get rid of these errors is to deactivate the DevNet driver in IOSYS.INI, by commenting out the line in the [DRIVERS] section. However, if you need to use the DeviceNet port, you're going to need to configure your DevNet setup properly. Which we can't help you with without more information.
However, after a "clean" install of KSS, the Devnet port should not have been active. Did you select it during the install?
-
This is why my standard advice to customers buying robots (any brand, not just KUKA) is to buy at least one extra robot, for spare parts and for testing suspect parts.
Unfortunately, this does present $$$ issues for many smaller customers.
-
Really? I will have to make a note of that for future reference. I take it then that $ROBROOT only changes in a "static" fashion, for systems where (for whatever reason) $WORLD is required to be different from $ROBROOT.
Am I correct in assuming that $ROBROOT_C is updated dynamically?