Posts by LowerCaseDream

Hi everyone.

I just downloaded the trial version of KUKA.Sim 4.1 and tried to connect to the robot I'm using on Officelite.

Officelite has KSS 8.6.2 and Kernel system version KS V8.6.170

This is what I managed to get to:

As you hopefully can see, I managed to connect to Officelite and can import and export projects between KUKA.Sim and Officelite.

However, when I move the robot on Officelite I can't get it to happen in KUKA.Sim.

On KUKA Xpert I found a document about KUKA.Sim where it explained that, in the "CONNECTION" ribbon, there should be an option "Synchronize Robot Position" just below "Simulation Configuration", which does exactly what I need.

Does anyone have any idea on why that option might not be present?

Quote from Mischa

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!

Display More

Hi Mischa. Unfortunately I tried but didn't have any luck, I have no idea what the problem is about. Thanks nonetheless for the help!

Quote from Mischa

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 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?

Quote from Mischa

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!

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?

Quote from panic mode

there is Kuka.SimPro and Kuka.SimLayout but i have never heard of KUKA.Sim.

besides i do not use any of them and I am not really paying attention to products i don't have... but...

are you sure about that? You are planning on using OL and SimPro and Y200?

as far as i know, SimPro bundles OfficeLite but connection between two requires VRC option and... so far it was mentioned that VRC may be incompatible with Y200.

Hi panic mode, sorry for the late reply but I didn't use computers in these few days. I checked on the marketplace and there seems to be a KUKA.Sim product valid for 1 year:


However, I won't be using KUKA.Sim, but a simulation software called ISG-Virtuos (which is what I was referring to in my last post).

Quote from Marco Moretti

However, I'm afraid that I still have to make the connection Officelite - Y200 work if I want to use a simulator different from KUKA.Sim.

And obviously you're right about VRC and Y200 being incompatible together, at the moment I only have the second one installed.

Quote from panic mode

instead of addressing IO directly, use signals.

for example nobody can know what those IOs really are:

Code

WAIT FOR $IN[666]
$OUT[777]=TRUE

that is not very readable and in case of a problem or porting code to another robot, it would be painful to maintain since available/mapped IO may be different and one would need to go through dozens of files to make changes, for example replace input 666 with input 333 etc.

it is MUCH better to declare signals such as:

Code

SIGNAL iPartPresent $IN[666]
SIGNAL oGripperClose $OUT[777]

and then use them all programs. This makes programs MUCH more readable - including displayed WAIT messages:

Code

WAIT FOR iPartPresent 
oGripperClose  = TRUE

And if you need to do some changes, you do not need to modify actual programs, all the code remains the same - you can just change one line in declarations by replacing 666 with 333 and you are done!

now if you want to run programs in OfficeLite there is no need for butchering all the programs to replace inputs and outputs with suitable substitutes. it is enough to do a search/replace and 10 seconds later 100s of IOs are remapped to something that you can control in OL. All changes are in just one file - where the declarations are. Programs remain the same. Example

Code

DECL BOOL iPartPresent = FALSE  ; $IN[666]
DECL BOOL oGripperClose = FALSE ; $OUT[777]

and now your OfficeLite is ready to run everything but since there are no pesky inputs to mess with, you can control the values of declared variables through either built in Variable Overview or an external application. if that external application can access variables in PLC, your simulation setup prep work is done - it is time to have some fun.

the part that would not work exactly like that are couple of handshake signals used in EXT mode.

Starting programming from scratch is usually difficult and takes time. and broke students may not be rich but they have plenty of time...

when working with Windows API to enslave some application, key is finding the correct info (handle etc.). there is tons of things that Windows reports and there are functions to get or set pretty much anything. AutoIt has own spy tool but there are others. Here is an example of old one but very nice one called Show Window. IT displays info of the object that is under the mouse cursor (no clicking needed). Note that it sniffs out caption, size etc from just about anything. This is needed to know what to look for when writing own programs and to verify that your code is doing what is supposed to do.

Display More

