Copyright © 2014 by Professional Control Solutions, LLC
All Rights reserved
Professional Control Solutions LLC
Let me introduce myself:
My name is Danny Campbell and I worked for the first 26 in the Information Technology field starting out as a COBOL mainframe programmer. Over the years I picked up quite a few different computer languages and went from mainframes to minicomputers to networked versions of ever more powerful PCs. I have played various roles in the IT field ending up in the late 1990s in a LAN operations management role. After a few years in this role, I was looking for something new and different. My company had a growing VIdeo Conferencing department that wanted to move from ISDN communications to IP. This looked like the perfect opportunity to play with some new equipment and get back into a hands-on position so I switched departments in 2001.
The idea of controlling actual devices rather than just moving data around appealed to me.
At the same time, we were having issues with our control systems that had been developed by an AV integrator, I decided that AMX was the way for our company to move forward. Since one of my favorite activities was writing code, I attended the AMX programming I and programming II classes and then passed the certification test. One interesting thing was that since my company was an end-user, we had to pay for my classes. My Programmer II class had all of the dealers drop out at the last minute, so I had a week working 1 on 1 with the instructor.
The reason I went with AMX over Crestron was the programming methodology. Basically I wanted to use a programming language rather than a drag and drop interface. I don't have anything against the systems produced by Crestron developers, but I enjoy the lower-level interaction with the systems.
I have developed systems for 75 different organizations in the past 10 years. Some of these were for one system, while others had as many as 60 different systems within the organization. These end-users include state, federal and local government agencies, religious organizations, universities, museums, corporations, medical facilities, and military bases. I do not do residential work.
I have also worked from the programming interface standpoint with many different audio processors. Like many of the audio processors, each Biamp Systems unit has a specific number of input and output ports. Unlike the others however, the Biamp units are not constrained in what happens between the time a signal comes into the input port and gets to the output port. The systems are programmed and provide for a greater amount of flexibility in both manipulating and routing the audio signals, but also in building complex system using multiple units. This is why I decided to take the training on the Biamp products. And as a benefit to my customers, if they choose to use both AMX and Biamp equipment, I can do both and they don't need to schedule a programmer for the AMX and a programmer for the dsp on-site.
One final note. PCS is not a dealer for equipment from AMX or Biamp. I only develop software and device configuration files.
Let's discuss Source Code:
Source code availability is a touchy subject among programmers. Many do not load the source files onto the AMX masters, and if they do they will add passwords to the files.They will also password-protect the touch panel configurations. PCS provides all of the source code and documentation to my customer (generally the AV integration company) and the end-user. As for who can do what with it, here is the information that I add into my quotes and contracts:
After the final payment for the project is received, AV Integrator and CUSTOMER will be supplied with a CD (or electronically transferred file) containing the source code loaded onto the systems.
Some of the code that will be used has been developed by Professional Control Solutions, LLC for use on this and other projects. Complete source code, documentation, and object code will be made available to both the AV Integrator and CUSTOMER as part of the code/documentation CD. Both the AV Integrator and CUSTOMER are free to modify, copy, or reuse this code as part of any future systems, but PCS, LLC will retain full rights to the code for use on future projects for other customers.
Additional code supplied by AMX will also be used to develop the systems. AMX provides some source code, documentation, and object code as part of their development package. All code and documentation provided by AMX will be part of the CD, but it is understood that source code may not be available for some support modules. Any and all software from AMX is subject to the AMX License Agreement. These files are also available for download from the AMX.COM website.
The master controllers in the system will have the AMX .SRC file loaded onto the flash drive of the master. This is a compressed backup version of the source code loaded onto that particular system. Using this file and the development software supplied by AMX, a qualified programmer can recreate the system from this file. This file is not password protected, and is a basic ZIP format file.
Touch panel source files are loaded onto each panel, and are not password protected. Using AMX software, these files can be downloaded directly from the touch panel.
The CD will contain both uncompressed versions of the file folder for the project, as well as an exported project file (.AXW) that can be imported into the NetLinx Studio application to provide the complete workspace for development and modification.
Module files will allow for the various hardware components to be swapped (either model or manufacturer) without major changes being required to the control system code. For example, a Sharp display could be replaced in the future with a display from another manufacturer with only minor modifications required to the control system code.
Remote Installs: While I have done complete systems remotely I do prefer to spend some time at the job site during the system installation and testing phase. It is extremely difficult to test and debug using remote control software, and a technician is also tied up setting switches and being my eyes and ears during a remote install.
Proper equipment: I have been to some secure government sites that seem to be in total shock when they learn that I need to take a laptop into the room in order to load and test a system. I understand no cell phone, no internet access, no wireless LAN, and no pictures. But I do need to take the tools of my trade into the room.
Coding style: Along the lines of not giving the customer source code, some programmers like to write code that is overly complicated. Some to make it hard to understand, and others appear to be attempting to show the next programmer how clever they are. I prefer to keep the code as simple as possible and provide plenty of comments. I don't plan on being the person you get to make modifications two years from now. It would be nice, but I don't expect it. In the software development business, all that is really valuable to us is our time. I want to be able to look at the code and quickly understand what it is doing and I expect the the person following me wants the same. So my source code may be more lines than the other guy, but it will be as simple and easy to follow as I can make it.
Touch panels: I am not a graphic artist. I generally use touch panel templates that are available from AMX and modify them for the particular job. I can and will create a completely custom panel design if you require it, but it will take much longer to produce.
Modules: The AMX NetLinx language allows for code to be developed as a module. In this case, the module is a complete program that is generally developed to handle the low-level control of a specific device while providing a common interface to the main program that uses it. For example, the control protocol for a NEC display is completely different than that for a Sharp display. The module provides an interface to the main program that standardizes the functions such as turning the device on and off, changing channels, changing inputs, and so on. Modules can be written in native NexLinx or in Java. Most AMX-provided modules are written in Java and do not contain source code. My modules are written in NetLinx and I provide the source code and a document outlining the use of the module in the same format that AMX uses for their modules. Many of the Java modules are large and contain control of every feature of a particular device. This is because they are sometimes written by the equipment manufacturer. PCS modules are bare bones and only have the features that are commonly needed in day-to-day operation.