Enhance Modbus device DTM to support other Modbus Function codes then 3,16 & 23

[RoozeeR]

Modicon/Schneider Electric are the founders of Modbus and Modbus/TCP. However in our software we limit the users in functionality. All years I'm with the company, this questions pops-up regularly:

Why does Schneider NOT support the use of other Modbus function codes than 3, 16 and 23 in IO-scanning?

Other function codes can be implemented (read of %IW/3xxxx references) using DATA-EXCH functions, which is a lot of programming effort and introduces limitations, IO-scanning doesn't have.

Today I got a question (again) from one of our alliance partners: Why does Schneider not support other Modbus function codes than 3,16 and 23 while competitors like Mitsubishi, Phoenix Contact and WAGO offer this functionality by default?

Can't the Modbus Device DTM be enhanced to offer this functionality?

[SEStig]

If extra function codes are what you want then the actual "DTM" for a modbus device should be completely revamped.

Currently it isn't what i would call a DTM because there are actually no configuration options when you open it in the DTM browser. It merely provides a way for the CPU/NOC etc to instantiate a device that will use modbus functions which you need to define in the CPU/NOC rather than the device itself. This leads to the issue of not being able to copy/paste modbus devices once set up.

In the modbus device dtm you should be able to specify function codes, rep rates or trigger types etc which then GENERATES the modbus table in the NOC/CPU in the same way a VSD DTM does.

The best example of how this should be implemented is in the Generic Modbus device in EcoStruxure Machine Expert. This has all the above functions and can be duplicated once a device has been set up correctly.

Ideally you would be able to create a new device using the Modbus DTM, configure it with all the required reads/writes/data types etc then save it to a custom library for later reuse on another project.

[Trinxs1]

This feature of has been included in the product backlog.    It has not been assigned to any version yet.

[Patrick_Nijenhuis]

Good point from Rene Rozee

We have the problem now that we have to read input registers and coils. The current DTM does not support that and that is strange because the Modbus protocol and the DTM are both from Schneider, can't be that hard to implement this in the DTM.

[dnordenberg1]

I think schneider wanted to forget about these old and less used modbus telegrams because everything fits in a standard holding register which is what modern remote IOs use for both digital and analog values today. But sometimes you still come across exotic devices that still uses them and it's a bit annoying that you have to handle them in completely different way then 😞 So I totally agree with this feature request.

[ciupol]

I do not think that it is only exotic devices. I have a lot of modern devices that still use registers other than 4x.

[Patrick_Nijenhuis]

I agree with that, I saw mere then once that other commands are beiing used and now is is a lot of work for something that should be in de DTM. When it can be configured in the DTM then all communication outside of the PLC is done from one point. Now you have to go through the software to find all communication connections.

[ciupol]

If this will ever be implemented it should allow to select particular modbus command user wants to use. For example I run into devices that support only function code 06 (write single register) or only function code 16 (write multiple registers). With the device that uses only function code 06 I was not even able to use the WRITE_VAR block (or IO scanner or anything else) as it uses code 16. I had use use DATA_EXCH block and construct my own custom modbus requests which is obviously quite cumbersome.