Posts by Mischa

Quote from Pascal Kaufmann

Hi Mischa,

could you give a hint which *.dll you are using and how you access the shared memory?

Hi Pascal,

I use all standard libraries:

using System;
using System.IO;
using System.IO.MemoryMappedFiles;
using System.Linq;
using System.Net;
using System.Net.Sockets;
using System.Net.NetworkInformation;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading;
using System.Windows.Forms;
using System.Xml;
using Microsoft.Win32;

And accessing the shared memory is pretty trivial:

using (var memoryMappedFile = MemoryMappedFile.OpenExisting(Dns.GetHostName())){
   using (var viewAccessor = memoryMappedFile.CreateViewAccessor(
                           0, 0, MemoryMappedFileAccess.ReadWrite)){

   // Write data to the KRC
   viewAccessor.WriteArray(84, krcInputs, 0, 1024);

   // Read data from the KRC
   viewAccessor.ReadArray(84, currentData, 0, 2168);
   }
}

Feel free to share you use case

Quote from M.Ozkan

Hello Y200 Interface can run on real controller ?

Hi,

in theory yes, but I've never tried it. I only tested it with a KUKA Office PC (a real PC running KSS 8.6).

The question is, why do you need it, since the main purpose of the Y200 interface is to enable Virtual Commissioning?

Here is my sample project with KUKA: Machine Tending Digital Twin with Kuka

Quote from Marco Moretti

Hi Mischa, thanks for answering.

This is my current situation:

However, I didn't know Y200IpcName needed to be the KUKA PC name. I checked Settings -> About -> PC Name. Then I turned off SmartHMI, changed Y200IpcName to my PC Name and relaunched StartKRC. Unfortunately, this didn't solve the problem. I also tried restarting the virtual machine, but nothing changed.

I read again the Officelite document and it says that I need to use the controller's name as Y200IpcName. I tried Controller_1 but didn't work.

My Y200IpcName was "Y200_VRC_R1" which was my default setting and I remember it was what panic mode was using.
Do you have any suggestion on how to procede?

Hi,

yes, you are right the controller's name needs to be used as Y200IpcName, just my OfficeLite PC and Controller names are the same. Sorry for the confusion.

Some info about Y200IpcName: this will be the name of the Shared Memory File used by VRC Y200 TestClient (or used by your own server) to read/write the KRC data. If this name is wrong, you will not be able to do anything.

Note that after changing anything inside Y200Interface.config file, the Cold start needs to be performed. Also, VRC Y200 TestClient needs to be closed before.

As far as I remember, first, the KRC drivers should be On, and then the VRC Y200 TestClient opened. Otherwise, it did not work for me.

If you do everything correctly and it still does not work, I can only suggest uninstalling and installing the Y200 again.

Good luck!

Quote from Marco Moretti

Hi Mischa . I'm trying to use Y200 as well. I installed it following the instructions on the Officelite 8.6 pdf document (also with no VRC installed). Unfortunately, when I click on Visu, the VRC Y200 TestClient opens up but is unable to read data from the robot. All numbers are 0 and inputs and outputs are all turned off.
Do you happen to know any way of fixing this?

Hi Marco,

I usually get all 0's for all axes if the drivers are off, so are you sure the KRC drivers are on?

Also, you can check the Y200IpcName inside the C:\KRC\USER\Y200Interface.config file. It should be the KUKA PC name, but usually, this is configured automatically.

Otherwise, just do the cold start.

Let me know if it helps.

Hi Frost9222 and grunftz,

First of all, I want to point out that Y200 is not a server, it's just an interface on top of which you need to develop your own server. I think this is the main misunderstanding.

Thus the main idea is:

1. Develop your own TCP server, that runs on KUKA PC. The server will do a couple of tasks:
   1. Create TCP/IP socket and listen for the clients.
      
   2. Read the shared memory file. So the Y200 interface reads the data from KRC and writes it to the shared memory. Y200 also reads the shared memory inputs and writes them to the KRC.
   3. Send the data to the client.
   4. Receive the data from the client and write it to the shared memory.
2. Develop your own client application that runs on any PC on the network.
   1. Create TCP/IP Socket and connect to the server.
   2. Receive the data from the server.
   3. Split the received bytes into the needed information: joint values, inputs, outputs, etc.
   4. Use (display) the received data.
   5. Send the data to the server.

I hope this helps a lot!

Quote from roni blacher

Hi

do you succeed to connect to kuka 8.6 / 8.7 ( y200 interface change)

