Hi,
I am trying to read Modbus address above 32767 using ModBusTCP.
Anyone can help me?
I would like to know the syntax to reed register 33792 as shown below.
I tried IRUS33792, IRUS33791 and IRUS33793 without success.
Here is the list of Register I need to read.
Thank you for your help.
Are you able to read other registers in lower ranges? I ask because there could be some configuration of the device that's wrong. Also, make sure the OPC path is in the form of
ns=1;s=[DeviceName]1.IRUS33792
Where the 1 after the device name is the node address of the modbus device.
Edit: Are you getting an error or just data that doesn't look correct? Screenshots of relevant configurations and errors can help.
When hex addresses are displayed, they are always zero-based, in my experience. IA's driver defaults to using one-based addresses. Double check your device's advanced settings.
Hi Michael,
Here is my config.
I tried using ModbusPoll tool for a test and here is the result.
Any clue on what is wrong?
Thank you
That's not what it says.
It's saying you are getting an exception response from the device with exception code 0x03.
Compare Wireshark traffic between Modbus Poll and Ignition to see what's different about the request/response.
Your Ignition logs are referencing address 31745, not 33792, which is odd. Might be best for you to disable all but one tag while you figure this out.
I think it's showing -31745, which is odd because if you take 33792 in binary is:
1000 0100 0000 0000
and when converted to a 16-bit integer is: -31744
So just 1 off of the -31745 it shows which if you offset the 33792 by 1 to 33791, then you get -31745 and in binary:
1000 0011 1111 1111
So could be the logs incorrectly formatting the address.
Good eye. I think that's just a formatting bug in the logs.
So, @jean.arnosti try addressing 33793, or keep 33792 and configure the driver to be in zero-based addressing mode.
Ok will try this today and let you know. I will also put Wireshark and look at the request and response. Will put the result later
Hi Kevin,
Here is the result on my test.
I set the ModbusTCP as Zero-based adressing
and OpcItemPath as ns=1;s=[ModbusTCP]1.IRUS33792
as you and Michael suggested.
The Query and response from the I/A ModbusTCP driver are OK.
But in the Ignition log there a timeout message.
Still have bad value at the tag . (Only one tag query in the test)
What would cause this timeout message?
Here is a snap shot of WireShark with result
There is no timeout
Modbus/TCP
Transaction Identifier: 148
Protocol Identifier: 0
Length: 6
Unit Identifier: 1
Modbus
.000 0100 = Function Code: Read Input Registers (4)
Reference Number: 33792
Word Count: 1
ModbusPoll Response
00 94 00 00 00 04 01 04 02 17
Wireshark result
Modbus/TCP
Transaction Identifier: 148
Protocol Identifier: 0
Length: 4
Unit Identifier: 1
Modbus
.000 0100 = Function Code: Read Input Registers (4)
[Request Frame: 9]
[Time from request: 0.082751000 seconds]
Byte Count: 2
Data: 17
Ignition Query
00 05 00 00 00 06 01 04 84 00 00 01
Wireshark result
Modbus/TCP
Transaction Identifier: 5
Protocol Identifier: 0
Length: 6
Unit Identifier: 1
Modbus
.000 0100 = Function Code: Read Input Registers (4)
Reference Number: 33792
Word Count: 1
Ignition Response
00 05 00 00 00 04 01 04 02 17
Wireshark result
Modbus/TCP
Transaction Identifier: 5
Protocol Identifier: 0
Length: 4
Unit Identifier: 1
Modbus
.000 0100 = Function Code: Read Input Registers (4)
[Request Frame: 22]
[Time from request: 0.086050000 seconds]
Byte Count: 2
Data: 17
I still have a bad as value of the tag
Here is a snap shot of the Ignition log
You seem to be communicating with a broken Modbus implementation.
This isn't a valid response to a Read Input Registers request.
00 05 transaction id
00 00 protocol id
00 04 length
01 unit id
04 function code
02 byte count
17 only 1 byte?
in your previous modpoll screenshots it looks like the device might actually be returning 17 6E, but since it seems to be incorrectly calculating the frame size in the MBAP header that doesn't end up being read or seen by the driver. The length indicated by the header in this case should be 5, not 4.
Problem solved.
Manufacturer fix the broken Modbus implementation
I would like to point out that ModBusPoll tool do not check nor verify the lenght of response.
This is why there is no error in ModbusPoll.
Thank you for your help