Y200 Can't Read Data

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

Display More

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?

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

Oct 20th 2021

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

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

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

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

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

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

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.

Display More

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.