Dashboard Server connection timeout

klacourt

I've had success using a PLC to use UR Dashboard Server to start, stop, load, etc.  I have a new PLC (by customer request) that is being very finicky about the connection, such as needing to send a command twice, no response after a few minutes, etc.  Does the UR controller time out?  I presume it only allows one connection at a time?  Are there instances where the connection will go into lala land and not respond?  I'm trying to understand some of the strange behaviors I'm seeing, and figure out where to look for limits or problems...

In my previous application (that works well), I opened a new connection, sent and received data, then "quit" the connection for each command.  Is this the best practice?

matthewd92

We don’t use the dashboard server with a PLC but we do use it a lot. We generally open the connection, send whatever commands we need, may be a bunch and then close the connection when we are finished with it. I have seen some weird behavior when it’s left open all the time. Not sure if it’s with UR or the Linux OS they are running which I’m sure is handling all the TCP connections. 

klacourt

I did manage to get it working, and it is important to send the "quit" command when the PLC is done.  If not, the connection is left open, and the UR has to be rebooted to clear the connection.  So, connect, do what you need to, and quit.  I find this keeps it clean and functioning.

Thanks!

matthewd92

@klacourt Glad to hear you got it working, would you be able to share any of the PLC code that you have with the forum.  I am sure there are others that would like to learn more about how to work with the robot and other systems.

klacourt

For the record, this was using a L02 Mitsubishi PLC and straight ladder logic.  Unfortunately, I can't share code due to NDA restrictions.  I can give the concepts though.  It used the "Predefined Protocol" to set up TCP communications, and was framed around the code example in the PLC manual.  I set up states for connect, receive (Dashboard always responds on connect), transmit command, receive response, quit.  It is important to have pauses between states to allow communications to finish.  Other PLCs that have structured ladder or state programming are less picky about this.  I used a Do More BRX and it worked great with no complaints.  Fast too.  Always be sure to run the "quit" command when done - otherwise the connection hangs open, and the UR needs to restart to clear it.