Home/Support/Support Forum/Digi One IAP Haz not transmitting data at certain Modbus Addresses
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Digi One IAP Haz not transmitting data at certain Modbus Addresses

0 votes
I'm attempting to use a Digi as a Modbus to ModbusTCP gateway and have hit a bit of a snag. When requesting sending data requests to certain Modbus addresses, the module refuses to transmit serial data to the device. If I request data at block address 40001, the signal is transmitted through and data is returned. However a request at 40616 returns nothing. I've connected a PC to the serial port on the Digi to observe serial communications and found that serial commands are sent when the 40001 block is queried but not when 40616 is. I do not know exactly where communication breaks down, but requests to block 40381 return successfully. Has anyone else had a similar problem, and if a resolution has been found, what was it?

The Digi module has what I believe is the latest firmware on it, but I am going to post the details about that to cover bases

Model:Digi One IAP Haz
Firmware Version:Version 82000770_W1 02/16/2016
asked May 18, 2016 in Modbus and Industrial Automation by sirus New to the Community (0 points)

Please log in or register to answer this question.

2 Answers

0 votes
Perhaps a trace might provide some clues:

http://knowledge.digi.com/articles/Knowledge_Base_Article/How-to-Run-An-Industrial-Automation-Trace-on-A-Digi-Device-or-Terminal-Server-Using-PuTTY
answered May 19, 2016 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
Do the trace, but also make sure your don't have XON/XOFF, as that can break some messages because it changes bytes. Because the code in the IAP passes the Modbus through without analysis, it's impossible it cares differently about 40001 or 40616.

As userid suggests, you need to do the ia trace because 1 of 3 things is happening here:
1) the IAP is sending a request & the slave isn't answering
2) the IAP sends request, slave answers, and IAP drops response as an error.
3) the IAP sends request, but slave answers too slowly and IAP has already given up.

For #3, some slave devices use multiple PCB talking internally. For example a Flow Computer might have a main comm card, which answers "its" data in 15msec, but if you ask for a totalizer value, it uses a backplane to ask a second card, so the answer might take 780msec. So different registers cause different timing behavior. If this is true, you MIGHT see in the IA trace some form of 'unexpected' or mismatch error show.
answered Jul 7, 2016 by Coralyn Seasoned Professional (150 points)
...