I'm working on a project where it's necessary to communicate between Main Control Unit (Just a PC) and KUKA KRC4. For that, Ethernet KRL 2.2 (for KRC4 8.3) package was chosen. Provided EthernetKRL documentation is quite brief, but enough to understand and ensure basic communication.
My task involves quite intensive communication where MCU acts as server and robot as client. Lets say I have 10 different queries, some of them use binary stream, some XML data option. I use binary stream when robot asks server about some information\data availability (and server request: yes or no). If data\information is available robot reconnects with different configuration file and receives data as XML structure. The difficulty lies in the fact that some requests must occur in parallel, independent of each other, because the requests calls happen in different submits (yeah, multisubmit module). Right now, this system is implemented in the following way -> I have separate sub ("Networking_manager.sub" ;)) which cycles all possible request, checks if this particular type of request is active (they can be activated from different subs), and if it is -> creates connection with proper configuration file, sends request, receives answer from server -> deactivates request ->move to next request type. So, robot constantly bombards the server with requests. Some times it works, but sometimes I receive errors about lost connection. Even if every RET variable returns 0 as result. And so, based on all the information above:
1. Is it possible to create multiple simultaneous connections from robot to server with EthernetKRL? This would solve the problem like a charm. Documentation states ("...The number of active connections is limited to 16."), but I didn't managed to test is successfully.
2. In my mind, there is another implementation option. Just make large single request which will contain all smaller requests with their status (active\inactive) and all "answer" data. So robot and MCU can just ping pong this single large data butch, changing necessary parts of it to communicate. Is it good option from your opinion?
3. How would you implement such communication with Ethernet KRL?
Thanks in advance!