Modbus data to iDigi

Digi Remote Manager Device Manager
41

Thanks! I will start testing later today and post results.

Any suggestions on how to write back to a register?

42

Hi Lynn,

Hit a snag with the new firmware. Can you confirm that you are testing with the latest POST and DIA? I tried loading the new firmware and uploaded a DIA configuration that is known to work (in a modbus only configuration). I did not change any end points, etc as I wanted to start off with a working configuration and then start making changes as you prescribed.

Here are the results from the System Information section after the new firmware:

Firmware Version: 2.9.0.9 (Version 82001536_F2_SA1 01/23/2010)
Boot Version: 1.1.3 (release_82001531_A)
POST Version: 1.1.3 (release_82001537_F)
Product VPD Version: release_82001747_A
Product ID: 0x0074
Hardware Strapping: 0x0043

And then, here is the telnet session log:

=============================================

#> set trace state=on mask=ia:*
#> python dia.py

Determining platform type…Digi Python environment found.

Attempting to read “dia.pyr” in “WEB/python/dia.zip”…
iDigi Device Integration Application Version 1.2.19
Using settings file: dia.pyr
Core: initial garbage collection of 0 objects.
Core: post-settings garbage collection of 10 objects.
Starting Scheduler…
Starting Channel Manager…
Starting Device Driver Manager…
turning all debug output OFF
XBeeDeviceManager(xbee_device_manager): retrieving node list
Starting Presentation Manager…
MBusUdpPoller(MBUS): UDP connection to peer(‘127.0.0.1’, 502)
100734:ia:DEBG:MBRTU: Cannot estimate Req len for func 8 (0x08)
100734:ia:WARN:mbrtu:m00(527) checksum error
100734:ia:DEBG: 00 08 00 00 00 06 01 03 0F 3C 00 64
Web2 (web0): using web page dia.html
… using digiweb
Starting Services Manager…
Core services started.

And here is the only device that was configured in the YML:

