We’re testing the NCD Relay Controller 4-Channel General Purpose SPDT + 8 Channel ADC ProXR Lite. As was suggested in a previous posting, we are polling the inputs every 50-msec and stopping when we change relay states. This seems to be working fine.
However, we are using a linux controller to provide the logic to monitor input states and command the relays - and have found that if the linux controller reboots, the ProXR Lite board begins sending abnormal serial output and requires that the 12VDC power is cycled to restore serial communications with the linux controller. How can we safeguard against this given that controller reboots will be part of normal maintenance processes?
I would like to check this here, so please let me know what the serial output of the Linux controller that initiates this behavior.
One way around the problem would be the use of E3C commands. You could use these commands to enable the device, send a command, and then disable the device with another command. This should safeguard against this type of problem, but I would like to validate this further by recreating your scenario here.
Thanks,
Ryan
Thanks for the note, Ryan. However, there no way to know the serial output of the Linux controller (RPi4 in this example) without installing some sort of sniffer between the controller and ProXR Lite board. And I’m not sure E3C commands help us given they must be sent over the serial port - which stops communicating. Given there may be instances of unexpected reboots, we wouldn’t be able to do this prior to event anyway. Are you able to reproduce this condition?
One more additional bit of information, Ryan. I’ve found that when the ProXR serial communications become corrupted witht he reboot, if I disconnect the USB cable and reconnect it to my windows laptop and start NCD BaseStation, if I go to the “AD8 Relay Activator/Event Generator” and simply “Save Settings,” it clears the condition. I don’t do anything else. Is there something similar I can do from the Linux controller? I assume it toggles Configuration and Run modes?
I’m afraid there is nothing I can do to replicate the problem without knowing the bytes that are sent during reboot. Comm Operator is part of Base Station Software ( https://ncd.io/start > Utilities Section of the Main Screen ) which can be used to monitor the serial port. E3C is still viable to help with this issue (though it may not completely solve the problem you describe), it’s definitely worth a try. Here’s a quick example:
Send 254 252 0 (This Enables the Device)
Send Relay Control Command
Send 254 252 255 (This will Disable the Device)
The theory being, the controller will always be disabled and will nullify all commands except E3C commands. The device is enabled only during command sequences and immediately disabled after the command.
One other possibility that I just thought of is wiring to the Raspberry Pi, it’s possible that a 10K Resistor connected between the Pi TX Line and 3.3V Line may suppress random outputs. You could also try 10K between Pi TX and Ground.
I just noticed your note, it appears you are using USB exclusively, and not the serial port.
You can try rebooting the controller (recommended if possible) : 254, 33, 140, 99
The AD8 Button is sending the following commands:
Storage Setup: 254, 33, 140, 86, 60
Data Storage: Command too Complex, see Base Station Source
There is a high probability the problem will be resolved by changing the baud rate as this will alter the byte structure significantly. I would suggest trying a few different baud rates to be sure.
Thanks,
Ryan
Thanks for the suggestions. Here’s what we found after trying them:
We tried connecting using 1200 and 9600 baud, but we didn’t get any responses even after power cycling before attempting at a different baud rate. Only at 115200 baud do we get responses from your serial commands.
We also tried sending the Device Reboot command sequence you suggested, and the combination of Storage Setup, Storage Cancel, and Device Reboot commands with a one second delay between each. Neither of these two command sets had any effect.
Specifics of what we see:
The anomalous behavior we are seeing is that there are dropped bytes in the responses. After a clean boot, the board responds to a 254, 166 command (Read all inputs) with 255, 255, 255, 255, 255, 255, 255, 255 (8 bytes). This continues to work fine until we reboot the Linux USB client without cycling power to the GPIO board.
Then it starts behaving anomalously. For the same command above, get between 3 and 6 bytes in response (all of them are the expected 255 value) instead of the expected 8 bytes. After a read timeout, we try again, always with the same result – fewer bytes in the response than expected. Cycling power to the board fixes the condition, but we can find no way to clear the condition through commands. The only two ways we can clear the conditions is (a) cycling power to the board (b) connecting to a Windows machine and saving settings from the Windows client, then re-connecting to our Linux controller.
Another idea:
Other than the serial interface, is there any other way your Windows client alters the state of the board? We have noticed that on Linux there are several devices other than the USB serial interface that appear when we connect the board. Perhaps one of these other interfaces could be used to reset the state?
It would be best to connect this controller to a computer and hold off on Linux for now. We need to run Base Station and make the baud rate settings change. Next, we need to validate these settings have changed and working correctly in Base Station. Change the baud rate to 1200 Baud in Base Station and make sure Base Station can talk to the controller at 1200 baud.
Once you have it working on a PC, only then can you move to the Linux computer. Please keep in mind, your software must also change to 1200 baud or you will not get a response from the controller. If you do not get a response, there is something wrong on the Linux side. Your best bet at resolving this problem is still going to be a baud rate change.
Addressing your specific questions:
Please MAKE SURE the controllers Program/RUN jumper is set to the RUN position. Run is for daily use and locks out access to sensitive memory locations. Only the Windows application should be used to change configuration of the board.
I really have no idea why you would see other devices appear when our board is connected, I rarely use LInux, so I am not sure about it’s behavior, but we have thousands of Linux users and we have other staff that may be able to answer this question. I really don’t think there’s a problem at the Linux OS level though, the fact that you have had it working suggests the drivers are working as intended. It’s virtually impossible for devices to interfere with each other regardless of operating system when working with Virtual COM devices.