Thanks a lot for all the info, panic. I really appreciate it. I will look more about this type of programming tomorrow, the concept seems really interesting. However, I'm afraid that I still have to make the connection Officelite - Y200 work if I want to use a simulator different from KUKA.Sim. Have you ever tried using a sim different from KUKA.Sim and, in case the answer is positive, did you need Y200?

Quote from panic mode

not sure what the Y-NET is and how to convince PLC to support it.

It seems to be another interface, I guess similar to Y200. On the Officelite pdf (for version 8.6):

Quote from panic mode

and since i do symbolic programming anyway, it is easy to adapt declarations only - KRL programs stay the same and would not know or care about the difference.

I didn't really get this, also because I don't have any notion on symbolic programming. But I'd be interested in learning more, it seems really interesting.

Quote from panic mode

in case of a TwinCat, there is a runtime on my own machine. this is handy for testing PLC code. and i can easily read/write TwinCat variables (examples are on Beckhoff website).

I think I get what you're saying here, however I'm doing my thesis right now, so my empirical knowledge is quite limited. However, I know that on TwinCat you can simulate PLC within the PC (if this is what you're saying) so I was planning on doing that.

Quote from panic mode

if i really wanted to make use of the actual robot inputs, i could do that right now - using Y200. and i don't even know what interfaces it exposes. and it does not matter... over the years i have created many programs that can control other programs using Windows API. (btw this is also what scripting with Auto-It does.) so it is possible to check and influence the state of any control (including inputs displayed on Y200 form).

This is incredibly interesting, and an approach I didn't even consider. I went and read about AutoIt and it seems that, among many things, it can simulate keystrokes and mouse movements. If I manage to get Y200 to work (and it seems to be a huge leap at the moment) I guess I could:
1) Simulate PLC on PC1
2) Send data from PC1 to PC2 via ethernet
3) Send data from PC2 to Officelite (running on PC2)
4) Within Officelite, have a program which analyses the data coming in and, based on which input I need to activate, simulate a mouse click on the inputs and activate them

However I'd need to learn this type of programming from the beginning, and this program seems to be way easier said than done. However, do you think this could be the right approach? Also, if you wanted to write a program which changes the $INs, how would you approach it (so if I decide to go through with this at least I won't take wrong paths at the beginning)?

Quote from panic mode

the point is that everything is doable. the question is just of cost/benefit ratio.

Yeah I guess so... Since I'm a broke student doing my thesis I guess I have no better option than doing stuff by myself!

Quote from panic mode

how is PLC supposed to communicate with Y200?

On the Officelite PDF from KUKA I read: "The interfaces (Y200 and Y-NET) can be used to read and write $IN[1] to $IN[8192]", which is what I want an external PLC to do. I configured the I/O communication on my project which had a EtherCAT net. Officelite doesn't support fieldbus hardware configuration in the projects, so I figured Y200 was the only way to write the $INs signals. However, I have no clue if that is possible, I was asking about that in the first post:

Quote from Marco Moretti

