Closed srebling closed 5 years ago
Sorry this took so long as I obviously missed the email notification and did not see this issue until I went to reply to another one.
An extended path specification for this access should work just fine, but you would need to write it a little differently. I would suggest trying hard-coding as follows: routing: [0x08, 0x00, 0x01, 0x00, 0x12, 0x0b, 0x31, 0x30, 0x2e, 0x34, 0x34, 0x2e, 0x39, 0x2e, 0x31, 0x34, 0x39, 0x00]
0x08, 0x00 = 8 words in path not including this length specifier 0x01 = backplane of ENBT you are using to access (first ENBT) 0x00 = slot 0 (if your second ENBT really is in slot 0, otherwise change) 0x12 = port 2 of second ENBT with extended address bit set 0x0b = 11 bytes in extended address 0x31, 0x30 = 10 0x2e = . 0x34, 0x34 = 44 0x2e = . 0x39 = 9 0x2e = . 0x31, 0x34, 0x39 = 149 0x00 = required to send an integer number of words I think
Please let me know if it works or does not work so we can either find what it takes to make it work or close the issue. Unfortunately we don't have access to a 1756 rack with two ENBT modules in it.
If anyone can comment on if they have tried nodePCCC with a remote connection like this, it would be appreciated. I have not yet had a chance to establish a remote connection this way.
Does the project support an IP address in the connection path?
routing: [0x01,0x00,0x02,'10.44.9.149',0x01,0x00]
0x01 - backplane (local rack) 0x00 - 1756-ENBT slot 0 (local) 0x02 - ethernet module port 10.44.9.149 - to 1756-ENBT remote IP 0x01 - backplane (remote) 0x00 - 1756-Lxx slot 0 (remote)