MODBUS Interface via wireless

  • name: MBUS
    driver: devices.mbus_udp_device:MBusUDPDevice
    settings:
    poll_rate_sec: 60
    udp_port: 502
    round: 3
    poll_list:
    - poll: EM6433
    pollinfo: { ‘uid’:1, ‘fnc’:3, ‘ofs’:3900, ‘cnt’:100 }
    channels:
    - parse: { ‘nam’:‘APP_PWR_AVG’, ‘ofs’:00, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘ACT_PWR_AVG’, ‘ofs’:02, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘REA_PWR’, ‘ofs’:04, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘AVG_PF’, ‘ofs’:06, ‘frm’:‘[f’, ‘unt’:‘PF’ }
    - parse: { ‘nam’:‘LL_VOLT’, ‘ofs’:08, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘LN_VOLT’, ‘ofs’:10, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘AVG_CUR’, ‘ofs’:12, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘HZ’, ‘ofs’:14, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘R_APP_PWR_AVG’, ‘ofs’:16, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘R_ACT_PWR_AVG’, ‘ofs’:18, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘R_REA_PWR’, ‘ofs’:20, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘R_AVG_PF’, ‘ofs’:22, ‘frm’:‘[f’, ‘unt’:‘PF’ }
    - parse: { ‘nam’:‘R_LL_VOLT’, ‘ofs’:24, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘R_LN_VOLT’, ‘ofs’:26, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘R_AVG_CUR’, ‘ofs’:28, ‘frm’:‘[f’, ‘unt’:‘A’ }
    - parse: { ‘nam’:‘Y_APP_PWR_AVG’, ‘ofs’:30, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘Y_ACT_PWR_AVG’, ‘ofs’:32, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘Y_REA_PWR’, ‘ofs’:34, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘Y_AVG_PF’, ‘ofs’:36, ‘frm’:‘[f’, ‘unt’:‘PF’ }
    - parse: { ‘nam’:‘Y_LL_VOLT’, ‘ofs’:38, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘Y_LN_VOLT’, ‘ofs’:40, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘Y_AVG_CUR’, ‘ofs’:42, ‘frm’:‘[f’, ‘unt’:‘A’ }
    - parse: { ‘nam’:‘B_APP_PWR_AVG’, ‘ofs’:44, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘B_ACT_PWR_AVG’, ‘ofs’:46, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘B_REA_PWR’, ‘ofs’:48, ‘frm’:‘[f’, ‘unt’:‘W’ }
    - parse: { ‘nam’:‘B_AVG_PF’, ‘ofs’:50, ‘frm’:‘[f’, ‘unt’:‘PF’ }
    - parse: { ‘nam’:‘B_LL_VOLT’, ‘ofs’:52, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘B_LN_VOLT’, ‘ofs’:54, ‘frm’:‘[f’, ‘unt’:‘V’ }
    - parse: { ‘nam’:‘B_AVG_CUR’, ‘ofs’:56, ‘frm’:‘[f’, ‘unt’:‘A’ }
    - parse: { ‘nam’:‘WHOURS’,‘ofs’:60,‘frm’:‘[f’,‘unt’:‘Wh’ }
    - parse: { ‘nam’:‘MAXDEM’,‘ofs’:92,‘frm’:‘]L’,‘unt’:‘Secs’ }
    - parse: { ‘nam’:‘RUNSECS’,‘ofs’:94,‘frm’:‘]L’,‘unt’:‘Secs’ }
    - parse: { ‘nam’:‘PWRINTS’,‘ofs’:98,‘frm’:‘]L’,‘unt’:‘Ints’ }
    ==============================================

Note the checksum error during startup.
Let me know if I missed a step along the way.

43

Any suggestions on how to write back to a register?

By end of the week I will post my “Dia Modbus Addon” to the Wiki . It is a client/server ZIP which overlays on the 1.2.19 Dia, adding:

  • Modbus export FROM DIA (AIO, DIO, Sensor and Massa M3 only). Each device looks like a Modbus/TCP slave based on Unit Id, and there is an auto-enum function.
  • Modbus import TO Dia (what you’ve already seen). It does support writing via function 5 & 6 (maybe 15/16 by then). Writing is more complex because Dia is atomic-channel oriented, not block oriented.
44

:Checksum errors:

I’d assume those are more related to maundane things like time-outs or serial wiring. There are few dependencies between the old Modbus-import to Dia.

  1. make sure your Modbus slave timeouts are 5 seconds or more - oddly, my 802.15.4 tests show it seems more laggy than ZigBee despite the fact that 802.15.4 is very deterministic compared to ZigBee (which has route discovery & other things adding delay-holes).

  2. make sure your Modbus character timeouts are 0.5 sec (500 msec) - def of 50 msec is too fast.

  3. always do first tests on 25 words or less - you are pulling a response that is fragmenting (85 bytes), so arrives as 2 chunks. This will cause mixed fail or success if ‘char timeout’ is too fast, as that is the inter-frag delay.

  4. Take a look at:
    http://www.digi.com/wiki/developer/index.php/Modbus_ZB_Fragmentation_Support
    This does NOT help defreg the XBee 232 -> X4, but does eliminate frag gaps in the X4 to XBee 232 direction.

I am running std CPX4:
#> disp version

Component Part-Number Release-Tag
BOOT 82001531 release_82001531_A
POST 82001537 release_82001537_E (V1.1.3)
Stored EOS 82001536 82001536_F2_SA1 (V2.9.0.9)
Running EOS 82001536 82001536_F2_SA1 (V2.9.0.9)

45

I tried the firmware on another CX4 with older POST and DIA 1.1.15 and the same device settings and it works.

Here is the System Information:

============================================

Firmware Version: 2.9.0.9 (Version 82001536_F2_SA1 01/23/2010)
Boot Version: 1.1.3 (release_82001975_A)
POST Version: 1.1.3 (release_82001753_C)
Product VPD Version: release_82002010_A
Product ID: 0x0085
Hardware Strapping: 0x0043

===============================================
And the Telnet log (Have not tried the E9 endpoint, but I am sure it will work based on your testing)

#> set trace state=on mask=ia:*
#> python dia.py

Determining platform type…Digi Python environment found.

iDigi Device Integration Application Version 1.1.15
Using settings file: dia.yml
Core: initial garbage collection of 0 objects.
Attempting to read “dia.yml” in “WEB/python/dia.zip”…
Core: post-settings garbage collection of 25 objects.
Starting Channel Manager…
Starting Device Driver Manager…
turning all debug output OFF
Starting Presentation Manager…
MBusUdpPoller(MBUS): UDP connection to peer(‘127.0.0.1’, 502)
165051:ia:INFO:mbtcp:m00 recv req 120
165051:ia:DEBG: 00 08 00 00 00 06 01 03 0F 3C 00 64
165051:ia:DEBG:rte[0]: return[2]
165059:ia:DEBG:mbrtu:p01 Zigbee slave connect 00:13:a2:00:40:48:a7:ac!
165059:ia:INFO:Binding on XBee end-point 232 (0xE8)
165062:ia:INFO:mbrtu:p01 send req 120
165062:ia:DEBG: 01 03 0F 3C 00 64 87 39
167558:ia:WARN:mbtcp:m00 message timeout error
167559:ia:INFO:mbtcp:m00 send resp 120
167559:ia:DEBG: 00 08 00 00 00 03 01 B9 0B
167583:ia:WARN:mbrtu:p01 slave timeout error
MbPdu.rsp_parse() Exception Response = 0xB9 0B
Web2 (web0): using web page dia.html
… using digiweb
Core services started.
GarbageCollector: collected 0 objects.
170777:ia:INFO:mbtcp:m00 recv req 121
170777:ia:DEBG: 00 09 00 00 00 06 07 03 00 00 00 28
170778:ia:DEBG:rte[0]: return[80]
170779:ia:INFO:mbrtu:p01 send req 121
170779:ia:DEBG: 07 03 00 00 00 28 45 B2
170946:ia:INFO:Auto-bump ZB TX MTU from 50 to 84
170946:ia:DEBG:MBRTU: Estimated Rsp length is 85
170962:ia:INFO:mbrtu:p01 recv resp 121
170962:ia:DEBG: 07 03 50 00 00 00 02 00 00 00 00 00 00 00 00 00
170962:ia:DEBG: 00 00 00 00 00 00 01 00 42 00 3E 00 42 00 3E 00
170962:ia:DEBG: 3E 00 EE 00 3E 00 00 00 06 00 4D 00 15 00 07 00
170962:ia:DEBG: 00 00 00 00 09 00 01 00 00 00 64 00 01 00 5A 00
170963:ia:DEBG: 1E 00 01 00 02 00 00 00 00 00 05 00 02 00 02 00
170963:ia:DEBG: 02 00 01 FE 58
170963:ia:INFO:mbrtu:p01 last message, 183 msec to complete
170963:ia:INFO:mbrtu:p01 start rsp min:166 avg:166 max:166 msec
170963:ia:INFO:mbrtu:p01 full rsp min:183 avg:183 max:183 msec
170966:ia:INFO:mbtcp:m00 last message, 188 msec to complete
170966:ia:INFO:mbtcp:m00 send resp 121
170966:ia:DEBG: 00 09 00 00 00 53 07 03 50 00 00 00 02 00 00 00
170966:ia:DEBG: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 42 00
170967:ia:DEBG: 3E 00 42 00 3E 00 3E 00 EE 00 3E 00 00 00 06 00
170967:ia:DEBG: 4D 00 15 00 07 00 00 00 00 00 09 00 01 00 00 00

46

Hi Lynn,

I have been using the “CPX4_82001536_F2” firmware for a couple of months now and it is working perfectly. Has this code made it into the main firmware? I tried loading the latest firmware and this logic (to allow me to specify a non-“e8” end point) does not appear to be included. When do you think it will be added to the latest firmware so I can stay current?

Regards,
Andy

47

Hi Lynn,
Just checking in. I looked for the addition to the WIKI but did not see anything new. Am I not looking in the right place?

48

Send me a direct email - lynnl at digi. I have a ZIP I can offer, but am not ready to upload publicly.

49

Hi Lynn,

Just checking in. I sent you my email address to your direct email. If you did not receive it, please let me know.

Regards,
Andy

50

Actually, I did receive and I did reply back on the 9th - I wonder if the .PY in the ZIP was being filtered by some virus tool, after all it is viewed as executable code by most security tools.

I’ll send it again (plus a text/message only email) - see if that gets through.

  • Lynn
51

What exactly is the issue? Does 8200136_F2 work or not? Since F2 is an actual full release I would not expect an F3 or G to ‘regress’ to not work.

Which firmware is NOT working as desired?

52

I went back and carefully retraced my steps and the latest version 82001536_F3 03/16/2010 works correctly.

It includes the ability to run both Modbus and Digi devices side by side if I change the DE to ‘0xe9’ on the RS485 Adaptor.

Somehow I thought that logic had been left behind due to an error in my configuration. Sorry about the mistake.

53

Hi Lynn,

I am using your code published at http://www.digi.com/wiki/developer/index.php/Modbus_Dia_Code_Add-On and I have some questions regarding the use of mbus_udp_device.py DIA device. I am only using it as a bridge to Digi IA module built-in into ConnectPort X4. I only need to monitor some values from DIA with Modbus and optionally write some registers to end-devices like sensors (for calibration means, to be specific). Finally, a web interface will be made as another DIA module for the end-user to view all the monitored sensor values as well as be able to calibrate them.

I have succesfully read holding-registers (modbus func nr.3), but I could only write one holding-register (modbus func nr.6) patching the current software. I would like to know if I am doing things well or not, and this “patch” is really not required. In addition, I think that modbus func nr.16 is really not fully implemented as it seems at first sight in that mbus_udp_device.py module, as only the data from self.parse_list[0] (the first item in array) is used… (!?).

As I will go deep into technical details (Python code), should I continue here? start a new thread? private mail? wiki comments on the topic?

For instance, I would describe the short patch I had to do at MBusPoll.pre_process method to allow a channel to be write. Also, I would like to contribute a device XML file compatible with DigiESP YML editor to show “nicely” in the graphic editor as a “Modbus IA integration device” (I do not know if this already exists in some wiki page, I created one myself from scratch).

Thanks for your comments. Best regards