I tested the Y200 interface with V8.5 and also with V8.6.

(Edited!!!)

Hi,

I was able to connect to KUKA OfficeLite and KUKA Office PC (real PC that runs KSS 8.6) through the Y200 interface and I hope my experience can help somebody. Please, see the detailed communication diagram attached.

Briefly about the main thing: the Server is a service program, which, in connection with the Y200 Interface, allows the coupling between the OLP application and the virtual robot controller (VRC) application KUKA.OfficeLite over TCP/IP network.

From my experience:

1. Y200 does not have to be licensed.

2. The VRC and Y200 interfaces cannot be installed together on the KRC virtual image, otherwise the Y200 interface will not work properly.

3. Y200 interface only works with KSS 8.5 and higher.

4. Use network address translation (NAT): the virtual machine and the host system share a single network identity that is not visible outside the network.

5. C:\KRC\User\Y200Interface.config file contains the Y200IpcName - the shared-memory name to access the KRC data.

6. The following data are stored on the shared memory: Inputs $IN[], Outputs $OUT[], Axis-specific position $AXIS_ACT, Cartesian position $POS_ACT, Current base $BASE and Current tool $TOOL. The Inputs can be read/written, but the outputs are only read access.

7. The server and the client mentioned here are developed by myself. Y200 is not a server, but only an interface used to exchange the data between KRC and shared memory.

Sorry, I cannot share the source code, but feel free to ask any specific questions.

Y200 - interface for simulation programs other than KUKA.Sim Pro, e.g. WinMOD.

Y200 gives access to controller Inputs $IN[], Outputs $OUT[], Axis-specific position $AXIS_ACT, Cartesian position $POS_ACT, Current base and Current tool information.

The problem is that there is no information on how to work with this interface

The one we have in KUKA_OfficeLite_85_en.pdf is definitely not enough.

Hello,

Does anyone have experience working with the Y200 interface in OfficeLite? I have OfficeLite_KSS8.5 and since Y200 interface is available and does not have to be licensed, I try to read the controller information. Is it possible to access the data with an external application that runs on the host machine? I know it is possible to purchase Y200 Remote Server that will transfer the data through TCP/IP, but it is not my case.

Does this mean that I need to create my own server on the virtual machine that will read the data from Y200 interface and transfer it to the host?

Do you have any example application of PrimaryInterOp.Cross3Krc.dll library?

Thank you in advance!

Thank you, SkyeFire!

Now I see the important condition to make it work with BASE shift:

1. The original Robot Base and Vision Base must be co-located

SkyeFire,

The concept works exactly as you described with pick_offset.A limitation to +/- 179.99.

I think that BASE shifting idea will work only if you do not have the rotation. For example, the points in BASE_DATA[1] and shifted BASE_DATA[2]

BASE_DATA[1]={X 1000.0,Y 1000.0,Z 100.0,A 0.0,B 0.0,C 0.0}
BASE_DATA[2]={X 1100.0,Y 1100.0,Z 300.0,A -100.0,B 0.0,C 0.0}

will be totally in the different position, because the rotation of BASE.A was performed.

That is why the concept of shifting the point was used.

SkyeFire,

1. This is the concept of the previous projects that I do not want to change. I think there should not be any difference to shift the Base or Reference Point, or there is? Also, how you can rotate the base if your reference position is not in the center of your Base?
2. The vision system is stationary.
3. When Offset.A value is 0 the A6=20 degree, it is because the middle of possible gripper rotation is also shifted by 20 degrees.

I have the limits +/- 179.99 degrees, as you suggested, so the offset every time is the shortest path.

Reducing the Pick position to a FRAME variable does not help, but I think you are right, making the motion LIN will do the right trick.

I tryed to use Geometric Operator only for point rotation in TOOL coordinat system. It works only with negative values of offset. With big positive offset values, it rotates in the negative direction, even the start moving point and reference point have same A angle. So the path planner cannot solve it by himself and I could make to work only with this code:

XPICKING_POS=Xref_input


IF pick_offset.A<0 THEN
   A_reversed_offset.A = - pick_offset.A
   XPICKING_POS = Xref_point : A_reversed_offset ; Rotate PICKING_POS with A angle of active Tool coordinate system
ELSE
   XPICKING_POS.A = Xref_point.A + pick_offset.A ; Add rotation angle to PICKING_POS
ENDIF


