The answer is either easy or not (I hope easy, but is untested by me). This will work for Zigbee or DigiMesh (things with end-points) but NOT 802.15.4!
The problem is that 2 threads cannot both bind to the ‘port’ (aka: end-point 232/0xE8).
However, when you configure the IA/Modbus routing table and enter a MAC address like 00:13:a2:00:40:0a:4b:eb!, it defaults to using 0xe8 - and you could also enter it as 00:13:a2:00:40:0a:4b:eb!232 to explicitly define the end-point code to use. The engine ‘assumes’ no code means 232 as 0x00 in Zigbee/Xbee has other special meaning.
So you would:
add a code other than ‘!232’ to every Xbee route. I’d use 231 or 233. If you mix these, the Modbus engine will thrash (open/close) the XBee socket and you don’t want that. A single thread manages all Modbus remotes, so give it a since end-point to use.
For EACH of your remote serial nodes, go into the Advanced Settings and change the “Source endpoint (SE)” setting to match (so 0xE7 or 0xE9). So it’s the moral equivalent of changing NOT to use TCP port 502 but 501 or 503 instead.
I would reboot/powercycle everything after this.
In theory that is all you need to do - let me know if it works
Well, the solution made sense and it almost works, but no joy.
I tried changing to end point 233 (0xe9) and kept getting timeout errors, so I started over with a working connection on 232(0xe8).
I wanted to see if it would work with the RS485 adapter Source Endpoint SE set to 0xe8. In theory this is the same configuration that works but with an explicit End Point of 232 instead of letting it default to 232 on its own.
Just checking to see if you had any luck with getting the Modbus code to use a different end point address. I have tried several ways of entering the endpoint other than 0xe8, but have not had success.
Also, do you have code I could add to the previous code that you sent me (see earlier email) to allow a Write from the Dia code to a register on a modbus slave?
Okay, next week I’ll look into this. Some ‘tweaks’ to the end-point stuff was added this fall to overcome 802.15.4 limitations. This may have broken (or ‘over-ridden’) this much older design.
I need to solve this same issue for a huge customer expecting to (as are you) mix Modbus polling with non-Modbus.
One quick check - also enable the ‘mesh’ trace info. This will show you the actual XBee message being sent out - including the end-point info. You’ll need to decode the API frame, but the existance of 0xe8 or 0xe9 should be obvious.
Thanks, this is a major issue for me as well. I will be glad to provide whatever you need, but not sure how to capture the ‘mesh’ trace information. If you can point me in the right direction, I will run a test this afternoon and post the trace results.
All I see in the trace info settings is as follows:
OK, looks like we have some useful information by turning on the mesh trace.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The following are the normal (and working) frames when the entered XBee
extended address is entered without any end point at the end (e.g., 00:13:a2:00:40:48:a7:ac!):
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
597987:xbee:SENT:
597987:xbee:DEBG: 0: 7e 00 1c 11 3d 00 13 a2 00 40 48 a7 ac b0 d9 e8 ~…=…@H…
597987:xbee:DEBG: 10: e8 00 11 c1 05 00 10 01 03 0f 3c 00 64 87 39 6e …<.d.9n
598006:xbee:DEBG:RECV:
598006:xbee:DEBG: 0: 7e 00 07 8b 3d b0 d9 00 00 00 ae ~…=…
598006:xbee:DEBG:msCompletePending: complete command 0x0 frame 0x3d
598086:xbee:DEBG:RECV:
598086:xbee:DEBG: 0: 7e 00 66 91 00 13 a2 00 40 48 a7 ac b0 d9 e8 e8 ~.f…@H…
598086:xbee:DEBG: 10: 00 11 c1 05 01 01 03 c8 00 00 00 00 77 ab 23 b8 …w.#.
598086:xbee:DEBG: 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
598086:xbee:DEBG: 30: 59 c0 24 8a 00 00 00 00 00 00 00 00 77 ab 23 b8 Y.$…w.#.
598086:xbee:DEBG: 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
598086:xbee:DEBG: 50: 77 ab 23 b8 00 00 00 00 77 ab 23 b8 00 00 00 00 w.#…w.#…
598087:xbee:DEBG: 60: 00 00 00 00 00 00 00 00 00 26
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The following are the (non-working) frames when the entered XBee
extended address is entered with ‘232’ at the end of the extended address (e.g., 00:13:a2:00:40:48:a7:ac!232):
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
370694:xbee:DEBG:SENT:
370694:xbee:DEBG: 0: 7e 00 1c 11 3a 00 13 a2 00 40 48 a7 ac b0 d9 23 ~…:…@H…#
370694:xbee:DEBG: 10: 23 00 00 00 02 00 10 01 03 0f 3c 00 64 87 39 d0 #…<.d.9.
370716:xbee:DEBG:RECV:
370716:xbee:DEBG: 0: 7e 00 07 8b 3a b0 d9 00 00 00 b1 ~…:…
370716:xbee:DEBG:msCompletePending: complete command 0x0 frame 0x3a
375696:xbee:DEBG:RECV:
375696:xbee:DEBG: 0: 7e 00 1e 91 00 13 a2 00 40 32 64 24 69 bf e8 e8 ~…@2d$i…
375696:xbee:DEBG: 10: 00 92 c1 05 01 01 08 00 0e 08 00 00 01 02 76 02 …v.
375696:xbee:DEBG: 20: 1a ba …
MbPdu.rsp_parse() Exception Response = 0xB9 0B
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Interesting that the ‘232’ gets parsed as ‘23’ for the hex end point.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
So I said Ah-Ha! Let me try entering ‘e8’ as the end point as such (00:13:a2:00:40:48:a7:ac!e8):
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1160604:xbee:DEBG:SENT:
1160604:xbee:DEBG: 0: 7e 00 1c 11 48 00 13 a2 00 40 48 a7 ac b0 d9 e8 ~…H…@H…
1160604:xbee:DEBG: 10: e8 00 00 00 00 00 10 01 03 0f 3c 00 64 87 39 3a …<.d.9:
1160623:xbee:DEBG:RECV:
1160623:xbee:DEBG: 0: 7e 00 07 8b 48 b0 d9 00 00 00 a3 ~…H…
1160623:xbee:DEBG:msCompletePending: complete command 0x0 frame 0x48
1168035:xbee:DEBG:RECV:
1168035:xbee:DEBG: 0: 7e 00 1e 91 00 13 a2 00 40 32 64 24 69 bf e8 e8 ~…@2d$i…
1168035:xbee:DEBG: 10: 00 92 c1 05 01 01 08 00 0e 08 00 00 01 02 7e 02 …~.
1168035:xbee:DEBG: 20: 1a b2 …
MbPdu.rsp_parse() Exception Response = 0xB9 0B
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
So, it looks like entering ‘e8’ as the endpoint gets parsed correctly, but the frame is missing some of the content.
So I broke down the frame and it looks like the clusterID and Profile ID are missing. I tried entering the missing information as part of the extended addres and the only thing that worked was the profileID after the endpoint (e.g. 00:13:a2:00:40:48:a7:ac!e8c105) the resulting frame now has a vaild profileID, but the cluster id is still missing. see the following:
The end-point is still 0xe8. The other ID’s are okay (this isn’t really Zigbee after all, but encap-Modbus). So 0x0000 and 0xC105 are what I’d expect.
I suspect that when they put the fix for 802.15.4, which lacks end-points, they hard-coded the 0xE8/232 for non-802.15.4 instead of using the ‘configured’ value.
I don’t think I am explaining this very well. Let me try another way.
I have a working Modbus connection to an RS485 Adaptor connected to a meter. If I enter: 00:13:a2:00:40:0a:4b:eb! as the extended address, it works all day long - no problem.
Without changing anything else other than the extended address to: 00:13:a2:00:40:0a:4b:eb!e8, I no longer get the register data coming back - see the trace I sent in the previous email. So even though it takes the e8 and plugs it into the end point byte in the frame, the frame is not successfully processed somehow. That was all I was trying to explain.
Anyway, it is probably not important. It sounds like the code is not working as you expected it to work by overriding the end point address.
Finally looked, and there are number of ‘issues’ - this code was done back when ZB wasn’t even released yet and some of the concepts where not understood.
the current code ‘might’ work if you knew that you needed to also include the cluster & profile, so “!E9@C105/0011” - but the DNS name-space used is only 32 bytes long, so you won’t be able to enter so many characters.
there is also some funky gymnastics required to src/dst end-point since the “E9” above is ‘technically’ the dst end-point, but the remote XBee needs that to be E8, so we need to treat it as ‘src’ instead.
I have a CPX4 image now which works, I need to see how to go about exposing this to others.
Also, do you have a code snippet on how to go about writing out to a register? I have a modbus thermostat that I need to be able to set various values, setpoints, deadband values, etc. It can be one register at a time as it will not be done very often.
Understood - by late Friday we should have an official CPX4 beta-build which I could offer.
To use, you’d enter the MAC as 00:13:a2:00:40:3e:15:18!E9, then in the XBee set ONLY the “DE” to 0xE9. The SE (source) in the XBee 232/485 must remain 0xE8. That was one of the issues with the old design - it would send 0xE9 as both src and dst, and the XBee 232 would not understand (despite the SE setting) that 0xE9 is now to be the serial-encap end-point.
So the CPX4 needs to send SE=0xE9 DE=0xE8, while the XBee has to respond as SE=0xE8 and DE=0xE9. Modbus is binding on the 0xE9 end-point, which permits Dia (or another Python script) to bind on 0xE8.
Here is the CPX4 F2_SA1 build, which includes the fixes/changes to move the Modbus ‘serial-encap’ away from default end-point 0xE8.
It has not yet passed through a full SA cycle, but I have run it over the weekend on 3 different CPX4H, all brigding Modbus/TCP to xbee-network to Modbus/RTU serial. One has ZB with end-point shifted to 0xE9, one with ZB on normal default end-point, and one with 802.15.4 which has NO end-points (confirms tweaking end-points didn’t break the no end-point).
To use, you’d enter the MAC as 00:13:a2:00:40:3e:15:18!E9, then in the XBee set ONLY the “DE” to 0xE9. The SE (source) in the XBee 232/485 must remain 0xE8.
