Modbus TCP 32 bit value

HI, I'm reading values from an SBC SAIA PLC ( PCD2.M5540 model). My problem is that some values are 32 bit, while modbus return 16 bit values, of course. Registers are consecutive, so I cannot read for example 9008 and 9009 since they store 2 different information.
To make it clearer I attach the PLC watch window. As you can see R9009 is a 32 bit value, but I can't require R9009 and R9010 via modbus since in R9010 register there is a different information. AS well as in R9008. Speaking with SAIA technical support, they explain me that their PLC registers are natively 32 bit, so in order to read them I need a 32bit modbus client. I cannot find anything like this, neither I can use standard modbus, since the buffer I get back is a 16 bit for each register. So 16bit for R9008, 16bit for R9009, 16 bit for R9010. What I can do?


First, I recommend trying to confirm what SAIA technical support told you is actually true (in my experience, communication is frequently a less important feature of devices and sometimes manufacturers' technical support staff may not actually know how their product communicates - there may only be a single person at the company that knows).

The only Modbus documentation I could find stated it is for the Saia PCD and PG5, so I'm not sure whether or not it applies to the PCD2.M5 specifically, but the manual seems to contradict what you were told.

That manual states that the user is able to configure mappings of "Modbus Media" (which I interpret to mean Modbus register, such as 40001, 40002, etc.) on "Saia PCD Media" (which I take to mean what they call registers, such as R9008, R9009, R9010, etc.). Additionally, in the schema diagram shown on page 3-4, it seems to imply that the Saia PCD Media "R" is composed of a MSW0 (Most-Significant Word) and LSW0 (Least-Significant Word) and that this maps to the Modbus Data HR0 (Holding Register 0 and HR1 (Holding Register 1). Therefore, I believe that in the example you've given, R9008, R9009, and R9010 are not Modbus register addresses, they are Saia PCD Media address. There should be two corresponding Modbus addresses for each of the aforementioned addresses. For example, R9008 could map to Modbus registers HR72064 and HR72065 (this is purely a guess based on the fact that R maps to HR0 and HR1 and R+1 maps to HR2 and HR3 in the schema diagram). Also, the default mapping shown on page 3-5 seems to indicate that there are different Modbus address ranges for 16-bit signed, 32-bit, and 32-bit floating point data.

So essentially, it seems it may just come down to the scope in which you are referring to the data - whether using the Saia PCD Media data addressing scheme of R, R+1, R+2, etc. or using Modbus addressing of HR0, HR1, HR2, etc.

If, after investigation, you find that the PCD2.M5 does in fact require a Modbus client that supports requesting a single register, expecting 32-bits of data back instead of 16, you can use one of ICC's gateways to perform the conversion into standard Modbus (you would uncheck the "Word-Size Register" and "Word Count" options under the 32-Bit Options when configuring the gateway). The proper gateway depends on whether you are using Modbus/TCP or Modbus RTU. For Modbus/TCP, you would use the ETH-1000 ( and for Modbus RTU you would use the Mirius (
Thanks so much for the support. Yes, thanks to the document you shared I tried to get more information from their technical support and it is as exactly as you said. So now I have to understand how the two areas are linked each other. I even have the source code, but I'm not expert on this PLC, so at this point I have to find someone that knows it and that can help me to find the correct register to read. Thanks so much
Undoubtedly SAIA has had this question before. I understand that putting 32 bits in a 16 bits Modbus register is impossible, so very likely they have a solution. I have once seen a device which, when you wanted to read 1 register, just sent you the full 32 bits back. But a normal Modbus master would then say "Hmmm I requested one register / 2 bytes but got 4 back, so error, so ignore reply". A more stupid master would just give you the 4 bytes. Impossible to say whether a master matches the response with the request, so the only option is just to try.