Patrick Barron" />

SVC on Twitter    SVC on Facebook    SVC on LinkedIn

Related Articles

 

Evaluating Control Options

Nov 16, 2011 2:52 PM, By Patrick Barron

Making the case for IP control.


   Follow us on Twitter    

The entire socket management issue is an area where IP control can turn into a real nightmare. You have to open and close the connection on the proper IP port, of course, but it usually isn’t that simple. Some equipment is very easy to work with, and when you open the connection, it stays open and the system can send endless messages and receive replies from the equipment without any problems. But in many cases, the connection can unexpectedly time out and drop without warning. Managing this is not an automatic process like it would be on a computer. An endless number of network issues that have nothing to do with the control system could cause the network to slow down or stop operating completely. As a programmer, you have to rely on the control system to send a message that the connection has dropped or that there is a problem. Typically this message does not happen instantly when the connection drops. It might be anywhere from 30 seconds up to several minutes before getting a message that the connection has dropped. If data is sent to the AV equipment after the connection drops but before the acknowledgement of that comes through, the data that you are trying to send to the equipment is not really being sent. You might get an error indicating an invalid command or you might not even know that there is a problem. As a programmer, you have a dilemma about whether to constantly send a message to keep the port open or take the risk that a connection has dropped and your data might not have been sent. Even if you are monitoring the connection, the control system might not know the true status of the IP connection. If the programmer decides to continually send messages, there is a risk of overtasking the network connection. Many systems have dozens of pieces of equipment that are controlled over IP, and if the code has to continually send messages, this has the potential to overwhelm the network connection and cause the system to run slow or it might crash completely. If RS-232 had been used instead of IP, none of this connection management would even be an issue. You would send data to the equipment over a hardwired RS-232 connection, and unless the equipment failed or the cable was damaged, you would be assured that the data you were trying to send went through. The same cannot be said for an IP connection.

One further wrinkle in this entire process is the equipment that requires a login and password in order to communicate. In addition to the typical opening and closing of the socket, there is the extra complexity of having to receive a message indicating that a login is required and the connection manager has to send the appropriate login reply at the correct time. Then another message has to be sent in response to the password prompt. All of this has to be done in the proper sequence in coordination with the socket being opened. The login procedure adds to the potential points of failure that was discussed earlier. The more possible places something can fail, the more likely it will be that a failure will occur. With equipment that requires a login, not only do you have to manage the socket connection itself to track the connection status but also you have to manage the logged in status. If you want to send a piece of data using RS-232, you just send it. But with IP, that requires a login; you can’t just send that data. You have to place that data into a queue that is held until the multitude of processes complete that allow you to be able to send that data. The connection has to be established, the system has to wait for the login prompt, the login has to be sent, the password prompt is received from the equipment, then the login password is sent. If all of that goes through and no error messages are received, only then can the piece of data you wanted to send in the first place be sent.

Many programmers have dozens and even hundreds of modules already written to work well using RS-232. The data is sent as needed without regard to checking a connection status or login status. If an integrator chooses to use IP when a viable RS-232 connection is available, it could mean that a great deal of extra work has to be spent rewriting modules to function properly with IP. The programmer is usually the last person on the job and the whole project is waiting on the programmer to finish. Extra time spent troubleshooting an IP connection, debugging conflicts on the network, or rewriting working modules is time that could be spent finalizing the code for the system.

When IP is Optimal

Analyze the equipment to determine if there are any advantages to using IP control and if there are features available through IP that are not available through RS-232. If there is not, consider why a choice would be made to use a method that is more difficult that does not offer any significant advantages. Overall, the process of communicating with equipment through IP is not trivial and should only be done when a distinct advantage is offered when compared to using RS-232. There are many instances where IP control is viable and preferred. In systems where the distance makes RS-232 impossible, a network connection could be used because it can extend to a farther distance. If a vast number of devices need to be controlled and the cost of adding RS-232 ports through the control system hardware becomes prohibitive, IP control can be a benefit. Certain equipment might not have RS-232 control available and IP is the only option. Hardware with key functions only available through IP control sometimes makes it necessary. Using IP control simply for the sake of saying you are using IP control introduces needless complexity and problems to the task of programming a system which is difficult enough already without added complications that are not necessary.

Our goal is to program a system that is reliable and failure-proof. A key way to do this is by designing a system with the least potential points of failure. The system engineer can design a video system that minimizes points of failure and the programmer can develop software that also minimizes points of failure. The responsibility lies with the integration company to develop the best solution that offers the highest reliability with the desired functionality. Knowing when to use IP control when other options are available is crucial to developing a successful system.



Acceptable Use Policy
blog comments powered by Disqus

Browse Back Issues
BROWSE ISSUES
  August 2014 Sound & Video Contractor Cover July 2014 Sound & Video Contractor Cover June 2014 Sound & Video Contractor Cover May 2014 Sound & Video Contractor Cover April 2014 Sound & Video Contractor Cover March 2014 Sound & Video Contractor Cover  
August 2014 July 2014 June 2014 May 2014 April 2014 March 2014