Evaluating Control Options
Nov 16, 2011 2:52 PM,
By Patrick Barron
Making the case for IP control.
There has been much discussion and commentary about the subject of AV and IT convergence and how the use of IP has migrated over to the world of AV and control systems. For the most part, this has been a positive occurrence and the traditional AV systems have benefitted greatly from the introduction of IP interfaces. But as often happens with new trends, there can be too much of a good thing. As great as the introduction of network and IP-based control has been, there are limitations we must recognize. As the famous comic book stated, “With great power comes great responsibility.” Audiovisual professionals need to use IP control wisely and find the applications where it will be most beneficial.
Because network and IP control has been such a hot topic, there is temptation to design systems with IP control for no reason other than just to say that you’re using IP control. Understand that IP control is just one of several viable options. All control options should be evaluated to determine which solution is best for a particular application. RS-232 is still a very reliable method for control and should be considered each time when the control method is being debated. Salespeople fall into the trap of selling systems with IP control because they saw it at a tradeshow (where everything always works perfectly, right?). Designers and engineers fall into the trap because they want to push the envelope with the newest and greatest technology. We need to remember: Just because you can doesn’t mean you should. This particularly applies to the desire to control everything possible using IP.
Recent graduates are used to doing everything over IP while programming in college. The thought of using RS-232 control seems foreign to them. They think of RS-232 like we think of the rotary telephone and 8-track tapes. To them, the question is, “Why would you ever not use IP control if it is available?” Many don’t have the years of field experience in troubleshooting systems to draw from when making design decisions. While IP connections managed from a computer may seem trivial and almost flippant, when done from a control system, it opens up a whole list of potential problems to be overcome.
The goal of any control system is to function reliably. If it isn’t reliable and doesn’t work, the method of control is irrelevant. One of the troubleshooting methods in solving system problems is to eliminate points of failure. In any system, every connection, every cable, and every piece of equipment is a potential point of failure. The most dependable system is where we have a source, a cable, and a destination. In that case, there are only three items that could fail: the source, cable, or display. When we add a switcher, we add another cable as well. Now that system has gone from three potential failure points to five. If we add a patch panel, wall plate, floor box, or other connections, we add more failure points. Large systems that have scalers, converters, and switchers that cascade into other switchers make troubleshooting extremely difficult when trying to isolate where the failure occurs.
IP vs. RS -232
The same logic applies when discussing control methods. Let’s analyze the differences in troubleshooting and maintaining an IP connection vs. an RS-232 connection, assuming that the protocol is used correctly and the code is written properly. In systems with simple RS-232, the cable essentially is the only failure point. In most cases a null modem adapter can solve 95 percent of all problems with RS-232, but when dealing with IP, the potential points of failure are multiplied greatly. We have to know the baud rate with RS-232. IP connections require that we know the IP port we are communicating through. RS-232 has a few standard baud rates that are frequently used, so even if we don’t know the baud rate, we can guess it within two or three tries. With IP connections, there are more than 10,000 valid IP ports. If the standard telnet port doesn’t work and we don’t know the port to use, we could spend a lifetime trying to guess what it might be. Programmers writing code and troubleshooting software always want to use the time available in the most efficient manner possible. With RS-232, there are very few things that might go wrong, but with IP, the list of items that can be a problem is extensive. If a programmer has to spend five minutes troubleshooting a network or IP problem, that’s five minutes too long. Trying to save a few dollars by not buying the necessary hardware to have a serial port available for control can turn into huge cost deficits if a large number of man hours are spent solving network issues that otherwise would be irrelevant.
The traditional control system is designed around an embedded processor, not a Windows or Mac machine with virtually unlimited processor speed and memory. A control system measures processor speed in hundreds of MIPS and measures memory in megabytes while the top of the line computer is approaching speeds of more than 100,000 MIPS with memory in the multiple gigabyte range. When dealing with IP we need to understand that an AV control processor has only a fraction of the capability of a typical computer. The IP connection management for a normal computer is an everyday process and thousands of manhours have gone into the development of stable IP socket connections to a multitude of different types of equipment. The socket connection management on a computer has so many layers, and there is so much processing going on behind the scenes that it would make the normal person’s head spin to comprehend how it all works. Yet we take it for granted every day when we browse to a website or stream music from the Internet. A control processor does not have the same kind of development with the IP socket connection management, and much of that management is left to the individual programmer to handle. A programmer could spend 10 years straight doing nothing but IP socket connection management and still barely scratch the surface of the amount of development that has been done to handle the IP traffic on your desktop computer. We need to realize that connecting to a piece of AV equipment over IP is not as simple as browsing to a website on your computer. There is not a magic solution available where everything instantly works. Each piece of equipment desiring to be controlled should be evaluated to see if IP control is really the best option or if there are other approaches that will work better.
Evaluating Control Options
Nov 16, 2011 2:52 PM,
By Patrick Barron
Making the case for IP control.
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.