I wanted to send PLC data to Officelite and have them modify $INs through Y200 (is it possible? Or there's another way to achieve this?)

Also, I have to simulate the robot on an external simulation environment, for which I definitely need Y200 to work (from the Officelite PDF: "For connection to another simulation program (from KUKA.Sim), the Y200Interface software must be installed on the virtual image").

So for now I'm just trying to read robot data through Y200Interface, which I can't manage to do. If I manage to do that, at least I can connect Officelite to the external simulation software and make that work.
Another problem is to have an external PLC to write robot's $INs, which I think is a quite important feature so I thought there was an easy way to do so, but I don't have a clue on how to do that.
I thought the problems were both related to Y200, so I wrote about both of them here. If I was wrong, then I'm sorry for the confusion.

Quote from panic mode

what you described so far makes no sense. your posts are contradicting. "sending PLC data to OL" is opposite of "just reading from robot"

Sorry, maybe I didn't explain myself at best.
The final goal is to create communication from PLC to OL through Y200, so sending signal from PLC to Officelite and also the other way back. However, for now, I'm just trying to read data from robot to see if I can get Y200 to at least partially work. Unfortunately I can't.

Quote from panic mode

do you mind stating what exactly you did and how? posts 5 and 19 are pretty clear.

Sure. About post 5:
I logged in as a high priority user (don't remember if Expert of higher), then went on Start-up --> Additional Software --> New Software and selected Y200. Then I pressed install, received the message of succesful installation with the requirement of restarting pc. I turned off pc and turned it on again. KUKA SmartHMI started with no problem and the Y200 purple logo appeared on the bottom right, as it should.

Post 19 is more about requirements then actual steps, however:
I don't have VRC installed. In the past I had installed them both, but even uninstalling VRC wouldn't make Y200 work. Now I only installed Y200.
I'm also using NAT, as recommended in that post.

The only thing that I can think of that could create a problem is the fact that I'm trying to use Y200 just to read from the robot and maybe it needs a full configuration (with also a source which sends signal).

Also, the thing you said about having to configure the project to use Y200 is something I haven't read anywhere, so that was an interesting point you made.

Quote from panic mode

check this out:

Post

RE: Access Y200 interface in OfficeLite

where can i find Y200 interface files version 2.0

y200.cs / Y200CInt.cs / Y200Clnt.dll

for OfficeLite 8.6/8.7

roni blacher

October 20, 2021 at 12:58 PM

I already read that and followed the steps written by Mischa, but didn't manage to get it to work unfortunately. The only thing that I can think of is that I didn't set up the server for the communication, but I think I should have been able to read the data from the robot nonetheless.

Quote from panic mode

I did not use it in a long time but as i recall, Y200 was quite finicky...

one had to integrate it into a project (and that was hassle #1), deploy, activate etc.

there is a config which did not need any change if remember correctly.

then on start one had to launch the client inconveniently and hope it works. when it did work it was interesting but... that's about it. It was all in German, no import of long texts, no reconnect option, even color scheme was not friendly so i gave up.

for a moment i did consider making my own version but lack of documentation and my lack of free time were enough to steer me away from this.

Hi panic mode . Unfortunately, I had kind of pictured the scenario reading the other post on Y200. However, I didn't know you had to integrate it in the actual project. Do you know/remember anything about how to do that?

And if not with Y200, do you know how I can send signals to Officelite and connect these external signals to $INs?

Hi everyone, this time I have a problem with the Y200 Interface.

I'm trying to replicate a etherCAT communication between a PLC (I'm simulating the PLC, so it's a PC, really) and a robot controller (I'm using Officelite KSS 8.6).
I wanted to send PLC data to Officelite and have them modify $INs through Y200 (is it possible? Or there's another way to achieve this?)
However, when I click on Visu it shows that Y200 can't read data from the robot.
I tried modifying the Y200 config file and also leaving it to default state... Nothing happens.
Since Y200 is almost not documented at all (which leads me to believe it should be fairly easy to use) I don't know how to solve my problem or if using Y200 would allow me to achieve my simulated communication.

Quote from hermann

It is possible to switch kinematically integrated external axis to asynchronous (not for base kinematics), but for example for a turn table. See the chapter about "$ASYNC_AXIS".

Yes, actually I was using $ASYNC_AXIS in another part of code but I couldn't test it at the time. Some time after, I read that part of the KUKA document I uploaded before which seems to say that ASYPTP automatically switches the axis to asynchronous.

However, everything works setting $ASYNC_AXIS, so thanks a lot to both you and SkyeFire

Quote from SkyeFire

ASYPTP and $EX_KIN are basically mutually exclusive. A kinematically integrated external axis cannot be switched into the Async mode that allows ASYPTP.

Hi SkyeFire and thanks for answering.
My settings for $EX_KIN are:

DECL EX_KIN $EX_KIN={ET1 #EASYS,ET2 #NONE,ET3 #NONE,ET4 #NONE,ET5 #NONE,ET6 #NONE}

Should I change something? The external axis is used synchronously in some parts of the program (which was made by someone else, I'm modifying it), so I'm afraid that changing something will create some problems. However, if that's the only way, I'll make the required changes.

Quote from hermann

There exist several requirements for asyptp movements:

- there must be configured a external axis

- the external axis must be configured/switched as asynchronous

Hi hermann, thanks for answering.
The external axis is configured correctly, I can jog it and it can be moved synchronously.

Before I could test my code I thought that I had to switch the ext axis to asynchronous to execute an ASYPTP. However, on KUKA's document about ext axis I read this:

Which made me believe the switch was executed directly from the ASYPTP instruction... Am I wrong?

Hi everyone.
I'm very new to KUKA, so I set up an easy piece of code to understand how asynchronous motion works:

;TEST 1: Movement ASYPTP
   ASYPTP {E1 500}
   
   WHILE $POS_ACT.E1 <> 500
      ;Stay here
   ENDWHILE

Unfortunately, nothing happens. Instead of the WHILE I was using HALT, but figured that could have been the cause for the robot not moving (even though that doesn't convince me, really).
I read about $EX_KIN in another thread, but its setting seems fine.

I'm running the code on Officelite, KSS 8.6.2.
Any help is deeply appreciated.

Quote from panic mode

On boot, all axes in OL are at zero. You need to move them to suitable position or open up soft limits.

That is not how it works. $CHCK_MOVENA tell to KSS if it is permissible to have $MOVE_ENABLE mapped to 1025 (always TRUE) when controller is in EXT mode. That does not change value of $MOVE_ENABLE which still need to be TRUE if you want to move robot.

So set $MOVE_ENABLE to 1025.

Thank you so much, panic mode. Everything is green and ready to go.
At least until I try to set up and use Y200, that is

Quote from panic mode

OL does not support fieldbus networks. Delete KEB (X44 bus) and deploy again.

I did that and now have only these errors:

The external axis is at 0.00mm, I have no idea why.
The second error is even stranger to me. It seems that it depends on $MOVE_ENABLE being FALSE (which it is). However, I set

$CHCK_MOVENA to FALSE in the option.dat file (it was TRUE before), so the controller shouldn't block me from enabling the drives because of that signal...

Quote from panic mode

to simulate KSS 8.5 project, you need OL 8.5.

to simulate KSS 8.6 project, you need OL 8.6.

one cannot simply massage 8.5 project and relevant options into working on OL 8.6 (or the other way around). the only option (other than obtaining correct version of OL or OPS or KRC) is to create new project from scratch for target KSS, replace options with compatible ones, convert any user files (KRL programs, UserTech etc.) and import them into new project. And i should know because I have done the exact same thing on several occasions.

Few tips:

1. Note that WoV projects created from scratch are not complete. One need to add some files manually from correct KSS versions.

2. I never dump any KSS files (things that come with controller) from one KSS version to another. They must be always from exact same version. Even slight version differences can lead to problems as seen on KSS8.5.6 /8.5.8 because KUKA chose to manipulate files and move things around.

3. Getting files to match (even on a correct KSS) may still mean that more than one step is needed. An example of this is when option packages are involved. During installation of an option, files on controller are modified. So you do not want to just dump all changes into newly created WoV project. First you need to get clean project working. Then get it working with all options. Take that working project from controller and then you have something to use as a starting point ... Now you can start adding user files (KRL programs UserTech files etc.).

4. In general - fewer options means faster results so i tend to strip out unnecessary ones.

Display More

Hi panic mode, thanks for stepping in.
About point 1: that explains a lot of troubles that also newly created projects brought me, thanks for writing this info.
About keeping all KSS files: the company I'm doing my thesis at is starting to program their robot just now. Up to this point they always hired system integrators. This time, when hiring the system integrator, they specified that they wanted the source files, so the workvisual project is the only thing that I have available at the moment, since the robot is no longer here at the factory. However, that's definitely a valid tip, I'll remember that.

However, after tweaking for a while with the project, I managed to get to this point:

Apparently the external axis is at 0.00mm. The motion enable signal is supposed to come from external plc via etherCAT.

Considering I'm working on officelite only and I didn't actually connect any robot to etherCAT in the simulation, could these errors only depend on that? Or there probably still are errors within the project files?