Modbus TCP access to unimplemented functions

[ronj]

Hi,
I have an application that needs to read some of the Modbus function code 08 (diagnostics  - error counters etc) and also read the slave device identification - function code 43. I understand that these function codes are not supported in AdvancedHMI.

These are part of the Modbus standard, but not all that commonly used, so I understand why they are not implemented. I am certainly not suggesting they should be, just looking for a work around.

In order to access these less common functions and possibly others, is it possible to call some existing low level function (maybe the data link layer) with a string etc containing the Modbus query (ie the PDU) to be sent  and then receive the PDU from the reply as a raw un-parsed string into the text property of a control or another callback function etc?

Ron

[Archie]

Not sure if this will work for those particular function codes, but you can try to force function codes likes this:

43:000

See this thread for more details:

http://advancedhmi.com/forum/index.php?topic=765.0

[Archie]

You can also probably implement those function fairly easily by modifying ModbusBase.vb

You can use the BeginRead function as an example to create a function to implement the other functions.

[ronj]

Hi Archie,
Thanks for your comments.

The 43:000x syntax works to a point, however the PDU sent is not formatted correctly. I fixed  this with a some special treatment just for function code 43 in the BeginRead function in ModbusBase.vb. This all works and Wireshark shows the correct packet being sent and the expected response coming back.

Somehow this response seems to get lost somewhere. The DataLinkLayerDataReceived function in ModbusTCPCom.vb never gets called.
If I understand the workings of this, I'm thinking that it would be called by the Modbus TCP driver DLL. Is there some kind of filtering in the DLL to reject incoming packets that maybe don't follow the rules for the implemented Modbus functions?

The response Modbus PDU (as per Wireshark) is 60 bytes, in case length is an issue.

Regards,
Ron

[Archie]

Can you post the WireShark capture so I can see the packet response?

[ronj]

Here is the response packet...

[Archie]

Are you using version 3.99a?

[ronj]

I am using Ver 3.99  (AdvancedHMIBetaV399.zip).
Please let me know if I should re-test with 3.99a

[Archie]

Version 3.99a does not filter what goes to the DataReceived event handler.

[ronj]

Hi Archie,
Updating to 3.99a solves the problem of received packets for the unimplemented functions not getting through - thanks.
Now a different problem on the sending side...
For the two new functions I am implementing (8 and 43), everything seems to work fine when there is only one of the new commands used (eg in a basic label). If I have a few of them on the same page eg 8:00011 8:00012 8:00014 etc some of them work and some don't. Each of them works fine if used by itself. The presence or absence of controls using the standard Modbus function codes does not appear to make any difference. A little checking shows that the ones that don't work never get through to BeginRead(). I imagined that they might be getting eaten by the code that does the bit read optimisation for "coils", so I tried adding 40000 to all the addresses (eg 8:40011 etc) and subtracting the 40000 in BeginRead(). This seemed to make no difference. Is there some easy way to disable the read address optimising logic, just for a test?
Regards, Ron

[Archie]

In ModbusBase.vb at line 515, you will see "< 20" at the end of the line, change that 20 to a 0