Introduction
The Fusion® Series is our fourth generation relay controller offering the ultimate relay control solution . . . without exception.
Fusion controllers are the most powerful relay controllers we have ever manufactured. While the learning curve is modest, there are key elements that must be discussed as a foundation to any Fusion series controller. This guide should be considered a starting point for understanding and using the Fusion series controllers. We strongly encourage all Fusion users to review this guide carefully, as many important questions are answered that are pertinent to the initial use of Fusion Series controllers.
Firmware
Before we get started, there are a few things we need all users to be aware of regarding Fusion Firmware.
- We plan to upgrade the firmware. If you are a software developer, plan on reviewing the EEPROM Quick Start Guide and learning how to read the current firmware version number; it may be necessary for your software to adapt to behavioral or command set differences between versions. We reserve the right to refine and tune the firmware, and at times, it may be necessary to make significant changes between versions that will likely affect the operation of your software. We always try to make everything backward compatible, but sometimes it is not possible to mix the old with new. We intend Fusion Series firmware to evolve as our final embedded relay control platform.
- We ask software developers to pay close attention to this document; firmware changes will be posted at the end of this document.
- Fusion controllers must be returned to us for upgrade. It is not possible for customers to upgrade the firmware in their Fusion controllers, as special tools are used for writing the firmware into Fusion controllers.
- We will NOT be maintaining a library of old firmware for Fusion, so a downgrade will never be possible. It is absolutely essential for all customers to plan for a software migration path as we make improvements to Fusion.
- All firmware upgrades are free and are processed within 24 hours. This is standard policy for all NCD products. However, we do not pay shipping charges for firmware upgrades under any circumstances, even if there is a fault in the firmware.
- Bugs are a part of life. And though there are no known bugs in Fusion firmware at this time, we anticipate our customers will discover a few bugs in the firmware that will require patching. With over one billion combinations of settings possible with Fusion configuration software, we can only test individual routines within the firmware. It is not possible for us to test all interactions with other routines. However, we promise to patch all bugs that we have determined to be significant as soon as possible.
- We want all customers to know that we did not just hack this firmware together. Fusion firmware is solid and reliable, and is capable of some really amazing things when properly configured. Fusion firmware took
two and a half years to develop and is backed by over eighteen years of relay control experience.
What is a Fusion Controller?
Fusion controllers are essentially three separate relay controllers built into a single device. Each controller has the ability to control relays in very different ways. Specializing in autonomous and computer controlled switching applications, Fusion controllers are capable of operating by themselves or under computer control from anywhere in the world.
Taralist
Taralist (short for Time Activated Relay List) is used to control relays based on a time schedule. Simply build a schedule using Base Station software and load the schedule into the controller. You can simulate time changes and watch relays change state as you test each event in the list.
Reactor
Reactor is used to control relays based on sensors. Reactor is about
50 percent of the firmware built into a Fusion controller and is capable of making complex decisions to control relays based on sensors directly connected to a Fusion controller. Reactor also works with Remote Access to read sensors connected nearby with wireless Fusion controllers. Reactor has the ability to send Push Notifications to a server if certain conditions are triggered.
ProXR Advanced
ProXR Advanced provides computer control of relays and overrides control of Reactor and Taralist relays. ProXR Advanced is our Fourth Generation command set for controlling relays, offering more capabilities with fewer commands than ever before. ProXR is the industry standard for relay control applications and remains the most powerful relay control platform in the world.
Override Controller
All three relay controllers are linked together and managed by an Override controller that is used to manage who has control of relays.
Performance
Fusion series controllers really shine in the performance arena, as they are capable of processing commands from two communication technologies simultaneously. Fusion controllers are also capable of processing Reactor sensor limits, timers, and counters while handling Taralist event schedules. Configuring large numbers of Taralist events will slow down Reactor processing; however, reaction time is programmable. Default reaction time provides good response to sensors while keeping the CPU task load light. Increasing the reaction time will improve Reactor performance and load the CPU down further. Because Fusion series controllers rely heavily on the use of hardware and software interrupts, you will likely not see too much change in performance.
If you need to tune your Fusion controller for maximum performance, limit the Taralist schedule to a couple of hundred events or so. Also, configuring Reactor to trigger large numbers of events when a sensor limit is reached can slow down processing of other tasks.
Remote Access supports automatic monitoring of up to 16 remote locations. Because wireless communications is involved with Remote Access features, the more remote devices you acquire data from, the slower your response times will be. Remote Access represents the most powerful feature of the Fusion series controllers, but because data must be communicated over a wireless pathway, it is also the slowest. But do not worry too much, it is not unusably slow. If you are monitoring a single remote sensor, you can achieve reaction times of about 1 second (usually less, but just to be conservative). If you are monitoring 16 remote sensors, plan on reaction times in the 10-15 second range for EACH remote sensor.
Because performance is heavily based on user-configuration, it is not possible for us to provide performance data worthy of practical use beyond general estimates. Some experimentation will be required.
Software
Base Station Software
The learning curve for Fusion controllers can be intimidating if you do not start in the right place. Base Station software is a necessary tool for using Fusion controllers. Base Station helps you configure your Fusion controller and explore Fusion features, providing you with links to quick start guides in the areas of interest for your application. This methodology significantly reduces the amount of information that must be reviewed, making learning and integration much faster. If you cannot use Base Station software, you cannot use the Fusion controller. Base Station software consists of about 75 percent of our development efforts, as opposed to the other 25 percent which was dedicated to developing the microprocessor that works with Base Station. Base Station is compatible with all Windows XP or later computers. Base Station is not available for the Linux or Mac platform, but we are working on a web-based configuration platform for Fusion using the WiNet Gateway. We hope to release this configuration option by the end of 2014.
The latest version of Base Station Software can always be downloaded here: ncd.io/start
Comm Operator
Comm Operator is integrated into Base Station software. Comm Operator is an essential tool for speaking to a Fusion class controller at the command level. If you are a programmer, do not plan on using a Fusion controller without Comm Operator. Comm Operator allows you to send and receive numeric-based commands to a Fusion controller for activating relays and controlling various functions. API Encoding is integrated into Comm Operator, which GREATLY simplifies software development. The Comm Operator Quick Start Guide will provide you with the important tips you need to get started. If you are a programmer, plan on spending some time with Comm Operator before you develop your software; it will save you countless hours of head scratching.
Important Notes to Software Developers
If you are a software developer examining the command set, you may find the commands listed in the manuals do not work in your program. By default, Fusion controllers do not accept commands that are not sent in API format. While it is possible to turn off this setting in Fusion Device Configuration, we do NOT recommend this practice as some Fusion functions will not process unless called in API format to prevent potential memory corruption. We have made a few provisions in Comm Operator to allow you to test the commands shown in the product manuals. Most importantly, the API Quick Start Guide should be the first resource you examine BEFORE reviewing the command set.
API
So why is API such a big deal? Internet Communications. API is what allows Base Station to configure a fusion controller over the internet from anywhere in the world. Data can take a while to travel across an internet connection and can arrive at a device at an unpredictable rate. API has the necessary routines in place to accommodate direct communications from your software to a device anywhere in the world, regardless of internet connection speed or delays between packets. API also has numerous benefits in wireless and Mesh Networking applications, where data packets may be lost. Fusion controllers force our customers to develop in API format, which has a real-world, long-term benefit for all communication technologies. When you learn API, you learn to use our products anywhere in the world over an internet connection. In applications that do not require an internet connection, API greatly improves communications speed and command processing reliability. All communication technologies will benefit from API with regard to speed and/or reliability.
Software Structure
To save a lot of time and frustration in writing software for Fusion or any other NCD product, we strongly recommend that all customers develop a single routine for Encoding and Decoding API commands and responses. These routines should be the first element of software you develop. We have provided complete details on this practice within the API Quick Start Guide. If you are using Visual Studio, we always freely provide our Base Station source code to help customers get started.
Device Settings
Fusion Controllers use two communication ports for communication to computers. Uploading and Downloading settings can take a while. Plan on using a ZUSB, which provides USB communications to the Fusion controller during initial configuration and when you need to transfer large numbers of settings. Though it is not required, it will save you a lot of time. Also plan on setting the baud rate of the ZUSB to 2,000,000. This will improve transfer speed. Also keep in mind that we can manufacture Fusion controllers with your configuration pre-loaded into the controller at no additional cost, which could save you a lot of time, just email us your configuration files, and we will preload them into your next Fusion controller.
Fusion With and Without the TLEE Expansion Module
The TLEE expansion module defines the way a Fusion controller is configured in Base Station software. The Fusion CPU has a small amount of memory used to store essential settings. By itself, it can do many things. However, the really powerful features require the memory resources of the TLEE expansion module. Here is a general list of differences you can expect:
- Base Station: Base Station software is always required to use a Fusion controller. Base Station detects the presence of the TLEE expansion module and changes its behavior accordingly. Base Station will not allow you to edit settings that require the TLEE expansion, so users will experience a more simplified version of Base Station when working with controllers that do not have a TLEE installed. Most of the windows that appear in Base Station software were written without the TLEE installed, and then completely re-designed with the TLEE installed. So you should expect many more windows and options to be available on controllers with the TLEE installed.
- ProXR Advanced: Most of the ProXR Advanced Commands work without the TLEE expansion. However, the TLEE expansion is required if you want to store relay patterns. Up to 256 relay patterns can be stored and instantly recalled if the TLEE expansion module is available.
- Reactor Generation 2: Approximately one-fifth of Reactor capabilities are possible without the TLEE expansion. For example, only two analog sensor limits are possible without the TLEE as opposed to seven sensor limits with the TLEE. Additionally, many more event triggers are available if the TLEE expansion module is used. Without the TLEE, Reactor capabilities are still very powerful and capable for most applications. If the TLEE is not installed, Reactor will be unable to access sensors on remote Fusion controllers (using the Remote Access features).
- Push Notifications are supported as a subset of Reactor features. Push Notifications allow your Fusion controller to send alerts to a server when sensor data reaches limits or when events are triggered (either by Taralist or Reactor). Push Notifications require the TLEE expansion module.
- Remote Access: The TLEE expansion enables the best part of Remote Access, the ability to tunnel and send commands to other Fusion controllers. Without the TLEE, Fusion controllers are able to respond to sensor data requests (acting as a slave to other Fusion controllers), but it is not possible for a Fusion controller to initiate a sensor data request without the TLEE (to act as a Master, a TLEE is required).
- Taralist: Taralist is 100 percent reliant on the TLEE expansion module. Taralist capabilities are not possible without the TLEE expansion module.
Dual Port Interface
At the time of writing, all Fusion controllers have a Dual Interface communication port. You may use these two communication ports to talk to computers, servers, or mobile devices. For the most part, these ports are identical to each other and may be used independently. No port has any particular priority over the other. However, Port Number 2 is the Remote Access port. The Remote Access Port has very special features that enable Fusion controllers to talk to other Fusion controllers. Remote Access can be used to send commands and to access sensors in other wireless locations. By default, Fusion firmware is burned with Remote Access configured on Port 2. You do not really need to do anything to disable Remote Access if you do not plan on using it. Remote Access does not get in the way when not in use.
Remote Access
NOTICE: REMOTE ACCESS IS EXPERIMENTAL AND CANNOT BE IMPROVED AS WE ARE OUT OF MEMORY SPACE IN THE CURRENT CPU.
Remote Access does many things for a Fusion controller, but special hardware must be used to fully take advantage of Remote Access.
Once Remote Access is enabled, the Fusion Controller has new capabilities available that allow many Fusion Controllers to act as one large relay controller. Remote Access is a data exchange protocol between Fusion controllers and is not generally used for computer-to-device communications. Remote Access frees you from the limits of two interface ports, the Remote Access Port links all other controllers together so that they may all be accessed by other controllers and interface technologies in other locations.
Put simply, Remote Access features allow Fusion controllers to communicate with each other as a group. While you give up Port 2 on all devices, you gain access to the entire group of Fusion controllers using Port 1 on every Fusion controller. This allows access to a group of Fusion controllers from every supported interface technology at the same time. So it is definitely possible to have a USB Fusion controller talking to the group, a Wi-Fi Fusion controller talking to the group, along with a Bluetooth, Ethernet and RS-232 controllers all talking to the same collective group of Fusion controllers.
Remote Access is also integrated into Reactor features. Reactor can use Remote Access to collect sensor data from remote wireless Fusion controllers, making decisions to control relays based on remote sensor input. A single Fusion controller can act as a sensor node for many Fusion controllers in the local area.
Remote Access also enables Tunneling features. Tunneling is when you use a Fusion controller to take complete control of another Fusion controller. When you enter the tunnel, your software will talk to the remote device exclusively. When you exit the tunnel, control is returned to the Fusion controller that entered the tunnel.
There are three essential requirements to enable the full Remote Access features:
- A TLEE expansion module must be installed
- A 802.15.4 communication module set to API format installed in Port 2 of your Fusion Controller
- Must be configured. Use Base Station software and click Device Configuration. Make SURE the UART Communication Technology is set to “802.15.4 API Wireless Remote Access” on Port 2.
A TLEE expansion module is not required if you just need a Fusion controller to act as a remote sensor node for other Fusion controllers.
Override Controller
Fusion controllers consist of three completely separate relay control technologies. Each relay control technology will control relays in its own way based on user configuration. The Override controller manages the priority system for every relay. It is not enough for a relay to be on or off. The state of the relay is simply an end result to the priority system. What is really important is which relay control technology has turned the relay on or off. Base Station software color codes each relay, which clearly indicates the on/off status of each relay and which relay control technology has control of the relay. Keep in mind, this is a priority based system, and taking manual control of a relay will prevent other control technologies from controlling the same relay.
The default priority for every relay is as follows:
Lowest Priority: Taralist
Taralist has the lowest relay control priority. Taralist is used to control relays based on a time schedule. By default, all relays are controlled at the Taralist priority level, even if you do not have a TLEE expansion module installed. Every other relay control technology can override a Taralist relay. Base Station highlights Taralist controlled relays in blue.
Middle Priority: Reactor
Reactor has priority over Taralist by default. The theory being that sensors should have higher priority over time schedules, as they should be used to make exceptions to time schedules. When a Reactor Event triggers a relay, Taralist no longer controls the same relay. Base Station highlights Reactor controlled relays in red.
Highest Priority: ProXR Advanced
ProXR Advanced has the highest priority level. The theory being that the user should always be able to instantly override a relay controlled by Taralist or Reactor. Base Station highlights ProXR controlled relays in green.
There are a few special exceptions to this priority system that are worthy of mention. Taralist and Reactor can work together to control a relay. The priority system for relay control may be altered so that a relay may be controlled by Reactor OR Taralist. Meaning if either Reactor or Taralist want the relay to turn on, the relay will activate. Similarly, the priority system can be changed so that both Reactor AND Taralist must turn the relay on before the relay will activate. Both of these priority systems are very useful for applications that need sensors and time schedules to work together to activate a relay. When relay priorities are altered in this way, the settings are stored in non-volatile EEPROM and the Fusion controller will reboot or power-up with the new priority system in place.
TIP: Right-Click on color-coded boxes in the Override controller to change priority level of relays.
Taralist has the lowest priority level control of relays, but it actually has the highest priority level control of the entire system. Time schedules may be configured to return control of relays back to Taralist based on a time schedule. Taralist has the ability to reboot the Fusion controller, which will reset the priority levels of all relays back to their default power-up state. Users should also note that Taralist has the ability to trigger Reactor events based on a time schedule. While Taralist triggered the Reactor Events, the Reactor Events are “owned” by Reactor, so these relays will light up red in Base Station software, even though they were triggered by Taralist.
Also worth noting, Relay Flashing is “owned” by ProXR. Taralist and Reactor both have the ability to activate and deactivate the ProXR Flashing function. These relays will be green in Base Station Software, even though they may be triggered by Reactor or Taralist.
Getting Started
In this guide, we have just scratched the surface of what a Fusion controller is actually capable of. We did not want to bombard our customers with a complicated product manual, so we have broken up the information into sections that can be reviewed based on subject matter. Fusion controllers are capable of so much more than what is described here, but we prefer an interactive approach to learning our products, as it is generally easier for customers to grasp. So what’s next? You are going to need Base Station software. It may be downloaded at the following link: ncd.io/start
Use Base Station to get familiar with the controller
The first window of Base Station will help you discover your Fusion controller for the first time. If you experience communication problems, use the Quick Start Guides found on the first window of Base Station software to troubleshoot the communication technology you are using. Base Station will automatically discover and list Wi-Fi, Ethernet, Web-i, and WiNet devices within about 10 seconds, so please be patient and wait for these devices to appear. If they are not listed automatically, please review the Quick Start Guides for the communication technology you are using.
As you experiment with Base Station, you may want to read more about a window that appears. Many windows have a “MORE” button in the upper right corner. Use this “MORE” button to reveal access to appropriate Quick Start Guides and to see bytes of data as you click on interface elements. The commands will be displayed in API format along with a brief description. Once you are finished exploring Base Station software, use Comm Operator to send commands to a Fusion controller. Be SURE to read the API Codec Quick Start Guide BEFORE developing any software for the Fusion series controllers.
Essential Tools for Developers:
- Base Station Software
- Comm Operator (Integrated into Base Station Software)
- API Codec Quick Start Guide
NOTE: We freely provide source code to our Base Station software as a courtesy to all customers upon request. Please contact us using the contact information found on the last page of this quick start guide.
Electrical Requirements
- Use a DEDICATED Power Supply for ProXR Controllers.
Never share the power supply of a ProXR Controller with inductive loads such as motor, valves, solenoids, transformers, or any other device that electrically contaminates the power supply. - Do not use a wall wart type unregulated power supply.
- Use only a computer grade regulated switcher supply rated at 12 Volts DC, 1.25 amps or greater.
- Use a supply rated for more amperage when powering multiple boards.
- DC power should never travel greater than 20 feet. A separate power supply should be used for each controller if controllers are not located within 20 feet of each other.
- Relay coils are rated at 12 volts DC. Higher voltages will shorten the coil life. Lower voltages may cause unreliable operation, but will not damage the controller.
- ProXR series controllers may be used in 12 volt automotive electrical systems.
- Minimum operating voltage 9 VDC, Maximum 13.5 VDC.
Notice: Never install NCD Relay Controllers near High Power RF Transmitters, such as CB Radio and Emergency Vehicle Voice/Data Transmitters. These Devices may cause all relays to turn off or other undesirable operation.
Fusion Hardware Diagrams
Hardware diagrams may be found in the Fusion Hardware Reference Guide on our website. Use the hardware reference guide to assist you with all physical connections to your Fusion controller.
Mechanical Drawings
Complete mechanical drawings for each device can be found on the product description page of each controller at ncd.io.
Two-Way Communication
All ProXR devices support two-way communication. All software developed for ProXR Series Controllers MUST be capable of two-way communications. ProXR controllers should not be used in One-Way Communication Applications without consultation with NCD Technical Support.
History Log: NCD Relay Controllers
Initial Series was released in 1995, limited to 100 Units of 4- and 8-Channel RS-232-Only controllers; this series is out of production replaced by the Pro Series.
1.0 Pro Series
Currently in production and includes emulation for the earlier Non-Pro Series controller. Technologically, this product line is obsolete, but our customer base is so strong that we cannot discontinue this series.
Ultra and Hybrid series were released in limited numbers along with a few low-cost 1- and 2-channel relay controllers. These controllers served as a development platform for the ProXR Standard Series. These controllers are still available by special request, but are no longer a standard production item.
2.0 to 2.2 ProXR Standard Family (Including ProXR Lite)
Available by special request only, this series has undergone a CPU/Firmware upgrade to ProXR Enhanced.
3.0 to 3.4 ProXR Enhanced Family (Including ProXR Lite)
Currently in production, this series remains the industry standard for relay control applications and retains most ProXR Standard features when possible.
Version Log: Fusion Series
4.0.0 Fusion Series Initial Release Version
Fusion Troubleshooting
In the event a Fusion controller does not respond as expected, the following troubleshooting tips can help get you back on track. In many cases, Fusion problems are easily resolved. We have organized this section according to the type of problem you may be experiencing.
Relay Control Problems
Problem: Unable to Control Relays
Solution 1: Make Sure Automatic Refreshing is turned on or send the Manual Relay Refreshing command
Solution 2: Taralist Holiday Mode may prevent activation of Relays when using a Taralist schedule.
Solution 3: Make SURE the Fusion controller was NOT powered up in configuration mode (Program/Run Jumper set to Program). Powering a Fusion controller in Configuration mode completely disables relay control, as this function is designed to recover a Fusion controller or to change important settings. Fusion controllers should NEVER be used in Configuration mode. Configuration mode should be considered for temporary use only.
Problem: Relays Turn On and then Back Off
Solution: High inductive voltages will interfere with relay control logic when controlling inductive devices such as motors, solenoids, valves, pumps, or anything with a magnetic coil. Please visit the following link for instructions: Induction Article
Taralist Problems
Problem: Cannot Turn Holiday Mode On or Off
Solution: An event in the event list may have control of the Holiday Mode parameter. Edit your Taralist events and make the Holiday events inactive.
Problem: Unable to Control Relays from Taralist
Solution: Make Sure Taralist Processing is On, Make Sure Holiday Mode is Off using Base Station Software
Reactor Problems
Problem: Unable to Control Relays from Reactor
Solution: Make sure Reactor processing is On using Base Station Software
ProXR Problems
Problem: Unable to Control Relays
Solution: Make sure Automatic Refreshing is turned on.
Communication Problems
Problem: Unable to send commands listed in the manuals.
Solution: Commands in the Fusion Quick Start Guides are shown without API Encoding. To reduce the chances of communication errors, all commands shown in all quick start guides must be API Encoded with a checksum. API Encoding is supported by COMM Operator (which is included as part of Base Station Software, ncd.io/start), allowing you to enter the commands shown in the guides into the COMM Operator terminal window. When commands are sent, the API Encoding feature will automatically reformat the command for API Encoding, saving you a lot of time in learning to develop for Fusion controllers.