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
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:
the IAP is sending a request & the slave isn’t answering
the IAP sends request, slave answers, and IAP drops response as an error.
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.