of course but - if you have to ask that question, please get someone qualified to take care of it and show you the ropes. do not just bridge X11, that bypasses safety. wire it properly according to current regulations and cell needs which is determined in safety review.
and as manual shows, there is a wiring diagram.
as well as trip curve
which allows creating very simple test of the sensor:
one does not even need robot to test it. just a wrench, multimeter and the ability to interpret manual.
it is just a momentary switch. to test it you can connect it to a test circuit. continuity check with multimeter will do. then apply torque to the sensor to activate it. depending on type,(-S, -M, -X, -XL) as shown by graphs and tables in the manual.
startup mode is used for diagnostics only and it is only possible to use it in T1. To use other modes like AUT or EXT you need to complete cell comissioning which includes wiring of safety interface.
note address is ok. not sure if the DN slave is capable of 500kbps. wiring only shows one side and it looks like TEW individual conductors rather than proper DeviceNet cable (and no shield?).
CAT2 is a very simple product to test. Why not read the manual? Everything you need to know is in it.
Basically this is just a switch and to activate it, you need to apply torque. Torque limit depends on type so for details read the manual.
If cant we send data in background its useless.
sending data in the background is not a problem but that sentence got me thinking...
would you also say that those who did not learn, cannot read and interpret manual are also useless?
and please try to avoid creating chains of deleted posts. you may not see deleted posts but some people here see everything and trails of destruction are not much different than spam. that is not useful for those who try to keep this place clean and - useful
as mentioned before forum is not a substitute for formal education, so consider reading documentation or take training. when posting in forum, try to make the points clear and well defined. try to understand terms before using them.
for example real-time and background are not the same.
"real time" is relative and it simply means "sufficiently fast and consistent response time". and you did not define what is your "real time". for certain processes this could be value measured in picoseconds. for others it could be in minutes, hours or ... maybe weeks.
in case of industrial automation, "real time" is usually expected to be in the range of few milliseconds at most. therefore in case of KRC, term "real time" is normally reserved for things like RSI or FSD, because EthernetKRL may not be able to meet such times reliably.
"background" process is something that happens in parallel with something else. it does not say how fast response need to be.
on KRC one can use SPS to do things in the background. this could be opening connection and sending or receiving data (or both). this would allow sending and receiving data in the background - regardless what robot is presently doing, regardless if robot is faulted or if robot program is even selected... but SPS is NOT a priority task and it is NOT synchronous to robot program so execution times are NOT guaranteed to be consistent or reliable in any way. hence anything running in SPS is normally not seen as "real time"... but to be honest, that would really depend on your definition of "real time".
there seem to be misunderstanding of key concepts.
every TCP connection requires client and a server. that is part of TCP fundamentals and there is simply no way around it. and every TCP connection requires client to connect to server. (it must be client that initiates connection). once the connection is open, data exchange can take place.
consider another example:
when you type "robot-forum.com" in your browser and press enter or click on load page, your browser is a client and it is connecting to this site (which is hosted on some server). the point is that YOU (client) requests data from this forum (server). if you do not do that, this site will NEVER somehow magically and voluntarily open your browser and load the page you are reading right now. and if the forum is down for example (server is down), there is NOTHING you can do with your browser (client) to get the forum page to load. server always must be ready and running BEFORE client tries to connect to it.
so when you start demo EKI server and see "Waiting for connection", it means that server is ready to do its work. it is just waiting for some client to connect to it. so your robot controller or OL should have program code (created by you) that will open connection to this server. without that code on the robot, there is NO connection...
buffer is just a temporary storage. it is used to temporarily hold data before it is used.
there are two buffers - one to send and one to receive messages.
send buffer can only hold data for one message but message can be complex and have many elements. you can write bunch of elements one at a time until the buffer contains all required message data. (this is done using EKI_SetBool, EKI_SetInt, EKI_SetString etc.)
then you can issue send command (that would be EKI_Send) and entire message is sent out. this "send" action also clears the send buffer so you can start loading parts of the next message.
receiving buffer can hold multiple received messages. reason is that messages may be delivered quicker than they can be processed - for example if server sends a burst of several messages, they all will end up in the receiving buffer. note that receiving buffer is a queue (FIFO or LIFO) so when your program reads one of messages, that message is removed from the buffer. depending on configuration you can read either the oldest or newest message in the buffer but - you cannot read messages out of order (for example try to first read one that is in the middle of the buffer queue).
really, you can keep receiving messages endlessly (billions of messages) even if the size of receiving buffer is 512... or just 1. the important thing here is to empty buffer in order to make room for next message. and this "emptying" of receiving buffer is normally done by reading from the buffer (using EKI_GetBool, EKI_GetInt, EKI_GetString etc.)
suppose your receive message that contains INT, STRING, BOOL and you read INT,BOOL but not STRING... and it does not really matter which element was not read, we are simply considering case where some part of received message is not read entirely. this means that message is not going to be removed from buffer UNTIL it is read completely. but if the other node keeps on sending more messages, count of messages stored in the buffer will keep on increasing.... once you reach the configured message limit, error will be generated.
suppose we expect message containing INT, STRING, BOOL but the other side sends incomplete message (such as INT, STRING and without BOOL). if you try to use EKI_GetBool to read non-existent element of the message, there will also be a fault....
to manage things like this one need to dive deeper into EKI manual and learn about flow control, checking buffer (this is receiving buffer) etc.
if you are only sending data, there is nothing to worry about receiving buffer.
that is recent robot and basic warranty is 12 months. if the robot is still under warranty, why not let KUKA come and repair it? will cost you nothing.
that's the one...
every simulation has limitations. and they may not be always easy to compare.
i find that the posts are quite confusing...
my understanding is that there is no PLC, just KRC4 (EIP master) and IR_ETN (EIP slave).
when it comes to slaves:
some bus couplers will work (using defaults) without specific configuration made by user. they may be able to work just by having correct address and nothing more. others may require additional more detailed configuration including setting IO sizes, slot configuration, I/O mapping etc.
not sure if IR_ETN falls into one or another category.
when it comes to masters:
master need to know slaves and their parametrization. this is why configuration software used to configure master requires device description file for each of the slaves (EDS, GSD, ESI, GSDML, XML etc. depending which type of fieldbus is used). so yes, WorkVisual will need to get the EDS for the IR-ETN. for simple cases WorkVisual can also use generic EDS template but it is always preferred to use specific one if available.
also Workvisual uses different way to import device description files for EthernetIP (and only for EtherentIP). Check WoV and EthernetIP manuals
warning, such posts (software piracy) will get you banned.
as mentioned in post #4 issue is resolved
as mentioned i don't have yet OL8.6 and user is hard to reach and communicate with. restarting smartHMI is not nearly as practical as previously available option to reinitialize UserTech. if that is the only alternative to reboot, it is a huge setback and very poor choice by design team behind UserTech.
that is not explicit enough and it is easy to miss. do not assume or make it hard on those trying to help you. nobody ha time to follow all little clues and decipher what you got yourself info..
why can't you communicate that at the begin of the thread?
is it really that hard to post all relevant info about the system? did you ever read READ FIRST?
OL and KRC are NOT the same thing. in OL there is no hardware, no safety circuit, etc.
therefore there is no safety configuration in OL, so this menu entry is ALWAYS disabled.
did not use FRI but... one can always contact manufacturer for support
yes, rights management. that would be the main reason menu entry is disabled (grayed out)
no need to be sorry. that topic was created to guide new users to KUKA specific information like how to identify KSS version, where to get documentation and what are the the key manuals... (because there are many but you need to start somewhere).