; Shift PICKING_POS along every axis of active Base coordinate system
XPICKING_POS.X=Xref_point.X + pick_offset.X 
XPICKING_POS.Y=Xref_point.Y + pick_offset.Y
XPICKING_POS.Z=Xref_point.Z + pick_offset.Z

It does not look like the best code, but it actually works.

You cannot evaluate the robot just by knowing how old is it and how many hours it worked before, also the pictures are great, but they do not tell you the accuracy of the robot. I have the experience to work with the second-hand robots and almost all had gear movements when you push any axes by hand. That definitely will make you a lot of problems in the future. Thereby, you need to examine any robot by checking its movements by yourself.

Also, the robot that you showed has a short arm. I would recommend long arm robot, but, of course, it depends on the scale of the part that you want to mill.

I want to point out one more serious problem of KRC2 - the limited memory. It means, that every few hours, in my case it was every 2 hours, you need to go to your robot, delete the old one and copy the next step programs. This is most annoying. This limitation was solved only in KRC4 with KUKA.CNC optional package.

1-4 - My advice is to start working with CAM software, where you can check robot reachability, layout, the height of pedestrian that you need and the need of turntable. The is a few CAM softwares that give you 30 days trial version and the "ready to mill" cells that you can test.

5 - I have the experience to use HSD spindle with water cooling system and, also, the very cheap fan cooling AREL spindle. You need to consider that some parts can be milled for a few days without stop, that why the cooling of your spindle is very important. I had a problem with fan cooling spindle during one-week nonstop milling.

6-7 - You need to have one long tool for rough milling (for example, the cylindrical mill with 350 mm long and 30 mm in diameter) and few rounded sharp tools - 5,10,15 mm in diameter. Generally, the longer your tool is, the less problem you will get with programming. All tools that I use is custom made, because of specific length requirements.

SkyeFire, at the beginning I was trying to do the same as you explained. I offset the Reference Position with Pick Offset using the Geometrik Operator:

FRAME pick_offset={X 100.0000,Y 100.0000,Z 200.0000,A -100.0,B 0.0,C 0.0}
DECL E6POS XPICKING_POS={X 610.000,Y -1540.00,Z -193.000,A 7.000,B 0.0,C -180.000}
E6POS Xref_pos={X 510.000,Y -1640.00,Z -393.000,A 107.000,B 0.0,C 180.000,S 6,T 50,E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0}


Xpicking_pos = pick_offset : Xref_pos

And it works fine without rotation angle "A". As I understand, it shifts reference position with the offset in active Base, so I rotate the point according to Base coordinate system and this is not correct. At list this is what I got - my point became in totally different position than it should be. Please, correct me if I am wrong.

Thereby, I have changed the calculations to:

XPICKING_POS = Xref_pos
XPICKING_POS.X=XPICKING_POS.X + pick_offset.X
XPICKING_POS.Y=XPICKING_POS.Y + pick_offset.Y
XPICKING_POS.Z=XPICKING_POS.Z + pick_offset.Z
XPICKING_POS.A=XPICKING_POS.A + pick_offset.A

But after that, I got the "A6 axis limit error", as the reference position is taught in positive rotation of A6 and the offset was -100. That is why I came to the calculation of "T" value.

Do you think there is another way of doing this?

Yes! This is so simply)

Hi guys!

I have a palletizing robot V8.3.33 and use a camera to receive the picking offset. During the high possible rotation degree - from -180 to +180 I need to change the last bit of "T" in E6POS. Firstly I tried to solve this problem as:

IF XPICKING_POS.A < A_zero_switching_degree THEN 
   XPICKING_POS.T='B100000' B_OR XPICKING_POS.T
ENDIF

And if A6 goes belove zero it will change the last bit to "1". But when the position changes, the "zero switching degree" of A (RZ) also changes, so I cannot use it. As I understand I need somehow to calculate the Turn bits for every new point. Please, correct me if I am wrong.

Any suggestions how to figure it out?

Hi! I want to change the jog coordinates from "W/WORLD" to "WORLD", but I do not have TOGGLE WRIST JOG in FUNCTION menu (see picture attached). Does somebody know how to activate it?

Hello,

After long time I want to post some small notes, how to set up the system with Directory Loader.
All you need - is to configure the global variables in $CONFIG.DAT in the Fold KRDIRLOADER GLOBALS. See KUKA.DirectoryLoader 2.2 manual (For KUKA System Software 8.2, 8.2 sr and 8.3), page 13.

After that, if you have KRDLTRIGGER (can be Input, Output or Flag) = TRUE - the loading process will start. Do not forget, that it does not work in T1/T2 mode.