Interrogate The Integration Expert

Oct. 27, 2008
Interfacing a door operator with access and bad code

Setting Up Custom Control Circuits
Q:
How do I interface a door operator with an access control system?

A: I overheard an architect explain the answer to your question recently during a job site meeting. He said, “It’s simply a matter of adding a timer module and some relays.” Easy, right? The architect changed his tune when the technician asked him if he could sketch out the wiring diagram.

    Setting up custom control circuits requires a certain level of technical competency and that a procedure is followed:
  • First, determine how the system is expected to operate,
  • Second, know the specifications for each device in the system. Then, figure out what you can do with what you have to work with.

Sometimes the system elements have enough inputs, outputs and programmable features to get you through. You may need to use additional timers and relay modules.

Also, there are other hurdles for you to overcome, such as the client changing his requirements after portions of the system (or the entire project) are already installed. There’s a large assortment of relay modules, power supplies and timer modules available. Learn what’s out there and familiarize yourself with the features and different applications possible with these modules.

Not the Code You Think It Is
Q:
Can you discuss Bad Code? Readers may be surprised.

A: Although building codes are frequently referred to as “The Code,” they are rarely, if ever, said to be bad. Building codes eventually become obsolete and then they are revised. Bad Code usually refers to microprocessor programming that crashes. Code comes in many forms, and, indeed, computers continue to assume the control of systems. Virtually everything is microprocessor controlled, and therefore contains “code.”

System integrators lately are being portrayed as computer gurus who write computer codes to solve their clients’ particular applications issues but very few site solutions are coded. Most are wired.

While most software applications do require data entry and configuration settings, these elemental processes can hardly be considered writing code. Writing code is an abstract process of composing machine language and operating systems.

Coding takes expertise and a lot of time to write, and, more importantly, to de-bug. In our modern era, when a system stops working after it has been working for awhile, it’s probably caused by a computer crashing, which, in turn, was probably caused by poorly written code. It could be a unique set of conditions and inputs which weren’t anticipated by the programmers and, therefore, not executable by the software. Some software is revised quite often.

When code is altered, it must be beta tested. Depending on the product, resolving bugs can be quick and painless, or they may be hits on your profits, and damage your relationship with your customer. Some products do not have the capability to upgrade this code. Other products can be updated through a phone line or with a PDA.

One sure way your company can protect itself from buggy codes is by never installing a product from rogue manufacturers or equipment which has been out for less than a year. This, however, is not always possible.

Security Dealer Technical Editor Tim O’Leary is a 30-year veteran of the security industry and a 10-year contributor to the magazine. O’Leary’s background encompasses having been a security consultant since 1986 and an independent security company owner/operator, in addition to his research and evaluation of new technologies and products introduced to the physical and electronic security fields. He is a member of the VBFAA (Virginia Burglar and Fire Alarm Association); certified for Electronic Security Technician and Sales by the VADCJS (Virginia Department of Criminal Justice Services); and, has served as a judge for the SIA New Product Showcase. Send your integration questions to [email protected].