Lately I met 2 non-standard Modbus servers. I wonder if someone here had a similar experience (and I want to share it, possibly to help others).
Case 1:
A small custom-build PLC. No matter what read request it receives, it always sends all the registers (13 or 14 if I remember correctly). To support this behaviour (in combination with our variable-register-size mode), I've added "Dummy Request Mode" to our Modbus driver options.
Case 2:
A control unit by https://www.comap-control.com. It supports "Authentication" for Modbus TCP. It means that the first thing the client has to do after a TCP connection is established is to write a password (up to 16 bytes) to a specific address. Then (if the password is correct) the unit is willing to accept read/write commands. Without a password, it only returns exception codes. To support this behaviour, I've added 3 more parameters - TCP Write Password (the data), TCP Password Address (register address), and TCP Password Function (6 or 16).
While this feature can be turned off on the control unit, it seems useful to make the life of a potential attacker a bit harder

 

I've seen a lot of Modbus implementations over the last 15+ years helping customers integrate our gateway products to other equipment, but I've never come across anything like Case 1. It seems whoever built this custom PLC didn't actually implement Modbus, but rather simply implemented "test" code in order to transfer data between some other device (perhaps another device they built). I would consider this case a proprietary protocol, though similar to Modbus, it is NOT Modbus.

Case 2, however, I have seen. I believe the Honeywell SOLA controller requires a password to be sent every 10 minutes to be able to accept commands via Modbus. There was a thread on this here:
https://control.com/forums/threads/how-to-send-login-string-via-modbus.48195/

In general, I would caution you against adding support in your Modbus driver specifically for these special, non-standard use cases, as the more options added, the more confusion this results in for your users. Is it really worth confusing 99.9% of users in order to have a more convenient way to support the 0.1% of use cases?

You should also consider whether these fringe cases can be accommodated by the standard features your Modbus driver already has. For example, for Case 1, if you know the device always sends a fixed response (say Holding Registers 1 - 14), then just have the user configure your Modbus driver to request 14 Holding Registers starting at register 1.

 

Peter,

1. The product deserving of "Dummy mode" (returning X number of registers regardless of the requested number) deserves to be named publicly for induction to the Modbus Hall of Shame. That level of deviancy from the Modbus spec should not go unrewarded.

2. On the topic of password/limited access

About 10 years ago, Siemens had a Modbus version of their coriolis flow meter, the FC410 with the FC010 electronic transmitter with Modbus RTU.

One could freely read Modbus data from the flow meter. But to write to it required a PIN number. There was a Modbus register that provided the status of writeability, with the status indicating whether a PIN number had been entered making the flow meter writeable, but there was no published register to which a PIN number could be written.

Getting the PIN number into the flowmeter required Siemens' PDM configuration software.

In the two days I had one of the Modbus flowmeters on the bench, I could not get PDM to talk to the flowmeter, even though I could easily read its Modbus data with Modscan32. The PDM wizard produced a "Device Mismatch" error. Siemens PDM software, Siemens EDD file and Siemens flowmeter and the PDM software can't talk to the flowmeter.

Their tech support blamed my USB/RS-485 converter with its FTDI chipset, but could not recommend a given USB/RS-485 converter product guaranteed to work (that's called grasping at straws). I gave up on it with a thumbs down evaluation; that product was not ready for primetime.

In spite Siemens' faults, adding functionality for dealing with passwords and limited access is a worthy endeavor. Good for you.

3. Comments on your "note on Honeywell controllers".

a. As you note, FC20/21 register/addresses covers all the configuration parameters, those accessed from the keypad/display for setup/configuration. Honeywell's commercial/proprietary software configuration packages for the UDC 2xxx/3xxx most likely use the FC20/21 function, given the register numbering follows the config menu layout.

The UDC 2xxx/3xxx product line manuals creates the impression that those are the only useable function codes are FC20/21 with the listed register/addresses in the product manuals.

However, all the industrial (can't speak to HVAC) Honeywell-made products (UDC 2xxx/3xxx, HC900, DPR, Trendview) use the common FC01-FC04 function codes in spite of the UDC manuals referring only to FC20/21 register tables.

Honeywell publishes a separate Modbus manual, Modbus® RTU Serial Communications User Manual, 51-52-25-66, Revision T, February 2013, that documents all the useable function codes and address/register tables (for the non-private labeled/acquired lines), which are the "operational" values, as opposed to configuration settings. It's the operational values that 98.7% of the people I talk to are looking for.

b. The industrial Honeywell products use two of the four IEEE754 floating point formats, which they call FP_B, and FP_LB in the table below (except UDA which uses FP and FP_L). Pages 10-14 (pdf) expand on the topic.


c. Honeywell's acquired (UDA) or private labelled products (UDC 1xxx), document Modbus in their respective product manuals, so those devices are not included in the 51-52-25-66 Modbus manual. None support the FC 20/21 function codes.

 

Thank you, that was ... full of information! Thank you!
I must admit that when I was trying to talk to UDC1700, I was happy to get at least some documentation I've modified the manual so that it refers only to UDC1700 , and included your information (and a link to your post) as a Note.

 

You should also consider whether these fringe cases can be accommodated by the standard features your Modbus driver already has. For example, for Case 1, if you know the device always sends a fixed response (say Holding Registers 1 - 14), then just have the user configure your Modbus driver to request 14 Holding Registers starting at register 1.

You are absolutely right there. The reason I implemented this parameter was that (for the sake of the users) I didn't want to modify their addressing scheme (I replaced a custom OEM-written protocol with our Modbus implementation). In their addressing scheme, some registers were 2-byte registers, some were 4-byte registers. We already had support for variable-size Modbus, so I used it; however, when reading, the data are grouped depending on the register size. This caused several read requests to be generated for those 14 registers - which is what I handled by that "Dummy Request Mode" parameter.

In general, I would caution you against adding support in your Modbus driver specifically for these special, non-standard use cases, as the more options added, the more confusion this results in for your users. Is it really worth confusing 99.9% of users in order to have a more convenient way to support the 0.1% of use cases?

That's a good point (to keep the code nice and standard). However, my task is to make the driver work with all the customers (and I'm never in a position to make any changes on the Modbus Server's side). So, I keep adding these parameters on the last tab of our configuration dialog. The good news is, people usually don't touch them (unless experimenting) and non-default values are clearly discernible. See https://d2000.ipesoft.com/content/images/2023/04/Modbus_station.png