RS485 Network with Duplicate Node

Hi,

I am stuck with RS485 network with duplicate node. I changed address of a node by mistake and now cannot talk to any node possibly due to duplicate node. I cannot turn off any node as they are sealed and connected to one power supply. How to recover from this situation please?

Is this Profibus or something else? How do you change the address? Is it by means of an engineering tool, right? Not through DIP SW/Rotary SW.

All the nodes are connected to the same power supply I understand. Can you disconnect the RS485 plug from a selected node?

Thanks for asking.

These are teledyne LEDs and I am changing address using commands from from Logix controller. No dip switches etc.

They came in package of 4 LEDs with factory default address 0 to 4 with common RS485 network cables and power cables. So not possible to disconnect individual node.

The command is as as below

Byte 1 = Node addres
Byte 2 = Command
Byte 3 = Value to be Written
Byte 4 = Checksum
Byte 5 and 6 = CRLF

Kind Regards

I would like to read the datasheet of this product. I have no ideas at this moment with the information you have provided. If I get this manual I will have a look at it and try to think some solution.

Please find link to the document.

http://www.teledynemarine.com/Lists/Downloads/LED-B-Series (Mar17).pdf

http://www.teledynemarine.com/led-b-series?ProductLineID=57

Are these lamps are already commissioned under water?



I cannot find any information on this Teledyne Bowtech Protocol. I guess you must have implemented this on your Logix program. I am sorry, I cannot suggest anything, since you do not seem able to disconnect either the power or the signal from the node you suspect has the duplicate address. I hope someone else in the forum has experience with this product. Really sorry.

I have protocol document but not sure how do I attach PDF here?

Without any knowledge of the products you are working with this is a guess but from what you are describing you will need to somehow sever the communications to one of the two devices with the duplicate address. They are both receiving a command from the master that they are both trying to respond to. Two responses at the same time from what the master thinks is one device is probably causing the problem and (again, my guess) the only way to clear the problem is to stop the dual response I.E. sever the communications from one of the two devices. Hopefully I'm wrong but I don't see how you are going to change the address of one of the two duplicate nodes when the only way they are identified is by the node number.

Thanks for reply.

The LEDs have some specific commands only e.g. change address and change light level, read level and read temperature etc. There is no command to reset to factory settings.

With RS485 network if we cannot remove and duplicate node physically, how can we recover from it?

whussain6 said:

I have protocol document but not sure how do I attach PDF here?

Click to expand...

look for the paper clip, then browse to select the PDF, then click upload

Master command frame consist of six character shown below:

Byte One Byte Two Byte Three Byte Four Byte Five Byte Six
Address Command Value Checksum Carriage Return Line Feed

Checksum - The checksum byte ensures that the data packet has been sent correctly. The algorithm exclusive ORs bytes one and two and then exclusive ORs the result with byte three to derive the checksum value. Carriage Return - constant character 0x0D (hex) Line Feed - constant character 0x0A (hex)



Command 0x27 //address change
Reply data1: light address
Reply data2: command (0x27)
Reply data3: value (command packet-new address)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)
Note: There is no reply and no execution if address is broadcast (0x52)


Command 0x28 //change light level command
Reply data1: light address
Reply data2: command (0x28)
Reply data3: value (same value as in command packet-level value)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)
Note: There is no reply if address is broadcast (0x52)
Command 0x29 //light description - demo
Reply data1: carriage return (0x0D)
Reply data2: Line Feed (0x0A)
Reply data3-22: "BOWTECH PRODUCTS LTD"
Reply data23: carriage return (0x0D)
Reply data24: Line Feed (0x0A)
Reply data25-44: "LED CONTROL PROTOCOL"
Reply data45: carriage return (0x0D)
Reply data46: Line Feed (0x0A)
Reply data47-57: "VERSION X.Y"
Reply data58: carriage return (0x0D)
Reply data59: Line Feed (0x0A)
Reply data60-70: "ADDRESS XXX"
Reply data71: carriage return (0x0D)
Reply data72: Line Feed (0x0A)
Reply data73-95: "TEL +44 (0) 1224 772345"
Reply data96: carriage return (0x0D)
Reply data97: Line Feed (0x0A)
Reply data98-114: "WWW.BOWTECH.CO.UK"
Reply data115:carriage return (0x0D)
Reply data116:Line Feed (0x0A)

Command 0x2A //change default light level command
Reply data1: light address
Reply data2: command (0x2A)
Reply data3: value (same value as in command packet-level value)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)

Command 0x30 // read temeprature
Reply data1: light address
Reply data2: command (0x30)
Reply data3: value (temperature in deg.)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)

Command 0x31 // read max temeprature
Reply data1: light address
Reply data2: command (0x31)
Reply data3: value (max temperature in deg.)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)

Command 0x33 // read FW version of 2 bytes
Reply data1: light address
Reply data2: command (0x33)
Reply data3: value 1(fw_major)
Reply data4: value 2(fw_minor)
Reply data5: checksum (light_address^command^value^….^data2)
Reply data6: carriage return (0x0D)
Reply data7: Line Feed (0x0A)

Command 0x34 // read light level default value
Reply data1: light address
Reply data2: command (0x34)
Reply data3: value (from eeprom)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)

Command 0x35 // read light level actual value
Reply data1: light address
Reply data2: command (0x35)
Reply data3: value (actual level value)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)


Command 0x36 // read light series (for this light in value should be ‘B’)
Reply data1: light address
Reply data2: command (0x36)
Reply data3: value (value)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)

Command 0x37 // smooth change light level command
Reply data1: light address
Reply data2: command (0x37)
Reply data3: value (same value as in command packet)
Reply data4: checksum (light_address^command^value)
Reply data5: carriage return (0x0D)
Reply data6: Line Feed (0x0A)
Note: There is no reply if address is broadcast (0x52)



Command 0x38 // read serial number
Reply data1: light address
Reply data2: command (0x38)
Reply data3: text char1
.
.
.
Reply data18: text char16
Reply data19: checksum (light_address^command^data3^…^data18)
Reply data20: carriage return (0x0D)
Reply data21: Line Feed (0x0A)

Wait a minute, the LEds are 24V only; they are not the part handling the protocol over RS-485, are they? What is actually handling the protocol?


Is some form of "factory reset" possible?

Factory reset not possible as far as I know.

There is moxa serial server between the EN2Tcard and the LEDs. I am writing to TCP port and the mode serial server is sending the command to the LEDs.

whussain6 said:

...and the mode serial server is sending the command to the LEDs.

Click to expand...

No, it's not. The LEDs in the link you mentioned do not speak RS-485. There is a black box in between the LEDs and the serial server. *That* black box, whatever it is, is what needs the factory reset.