well... in good hands everything is possible...
it also means to never underestimate someone's ability to wreck a good thing.. 
Thank you for your response Panic Mode
it also means to never underestimate someone's ability to wreck a good thing..
I very much agree with this, hence my caution. I have been researching KUKAVARPROXY for a few weeks now. I imagine this is hard to answer without looking at the system in question but I'm hoping you have some experience with this.
I was under the impression that KUKAVARPROXY will be able to operate independently from ethernetIP because I have seen papers where KUKAVARPROXY is used in collaboration with RSI. My concern is that KVP and RSI work together because KVP is TCP/IP and RSI is UDP. Is it likely that the KVP server will overwrite/interfere with ethernetIP because they both use TCP/IP? They do not need to work at the same time but it is important that the ethernetIP connection work when KVP is not running (because we do not want to wreck a good thing!).
Hopefully you have some experience/ guidance to share!
Thanks again
it is not TCP vs UDP, each of them has own port or virtual network interface as same physical interface of KLI is used for many things, like:
EthernetIP or ProfiNet (*note*)
WoV file transfer
File sharing (shared folder)
RSI
EtheretKRL
FastSendDriver
etc.
and of course all of those are meant to work independently and not clash...
note, EIP and PNET both use same resource (virtual5) so they cannot be used at the same time. it is either one or another or - neither...
Hello, i think it will be ok, KVP uses port 7000, you just open it inside KSS... So from my view is like using VNC viewer on port 5600 and KVP on port 7000 and PROFINET all together but ok i guess KVP is comunicating directly with VxWorks part of the controller... or for example when having PROFINET, or ETHERNET/IP and accessing the robot with WorkVisual over the same IP... But i could be wrong, you never know for sure until you try for yourself 😁... only issue i had with KVP when using Roboteam(2 robots) and KVP on both of them, only one robot in roboteam always got data when trying to send points each of them... I guess in Roboteam VxWorks ip changes, increases by one in each robot because they are also in network and KVP is setup only for default IP...
Fieldbusses (Ethernet/IP, Profinet, etc) are sensitive to packet delays. However, in most situations, it is possible to run significant non-Fieldbus traffic over the KLI alongside Fieldbus without causing any issues. If the non-Fieldbus traffic becomes too heavy, packet delays or loss can result. But it's hard to get to that point.
While I'm not privy to KUKAVarProxy's inner workings, I think it runs in the Windows side of the KRC. This means it automatically has lower priority that anything running in VxWorks. So if there is any traffic congesion, KVP is likely to start lagging first. I imagine your KVP process would have to be quite heavy to have any chance of interfering with your EIP.
yes, they are all Windows executables:
VarProxy SERVER is a an EXE created in VB6 and it runs on windows side on KPC.
VarProxy CLIENT demos are available in DotNET (C# , VB.NET)
I am planning to install KUKAVARPROXY
I don't want to sound like someone pushing his product, but why not take advantage of the simpler, clearer, and more open C3 Bridge Interface. KUKAVARPROXY certainly does its job too, but it's harder to install and practically undocumented.
While I'm not privy to KUKAVarProxy's inner workings, I think it runs in the Windows side of the KRC. This means it automatically has lower priority that anything running in VxWorks.
You're right!
On the technical side, both KUKAVARPROXY and C3 Bridge Interface use a COM subsystem (I mean Component Object Model, not RS232 port) called KUKA Cross 3.
The KUKA smartHMI interface (written in C#, by the way) also uses this software subsystem very extensively. In my opinion, KUKA Cross 3 is some kind of low-level software layer between the two operating systems. But it still running on Windows.
P.S. I'm just now working on a version of C3 Bridge 1.1, in which I would very much like to implement file transfers of KRL programs and hope that the system will compile them (i.e. they will be ready to run).
