1) The UDCs are Modbus slaves only.
2) Prosoft is A-B's partner for Modbus modules for a Modbus master in a SLC rack.
3) I suspect that RSView 32 has a native Modbus driver where RSView is the Modbus master; most HMI products in that competitive category have this capability.
4) The current version of the ethernet Modbus firmware ROM in the 1/4 DIN UDC's 2500 is 2.14.
Each version has contributed serious bug fixes. If you work with an earlier version, you'll probably be re-discovering the bugs all over again. The firmware version is not the version available in the display under Read Status > XXXX. The Modbus firmware version is printed on the paper label on the PROM on the ethernet card.
5) Pay NO attention to any of the information (registers, addresses, function codes) given in the UDC Product
Manuals, section 9, Modbus RTU function codes. Those function codes are for undocumented functions 20
and 21 (decimal). This information is totally useless, disorienting and confusing.
Honeywell publishes a manual, document # 51-52-25-66, called the Modbus® RTU Serial Communications User Manual, which has correct information.
6) A UDC's IP address cannot be configured from the UDC keypad. PIE software is needed to configure the IP address.
7) My experience shows that UDC's choke when polled too quickly. Use a minimum of 1 second polling rates.
8) There are separate integer registers and separate floating point registers in the UDCs, so that you can avoid data format handling by picking the appropriate register in the UDC.
The two common floating point formats (big and little endian) are FP B and FPLB. I have never seen the other two (FPBB, FP L) used anywhere. If you can eliminate 2 out of 4, it makes figuring out which FP/real format to use a lot easier. (Honeywell offers all 4).
9) There are limitations to the number of values that can be read or written in a single command. The limitations are printed somewhere near the beginning of the 51-52-25-66 manual in a table. If I recall properly, most writes are limited to one value per write command. I'd do extensive testing to confirm that a UDC could take more than one value written in a single command.
Limit the number write functions of repeated data, because the internal flash memory gets overwritten every time a change is made (so that in power up after power down situation, the last known working variables are available. The flash memory has some limitation as to the number of writes it can handle.
So to change a fixed setpoint, write it once or twice, but do not write it once every 3 seconds on a continuous
basis.
Reads have no impact on the flash at all.
