create new program without kuka software

Hi,

You can write your program with every editor, but you must to load the program from kuka's explorer.

If you have soft v5.x, you haye to change to "Expert" and find your file using the explorer in Kuka HMI, you copy from "Edit" menu and paste into R1, into the folder for works trajectories.

In lower versions, the procedure is similar, but I don't have any handy to be precise.

Hi,
Probably the word "kuka's explorer " is not the best word to define the manager of files in Kuka HMI, sorry.

You haven't to compile the programs.

You can paste your program to R1\programs from C:\, D:\ or usb device, but you must do it from kuka HMI.

If you want to write the program with the robot, you must go into R1\program and choose softkey "New", and select p.e "Modul".

theres ways to do it but its gonna cost you. there is a utility that you can use that will copy programs from a directory and reload them through the hmi on command, its a bit overkill for what your looking for though. so what your trying to do is write a program outside of the editing environment but your trying to get the robot to pull it from where your writing it to? why not have it reside within the robots krl directory?

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?

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:

FOR 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.

Hello SkyeFire,

NiamoR42 is a french guy, and he send me private message in french. I gave him a short response (normally, I don't do this, discussions should be made here, this is the code of a forum).

I told him nearly the same, but (now Mookie has to leave definitively the country), you did it better

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/France

Quote from Tilman

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/France

Hm! 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.

Hello SkyeFire,

Quote from SkyeFire

Not to mention lots of free time.

Yes! Or somebody, who knows how it works

You have seen perhaps the simulation of the KR6 in my video. It was not Kuka Sim, but OfficeLite with a virtual arm that I programmed myself (for economic reasons…). I used here the cross.ocx interface, but only for reading the position ($AXIS_ACT). I stopped playing with the cross.ocx at this level.

The programming is not very hard, if you know ActiveX. The main problem is that no documentation is available. For example to copy a file, it could be the function DownLoad:

short __fastcall DownLoad(BSTR strFile/*[in]*/, BSTR strKRCDest/*[in]*/, BSTR strOpt/*[in]*/);

But strOpt... Is it a timeout value? And the strKRCDest, what is the syntax of the path?

There is also the crosscommexe.exe interface. You can find some unofficial documents for it. This interface is a little more user friendly, but it is not supported on newer versions of the KSS any more.

After all, I prefer the solution that you explained, SkyeFire: transferring the positions. This solution is documented, you can realize it without any package (by using the RS232 interface), no problem with the guarantee of your robot… and you need less time to realize it

Greetings,
Tilman/France

Quote from Tilman

Hello SkyeFire,

NiamoR42 is a french guy, and he send me private message in french. I gave him a short response (normally, I don't do this, discussions should be made here, this is the code of a forum).

I told him nearly the same, but (now Mookie has to leave definitively the country), you did it better

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/France

Hi All, please see attached document. Is it what you search?

Wow! Thank you a lot!
I used another, inofficiel documentation for the crosscom.exe interface. Yours is much better!!!
Has somebody the same for the cross.ocx
Very best regards, and thank you again,
Tilman

Hi Tilman,
Have you initialized the cross.ocx in vb or got the documentation for this?