ProXR controllers have been the standard for relay control applications for many years. Over the years, we have improved firmware to add functionality. Several years ago, we migrated from a PIC16F690 processor to a PIC18F46K22 processor, which has more memory and runs 4 times faster. After this migration, we found it necessary to slow down the CPU to safer levels, as older software was not able to handle the ultra-low latency of the new CPU. NCD ProXR relay controllers have the ability to perform much faster by tuning a few settings. This guide will help you get the most performance out of your ProXR controller.
If you are developing your own software, please make sure you are properly supporting 2-way communications. In other words, send a command, wait for a reply, do not send another command until you receive a reply from the previous command. Since some commands execute faster than others, using a fixed delay is not an ideal way to improve speed. Also note that it is not possible to flood the controller with commands, as each command must be executed individually. ProXR controllers do support commands that allow control of multiple relays using a single command, so be sure to dig into the command set to make sure you are using the best commands for your application.
To get started, you will need Base Station software. Base Station is used to test ProXR controllers, and provides a comprehensive set of tools to make sure your controller is working properly. For the purposes of this tutorial, Base Station will be used to edit device configuration settings. Start by downloading and installing Base Station on your Windows computer:
- After running Base Station, click on the “Device Configuration”.
- The device configuration window displays many parameters that will improve speed.
- Take a good look at the “UART Delay Between TX Bytes”. This setting deliberately injects a delay between communication bytes. The default value of 10 can be reduced to a much lower speed, which will improve performance. In the window below, a value of 0 is shown, which effectively eliminates the delay between bytes. I would urge some caution with this setting, as having a little bit of a delay may be necessary for some applications.
Other settings that can reduce latency between relay control commands are highlighted below.
The “Number of Attached Relay Banks” setting can be reduced to the actual number of relay banks on your controller. By default, your ProXR controller thinks it’s talking to 512 relays. This setting maximizes compatibility for some of our customers who are talking to large arrays of relays. If you don’t have 512 relays on your controller, you should reduce this setting to improve speed. One Bank is equal to 8 relays. So if your ProXR controller is controlling 32 relays, reduce this value down to 4. If your ProXR controller has 24 relays, reduce this value down to 3, etc.
The “Serial Clock Delay” parameter is used to control how fast data is transferred from the CPU to the relay banks. A delay value of 15 is good for large arrays of relays, but for smaller relay groups, a value of 0 works great and improves speed.
In you are not familiar with API communications, now is a really good time to learn. API is required to get the most out of your ProXR controller, as it eliminates the need for a byte time-out. API makes your ProXR controller faster because it tells the ProXR controller exactly how much data it should expect. Without the extra information of data length, ProXR controllers have to wait until you stop sending data, then timeout and examine the packet for processing. Getting ride of this timeout period can easily double communication times, even though there is slightly more data. API has other benefits as well. API includes a checksum, which validates the receipt of the packet before processing. Any data with an invalid checksum is ignored, and this can seriously improve reliability for some applications. If you are thinking of controlling ProXR controllers over the internet using a Ethernet connection, API is absolutely mandatory. The latency of the internet is far too unpredictable to talk to low-level devices without some form of error checking. API is by far the best way to improve communication speed. Learn more about API here.