EthernetKRL is fine, but if i have a choice, i would rather have robot side act as a client as it is more flexible arrangement. this way i can control all connections and an on each end. With server running on a external PC (also our product) we can do full diagnostics and know if the node is who we want to talk to or not. So if needed, we can have server reject connections from unwanted nodes. you simply cannot do that if the roles are reversed and the server is on the robot side (at least not conveniently).
Also this makes few things a bit nicer, setup is cleaner when multiple robots are connecting to same PC therefore all robots are set the exact same way, simulation in OL is also simpler, i can have each robot create more than one connection if needed, choice of ports is greater etc.
That makes sense. Sounds indeed like a more flexible setup that way.
So do you guys use RSI and implemented all acceleration, deceleration, boundary checking etc yourself on the robot? And then run a TCP client on the robot that can connector to a PC running a TCP server which will give commands?
Also, would below be true?
I indeed saw that the controller interpreter is a lower priority than the robot interpreter.
The task of the robot has a clear start and end point. Would it be possible to write a robot program for the robot interpreter that first does some general stuff, then by using EKI receive for a not set amount of time a not set amount of "commands" (new positions, tool on, etc) and only when triggered stop waiting for commands and maybe after that do some other general stuff? That way it is executed by the robot interpreter so it has high priority and CPU quota.
Also I saw that in the controller interpreter only asynchronous motion can be used (not sure if that is a practical limit for me), but that limitation would also be gone.
Thanks!