Hi, I’m ordering a pair of relay boards with the Web-I WebRelay ethernet interface and haven’t been able to confirm through reading the product info whether or not this interface will be using the older “Enhanced” command set or the newer “Advanced”. Is there a firmware version that will be viewable from BaseStation config tool to confirm this? I have already programmed a system to control this using the “Enhanced” command set, but would like to make use of the “macro” and “pulse” functions that have been added if possible. I haven’t looked all the way through it to compare, but hopefully the “Advanced” set is backward compatible with the “Enhanced” commands.
Also, can anyone confirm the length of time that the relay will pulse? Is this length of time configurable?
The Advanced ProXR command set is a feature of Fusion series controllers. So if you buy a Fusion controller, the Advanced ProXR command set will be available to you. If you purchase a ProXR or ProXR Lite series controller, you will received the “Enhanced” firmware. I hope this helps clarify. Please let us know if you have more questions.
Ryan
Thanks Ryan. I went back to the product selection, and can now see that the “Fusion” series is visible in the “Series” filter. I have only used the ProXR industrial relay controller series before, so am working from my experience of that series. I went through the exercise of adding to my cart what would be the equivalent Fusion series 24-channel SPDT relay board and it seems to be about $30 cheaper than the equivalent ProXR series board that we were planning on buying. Besides the functionality differences in the command set, the only major differences I can see is that the Fusion series board doesn’t have the UXP expansion port (don’t need) and doesn’t appear to have the LED indicators on the PCB (do like these). Is this correct? As long as the relays are the same quality and the control protocol is stable, I would probably choose the Fusion just for the pulse and macro functions.
Can you clarify the Pulse function question from my initial post?
Thank You
Fusion is our top of the line controller, it has 2 interface modules as well as 2 UXP ports for expansion. It also has 16-Channel Analog to Digital converters that are shared with the UXP port. So you can choose between using the UXP Port or the ADC Inputs, but not both at the same time. Fusion does include the LED indicators on the board, this is a standard feature of all NCD relay controllers, regardless of series.
The relays are the same quality and the control protocol is very stable. Fusion REQUIRES that you send all command in API Mode. API mode wraps your command with a header and finishes the command with a checksum. ProXR works with or without API. We do NOT encourage customers to use ProXR commands without API, as this makes communications 100% stable and predictable.
Pulse functions are included with Fusion, they are not part of the ProXR Enhanced command set, as Fusion was created at a later time.
Please help me understand the Macro functions you are referring to and I will provide you with more detailed information if needed.
Hope this helps and please let me know if you need anything else!
Ryan
Hi Ryan, One more question. As mentioned I have done a significant amount of programming that I don’t want to replicate, so I want to make absolutely sure that if I go with the Fusion series (which I’m leaning toward because of the additional functionality) that I don’t have to rework all my code.
The Fusion Advanced Quick Start Guide states "Fusion controllers require all commands to be API Encoded. Please review the API Codec Quick Start Guide for proper implementation of API. "
However, in the API Codec Quick Start Guide it states "The API Codec does not interfere with standard communications in any way. If you send a standard command to an API capable controller, you will get a standard response. If you send an API Encoded command to an API capable controller, you will get an API Encoded response. So any controller that supports the API Codec is 100 percent backward compatible with standard communication protocols. "
Can you confirm which one of these statements is true? ie 1. Fusion controllers require all commands to be API Encoded or 2. An API capable controller (Fusion) can accept standard/enhanced ProXR commands.
Thanks!
API is required for fusion. API does not interfere with ProXR Standard, which is a very old version of firmware, which is now obsolete. What we are saying here is that if you send a API encoded command, the old ProXR Standard firmware will ignore the API frame and process the payload of the command. In other words, it won’t interfere, but it will not benefit either. A common command for testing communications with a ProXR controller is:
254 33
Sending these bytes will return the value 85
The same command API encoded looks like this:
170 2 254 33 203
Sending these bytes will return the values: 170 1 85 0
While ProXR will process the 254 33 or the 170 2 254 33 203 command, Fusion will not process the 254 33 command, it will only process commands formatted 170 2 254 33 203.
I am glad you asked this on the forum, this is an important topic, as all future firmware will only process API encoded commands. Despite being longer and more complicated, they actually execute faster and they are tolerant to long delays over the internet when working with TCP communications. Since they are checksum validated, API commands are considered to be more reliable.
OK, that clears that up for me. Looks like if I want the additional functionality of Fusion, I’d need to rework my code. I’ll have to think that over for a bit before deciding on which series of controller I’m going to purchase. Thanks for your assistance!
Hi Ryan, I have received my boards and am now reworking my code to work with the API code set. Couple questions have come up. I understand that in Base Station you can select an action and see the command as it should be encoded. But is it possible to send these commands manually (enter in the command, not press a button), either through base station or through a terminal emulator like Putty, for testing purposes?
Also, I don’t see a way to use the pulse functionality from Base Station, and I unclear on the command structure that is laid out in the manual. I’ve been unable to decipher what it means when it says to use the 16 bit LSB and MSB values for the relay. Please explain, and provide examples, if their indeed is nowhere in BaseStation to simulate these commands. Thanks!
"Pulse Selected Relay
Pulses the selected Relay for a very brief period of time. This command requires a 16-Bit Relay Value using Relay LSB and MSB Values. The fifth byte of this command must be 1 to trigger the pulse option. After the relay is pulsed, this command will return 85 (0x55) to the user.
Send Bytes: Byte 1: Byte 2: Byte 3: Byte 4: Byte 5:
Function: Header Command Relay LSB Relay MSB Pulse
Decimal Values: 254 148 0-255 0-255 1 "
Yes, you can send commands to the controller through a terminal as long as you are sending byte values (NOT ASCII Values, this will not work). Be sure to configure your software for bytes. Alternatively, install Base Station. Run Base Station and choose the “Comm Operator” button. This should launch a trial version of software that we use for sending/receiving commands to our controllers during development. Comm Operator is amazing, and is our favorite tool, as it will also encode NCD commands into API format. The developer of the software is also an employee, so he is accessible if you need to learn to use it. We also have a Comm Operator Quick Start guide in the Learn section of our site (I suggest starting there).
As for the Pulse Selected Relay command, just send 254, 148, 0, 0, 1 (be sure to encode this command). It should pulse the first relay. To pulse the second relay, send 254, 148, 0, 1, 1. You can ignore MSB and always set it to 0. LSB we choose which relay to pulse from 0 to 255, 0 being the first relay, 1 being the second relay, etc. BE SURE TO API ENCODE, I cannot stress this enough!
Ryan, That comm operator software is just what I was looking for, very handy. BTW, just to clarify that in the example you gave for controlling the second relay the command should be 254, 148, 1, 0, 1. As you said the MSB can be ignored and it’s the 4th byte, not the 3rd. Thanks!