We have 3 PROXR 32 channel relay cards with RS485 interfaces (no UXP). I will refer to them as 1, 2 and 3. All cards have identical jumper settings in accordance with the documentation. We are using NCD Base Station.
Card 1: First powered up ok and RS485 comms initially seemed ok as we could look at the configuration. However, on “Save”, it seemed to lock up and then no further comms with card 1 was possible.
Card 2: First powered up and able to successfully set the E3C number and change the card’s identity name. Power down/up and card works correctly. Comms OK.
Card 3: First powered up and able to successfully set the E3C number and change the card’s identity name. Power down/up and card works correctly. Comms OK.
Swapped RS485 modules between cards 1 and 2. Card 2 continued to work but card 1 still had problem. Therefore we assume card 1’s RS485 module is OK and problem is on card 1’s PCB.
Documentation refers to making connection between 3.3V and CLR to reset to factory default but 3.3V and CLR are not marked.
Tried the “Hint” in the documentation suggesting moving link between run and program and cycling power but this did not work.
I am in England and leaving for the day now. If you could let me know how I can get the card back to factory default then I can try that in the morning and get back to you when you come in.
The Factory Reset is for the RS-485 module. Bhaskar will have to supply a pinout for that procedure.
Alright lets run through a quick diagnostic to see if its a device targeting issue.
Firstly have you only tried this in Base Station? No consoles or other software?
Disconnect everything from the chain until its just device 1 and the USB to RS-485 adapter.
What I would suggest doing is opening a console (I suggest Putty or Comm Operator). Open a serial port to the USB to RS-485 adapter, send the command (in bytes, make sure they aren’t being sent as ASCII) “254 252 1” - This will target board 1. The board should respond to this command with a 1 if it is at that location.
Close the serial port. Try Base Station again. Once the E3C device number is set, the board will need to be individually targeted via software.
Its been a while since I did this so let me know if it works and what, if any, error messages you’re getting out of Base Station.
The problem is that Base Station is not even finding the card. The baud rate scan starts and runs through to the end without finding anything. Therefore we can’t receive anything from the card with Base Station.
If an E3C device is targeted and there isn’t a device on the com line that has the targeted E3C number, non of the boards will respond.
This mostly sounds like either the baud rate was accidentally changed (probably not), or an E3C device was set and not targeted so the board is not responding.
It’s unusual in the extreme for a board to go bad shortly after a configuration unless it was powered up while sitting on a conductive material such as the ESD bag it comes wrapped in.
Hi Jacob,
I’m working with Guy on this project. I followed your instrucions from yesterday but without any luck.
I connected just the board in question, powered it up, opened a serial console and sent 254 252 1 and received no response. I also tried 254 252 0, again with no response.
I then power cycled it and tried 254 247 2 and still got no response. I also tried 254 33.
Then I tried the same procedure at a selection of other baud rates, still without any luck.
As a sanity check, I tried the same things with one of the working boards and got the expected results.
The boards were securely mounted before being powered up and have only been used in an ESD protected environment.
Is there anything esle that you can suggest we try?
Can you double check the module’s connection to the board? (no pins are overhanging)
Are the lights on the board flashing at all when attempts are made to communicate to it?
Do any LEDs light up when power is applied?
What is the position of the PGM/RUN jumper on the board/PCB? If it is in PGM mode try switching it over to RUN mode.
Back in console try sending just the byte 246. As per https://ncd.io/rs-485-network-quick-start-guide/ sending 246 should return the current baud rate of the module. I’m curious if there may be a mismatch between the module and the board.
Thanks for your suggestions. The wiring is correct, I’m only connecting one board at a time for simplicity. I have all 3 of the jumpers fitted, is that correct? I also tried with just jumper 3 fitted, with no change.
The RS-485 module is correctly mounted on the board.
When power is applied, the leftmost LED in three of the LED blocks lights up.
When data is sent to the board, the leftmost LED in the top left LED block flashes.
The PGM/RUN jumper is in the Run position. I moved it to the PGM position and power cycled the board without any success.
I tried sending just 246 but got no response. However I tried this with both working boards and got no response from them either.
I found out how to factory reset the RS485 module and proceeded as follows:
Fitted the C jumper
Powered up
From the console read 80 71 77 which in ascii is PGM
Connected Clr to 3.3V for 1 second
Read 170 187 via the console
Powered down.
Removed the C jumper
Powered up.
I then tried sending 246 with no response, then 254 33 with no response, the 254 247 2, again with no response.
After this, I swapped the RS485 module with that from board 2. I could still communicate with board 2 as before and there was still no communication with board 1.
From this, it would seem that the RS485 module is working correctly, despite the lack of response to the 246 command. Unless I’m missing something?
No, this all looks correct and you’ve followed the steps to the letter. The flashing lights on communication means the board is getting something, but can’t understand it for one reason or another (usually a baud rate mismatch).
The last step before I would have to recommend an RMA is to try altering the Baud rates manually.
In particular I’m wondering if somehow the Baud Rate of the RS-485 board somehow changed to the baud rate of 115.2k while the RS-485 module is translating at 57.6k.
So try the command F3, 01, C2, 00 (byte/hex values). Power cycle the board and module, (disconnect the board, disconnect the adapter).
You could try this with all of the USART baud rates listed, but if there’s still no response I’d have to recommend an RMA as there’s not much further we can go without a USB communication module on your end. RMA: https://ncd.io/contact-us/product-returns/ send the board with the RS-485 module and we’ll have an engineer figure out the issue.
That was a good guess, when I set the USART to 115200, I was able to communicate with the relay board.
Could you tell what I need to send to the relay board to change it’s baud rate back to 57600 please?
Awesome, there was only about 4 or 5 things that could be causing it. Determining the right one was the trick. I should probably see about adding these steps as a troubleshooting guide now that all of them are in one place anyway.
115.2k isn’t extremely reliable on RS-485 so we’ll just have to try to make this works. Ideally you would have a USB module to change this setting.
So once its communicating you’ll want to load up Base Station and connect to the device. Once connected there should be a button for Device Configuration in the top left.
Click on that and a window will come up that contains the options for baud rate. Make sure 57.6k is selected and RS-485 is the interface.
(You will lose communication temporarily after this step) Hit store configuration in the lower right side of that window.
Close Base Station and power cycle the board.
Again open a direct terminal/console to the board and send the command: F3, 00, E1, 00
This will set the USART of the RS-485 module to 57.6k to match the board’s baud rate.
Marvellous, that’s completely working now. Many thanks for your help.
Good idea to use this as a troubleshooting guide, if you do it might be worth including the fact that on the RS-485 module, the C jumper must be fitted, and the power cycled, to set the baud rate and also to get a response to the 246 and 245 commands.