This is a modbus related problem with python. I hope I’m in the right thread here.
Summary:
Having this problem whenever I send a request of Reading Holding Registers (function code 3) word count >56; I get a mbtcp message timeout error from the IA Engine. When the test is repeated by Reading Holding Registers of word count <56, IA Engine was able to process. Is there a limit to the number of holding registers the IA Engine can process?
Detail info
I’m running a simulation of modbus protocol message encapsulated in tcp or zigbee. I’m testing this to understand the limits of encapsulation methods powered by the ConnectPort X-Series. My layout of the simulation looks like below:
Initially the modbus portion was running on Labview’s Virtual Instruments, but another day for that.
So after the above setup, I ran the test of mbus function code 3 to query for varying word counts. (varying numbers of holding registers). It was able to give a response if my mbus query request to read holding registers < 56.
56 Holding Registers is apparently the limit the IA Engine can process. On the query of 57 Holding Registers onwards, the IA Engine begins to reply on the tcp line that mbus tcp has occurred a timeout.
Troubleshooted results:
Sent raw ZB packets of equivalent length (57 bytes) or more to the CPX4 in a single PDU (packet). I achieved no error until I reach the PDU payload limit of 255 bytes.
sniff TCP packets between interface of MODSCAN32 (Host Computer A) ------- IA Engine (CPX4) . Error points to the IA Engine settings.
set trace of all ZB and IA exchanges between IA Engine (CPX4) ---------- MBUS_ETHRNET_BRIDGE (CPX2) . Again error points to the IA Engine settings.
[Attachment provided with results of test 2 and test 3]
The strangest thing is, the attachment CPX2_MBUS_ETHERNET_BRIDGE.log entry displays that the xbee module successfully sent out a ZB reply to the CPX4 displaying the results of the modbus query. BUT the CPX4_IA_Engine entry did not show a successful receive trace of the ZB packet. Bizzare-ness!?
I’ve also tried changing configuration parameters and response/character timeout but it didn’t help. I’ve tried changing the response timeout in the IA Engine = 25000 msec & Character timeout = 7000 msec away from the default settings; still it didn’t help.
I’ve come to a point hitting a stone wall not knowing how to rectify it. Unless… is there a holding register’s limit the IA Engine can process?
The engine can handle more registers than Modbus allows - 125 registers is always tested. Plus if that were the case, you’d see the first 1 or 2 fragments of XBEE RECV returned. Nothing is being submitted to the X4 from it’s XBee. So the IA engine obviously sees nothing either.
What firmware do you have on the 2 units? make sure they match & are relatively new. I assume this is a ZB defrag compatibility issue. For example, normal ZB packs are limited to about 80 bytes of payload. When you code submits an API frame with more than that much data attached, NEWER XBee firmware will attempt to use a special fragmentation header.
If the Xbee firmware in the X4 either doesn’t asupport fragmentation, or does it differently (or there is a bug), then the X4’s XBee will drop the series of packets.
It might also be possible the X4’s XBee is too busy to or lacks buffer space to HOLD all incoming packets until the full message is received. I don’t really know how that portion of the XBee works.
So:
make sure both Xbee have the same firmware
worst case, on the X2 manually fragment your Modbus response, so send as 2 or 3 fragments. The X4 IA engine will correctly reassembly them without the XBee in the X4 needing to handle the defrag itself.
hey there lynnl, always appreciate your thoughts
I hope to get the feedback from the community as well for those who might have had their hands on this before.
What firmware do you have on the 2 units? make sure they match & are relatively new.
The CPX4 is running on Hardware Version 0x1e42 , and Firmware Version 0x2170
The CPX2 is running on Hardware Version 0x1941 , and Firmware Version 0x2370
Further Testing
I assume this is a ZB defrag compatibility issue. For example, normal ZB packs are limited to about 80 bytes of payload.
I’ve tested on sending a payload size of 255 bytes (i.e. PDU size of 278 bytes) from CPX2 -> CPX4 and was able to trace successful results of complete transfer. Attached is the log entries from the sender (CPX2) and receiver (CPX4). The attached log files are my latest post entry to my test conducted to prove that the Radio has no problem reporting of successful transfer even with fragmentation (look at Frame ID 0x8B). But in reference to the question of my first post, if this test was able to prove a successful transfer of payload size 255 bytes and that CPX2 was able to report a successful transfer; In Comparison With
The strangest thing is, the attachment CPX2_MBUS_ETHERNET_BRIDGE.log entry displays that the xbee module successfully sent out a ZB reply to the CPX4 displaying the results of the modbus query. BUT the CPX4_IA_Engine entry did not show a successful receive trace of the ZB packet. Bizzare-ness!?
…then why didn’t the transfer of 57 bytes of Modbus payload appear on the trace results of the CPX4 for the above entry?
I couldn’t pin point the fault to a specific area, hence I can’t figure out any further. Right now, the fault points toward The Radio’s Firmware, The IA Engine, or The CPX4 Processing Capabilities. Even so, I’m not sure how to proceed any further if it falls into these areas @_@
worst case, on the X2 manually fragment your Modbus response, so send as 2 or 3 fragments. The X4 IA engine will correctly reassembly them without the XBee in the X4 needing to handle the defrag itself.
Will be avoiding this until absolutely necessary for now.
You gave me an idea on trying it out for the same hardware version for both sides. Going to do that next.
The problem isn’t the IA engine, but Digi’s Python socket module. In other words, the IA engine can send a 122 register write via ZigBee because the underlying OS and XBee API allows frames larger than a single ZB packet.
However, the Python socket() code originally implemented a semi-smart (semi-dumb) attempt to protect the XBee from API frames which are too large for a single Zb packet. This made sense back before Xbee supported the ZB fragmentation headers. But once the Xbee moved to ZB-PRO & did handle larger packets, there was a considerable time-lag before Digi removed these restrictions.
Older sendto on the X2 might be just TRUNCATING your large response in a way it feels is correct.
What version of firmware is running on your X2?
I know this was fixed on the X4 (because I just went and did a test of sending 200 bytes on an X4 with J firmware from last month). However, I don’t know WHEN it was fixed and I see the newest X2 firmware on the support site is F3 from feb 2010 - a year+ old. I attached a test build of a newer firmware for the CPX2 dated April 2011. Don’t know when it will release, but this shoudl have the same sendto() function as the released X4 “J”.
