Hi, we have several of the SN65HVD12D RS485 adapters. One of them is behaving oddly, we’ll set it to run at 9600 baud but then after a few power cycles when we send F6 to the controller it responds with 01 25 80 instead of 00 25 80 which is the expected response for 9600 baud. We’ve tried doing the factory reset but the problem persists. Is there anything else we should try? If the converter is faulty is it possible to exchange it?
Thanks in advance!
I will recommend sending it back for a repair
Hi, we’ve had another one of these units fail on us. As the saying goes, once is never, twice is always. When we’re connected at 9600 baud and send F6 it responds with 86 25 80, not the expected 00 25 80. We can certainly send this unit back for repair as well, but it is very concerning that something is causing a valid 9600 baud rate to change to something invalid. Is there any way we could be accidentally sending bytes to do this while the config mode jumper is not set?
will it be possible to share the steps to reproduce the issue ?
looks like the very first byte location is getting overwritten.
As far as I can tell, the issue is arising during the course of regular operation of our device. The relay board is connected to a routing pcb which connects to banks of solenoid valves. The SN65HVD12D is connected to a FTDI USB-COM485-PLUS4 and is controlled by software we’ve used previously to control another of your relay boards using a RS232 adapter. There are arduinos on the serial hub’s other ports, but I don’t know how that could be affecting this. The whole system is powered by an ADP-66CR-BE wall adapter. The jumpers for 1,2,3 and BR are in place, is it possible for that byte to get overwritten if the C jumper is off?
In the firmware, there are ONLY two ways for the baud rate to be overwritten:
I’ve observed some unusual behavior in noisy environments. Are you providing power to the solenoids from the same power supply as the board?"
Also did you try factory reset ?
We are, but there are caps on the routing board to filter noise from the solenoids.
Not on this unit yet. I’ve manually set the baudrates back to their normal values. On the other unit where this was happening, the behavior did reoccur after a factory reset.
There are few caps on the main board and the rs485 board.
I will not recommend using same power to power the board and solenoid. if you are doing it, use induction suppression cap
Induction Suppression Capacitors - NCD.io.
We’re currently using induction suppresion caps. We will try out adding protection to the relay board supply line.
A quick update. We added more suppression caps to our system. With the original comms module, this did not change the result; it would forget one or more bytes of its comm rate after a power cycle, even if the solenoids were disconnected from the system altogether. So whatever has happened seems to persist beyond inductive noise.
We then changed to a new RS485 communication module. We first tried running it on a system with extra caps. We ran the proXR QC tests included in NCD Base, where it clicks through all 16 relays sequentially for a period of several hours. We were unable to reproduce the issues, even after running the test program overnight. We then reverted to the original configuration, without the added caps, and ran the new communication module through the proXR QC tests. Once again we could not reproduce the issues.
So what is it about some of these modules that makes them more susceptible to this failure than others? What does NCD QC look like for these parts? Having to maintain a supply of them at our office and RMAing as needed sounds like a headache but at present it seems like the path forward.
we will run some tests here with similar setup to yours and share our finding.