I am developing a serial Modbus interface for an existing sensor product. We plan to submit our device for conformance testing. The device's only implemented holding registers contain settings for the Modbus baud rate, slave ID, and similarly critical low level parameters. The conformance test specification V3.0 says that holding registers will be written via functions 6, 16, and 23, but is not specific about how the actual values to be written would be selected.

Similarly, the conformance test order form asks questions about address ranges supported, but is non-specific about what values are "safe" to write to registers.

My concern is that writing these registers with arbitrary values could cause the test suite to loose contact with the device.

As we wait for our copy of the test tools to arrive (and a TCP to serial gateway so I can run the suite under conditions similar to the test lab), I'm seeking some reassurance that the suite can be configured to not mess up the device, and that it is reasonable to expect to need to do so.

Any thoughts?

 

I think that's sorta what the conformance test is about. That is, it's optimistic to have critical parms that can brick the device, as a simple write to "normal" data ranges. The question that comes to my mind is when the user inevitably bricks the device, how will they recover? And how do you set them initially? And how confusing will this be for the poor guy that has to fix it. It seems the idea is prone to losing contact when you try to change anything. Or do I misunderstand?

Regards
cww

 

> I think that's sorta what the conformance test is about.

Well, I don't have an issue with testing that when you do a write operation with "safe" values that the protocol acts correctly. But the conformance test spec is pretty clear on the subject of testing only the modbus protocol, and not caring about the data content of registers.

>That is, it's
>optimistic to have critical parms that
>can brick the device, as a simple write
>to "normal" data ranges. The question
>that comes to my mind is when the user
>inevitably bricks the device, how will
>they recover? And how do you set them
>initially? And how confusing will this
>be for the poor guy that has to fix it.
>It seems the idea is prone to losing
>contact when you try to change anything.
>Or do I misunderstand?

The only parameters of my device that need to exist are the modbus serial baud rate, parity, RTU vs. ASCII and slave ID. (Following the model of some other products in the wild, I may add some controls over byte order of the 32-bit values that span more than one input register, but those aren't scheduled for implementation until a customer requires them.)

Those basic modbus parameters need to be adjustable so that the device can be integrated with a customer's network. I can (and did) arrange it so that writing zero it any of those registers is "safe" in the sense that zero is treated as meaning a factory default setting.

They don't take effect until the device is rebooted, so it is supposed to be possible to connect to it at the factory defaults, configure it for the site, then move it to the live network.

To defend against the inevitable bricking caused by accidentally writing the wrong register, I do have a side door menu that can be reached from a terminal emulator connected at a specified baud rate and configuration.

Because this is an add-in to an existing product, I can't add any user interface elements to the product itself. So I don't have many good choices for an affordance that could be used to force it back to known factory default settings.

 

Well, you sort of answered your own question. If the changes
don't register until you reboot, I would think the device
should pass fine as the test should simply write, read, check
addressing, etc. Your problem might be what state it leaves
the unit in. If this is a one time test for design conformance,
you might have to reset parms on the test unit. I would expect
that the values read and written would be part of the test, for
example, all ones, all zeroes, checkerboard to test for endian
issues, etc. At least that's how I would write it. But the only
one who would know for sure would probably be the author.

Regards
cww

 

As far as certification tests are concerned, I would suggest that you contact whoever is performing the test as they're the only ones who can tell if this is going to be an issue for them. You will need to tell them just what data you can accept.

It's quite possible that their test software isn't flexible enough to write specific values, as this isn't a problem with typical simple I/O. On the other hand it's possible that your hardware isn't the first that would react badly if given unexpected data.

I won't dwell whether or not the behaviour of the product is a good idea, but I think that Curt Wuollet has a point. Even if the module passes certification, I would not be surprised if you get a lot of customer warranty returns claiming that the module keeps "locking up" when what is really happening is the parameters keep getting changed by incorrect writes.

Ideally you would have a jumper which could be used to protect the parameter registers once they have been configured.

There is another method which I haven't seen used with Modbus (or any other industrial hardware), but which is sometimes used elsewhere. When you write a specific value to a particular register (the "unlock" register), that changes the mode to allow the parameter registers to be reconfigured. You then change the "unlock" register to some other value to write protect the configuration again. The "unlock" register will also automatically time-out back to "protect" mode after several minutes. It's not fool-proof, but it makes accidental changes less likely.

 

The Modbus Organization test tool provides a config file that you can set to provide the range of addresses for the test to execute. You can not, however, change the data value written to a register. I recommend you setup the config file to avoid writing to those critical registers so as not to "brick" the device.

Our test is mostly concerned with testing boundaries and range limits. We don't test values of the reads/writes as this is not a protocol issue, but rather an application issue. So, just avoid writing to those registers when using the test tool. If you submit for formal conformance testing, mention that clearly in the submittal form.

Hope this helps.

 

I was just reading the manual for a modbus electric power meter last night that documents the magic cookie in a specific register to unlock settings technique. That seems like a good way to render things "safe" enough under most circumstances. I can also verify its safety in my own testing before I submit for the real compliance test.

 

My copy of the conformance test toolkit just arrived moments ago. I will look carefully at its configuration capability.

>The Modbus Organization test tool provides a config file that you can set to provide the range of addresses for the test to execute. You can not, however, change the data value written to a register. I recommend you setup the config file to avoid writing to those critical registers so as not to "brick" the device.

Our test is mostly concerned with testing boundaries and range limits. We don't test values of the reads/writes as this is not a protocol issue, but rather an application issue. So, just avoid
writing to those registers when using the test tool. If you submit for formal conformance testing, mention that clearly in the submittal form.<

Does this imply that I should bury these critical registers inside a larger range where the test tool can safely read and write to the first and last documented registers?

Or since I have no no holding registers in the map that are used for anything other than device setup, should I just avoid calling out tests for holding registers and the related read and write function codes entirely?

Since this project is a retro-fit for an existing sensor, I am not supporting any configuration or calibration of the sensor itself from Modbus, just those properties needed to make the device talk to the Modbus itself.