Have not seen this before, but then I haven't worked a long time with the Wago's as targets under CoDeSys.
Project has 2 ModbusTCP servers. (1) on port 502, (1) on port 503. No matter how I structure queries in ModbusPoll - I get 'Gateway path unavailable'.
CoDeSys 3.5.16.10
Some items to note:
The server(s) have nothing in the device tree - they are called via structured text. This has not been a problem to date on other projects...
I though perhaps it was related to the unit ID? It's 1 for the query and the response.
Wire shark query....
Wireshark response....
PFC200 Ethernet setup....
This example uses very high holding register locations...which has been a problem for some platforms in the past, but when I reconfigure my query to just a few registers at lower HR addresses the behavior is the same.
In limited testing I added the 'Interface Name' to the function call - but it was worse in that Modbus poll would not even connect. Besides, I deally I would like these servers to respond on both X1, and X2 NICs...
I have a feeling this is something stupid/simple.
Any help appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed...
So, the PFC200 will respond if Slave ID = 0, whereas the other targets I have been using do not care, or were using Slave ID = 1. As that is how all of my Modbus poll files are setup.
Last edit: S1ack 2020-08-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With SP16, UnitID 0 works because it is the broadcast address. The actual UnitID is 0xFF, and if you check out the ModbusTCP Spec at modbus.org, it says the UnitID should be 0xFF, unless you are using it as a gateway, eg. a modbus serial gateway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Question: Is this new to SP16? If I revert to SP15 can a unit ID of 0x01 still be used? And not result in a gateway exception?
Because I can see a real problem here. Suppose I want a CoDeSys SP16 target to be a client to another CoDeSys SP16 server (and indeed I do).
When I configure that server in SP16, 0 and 255 (0xFF) are NOT ALLOWED as unit IDs in the configuration dialog.
So while Modbus Poll can deal with this change easily, CoDeSys apparently cannot.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"With SP16" can you please elaborate. Is this with the CoDeSys Control for PFC runtime on the target? Or with the version of the IDE? Or the version of the Ethernet device? I have saved my project as SP15 Patch40 (with matching compiler rev). And a Unit ID of 1 does not work. I have down reved the ethernet device to SP15, same result.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have not seen this before, but then I haven't worked a long time with the Wago's as targets under CoDeSys.
Project has 2 ModbusTCP servers. (1) on port 502, (1) on port 503. No matter how I structure queries in ModbusPoll - I get 'Gateway path unavailable'.
CoDeSys 3.5.16.10
Some items to note:
The server(s) have nothing in the device tree - they are called via structured text. This has not been a problem to date on other projects...
I though perhaps it was related to the unit ID? It's 1 for the query and the response.
Wire shark query....
Wireshark response....
PFC200 Ethernet setup....
This example uses very high holding register locations...which has been a problem for some platforms in the past, but when I reconfigure my query to just a few registers at lower HR addresses the behavior is the same.
In limited testing I added the 'Interface Name' to the function call - but it was worse in that Modbus poll would not even connect. Besides, I deally I would like these servers to respond on both X1, and X2 NICs...
I have a feeling this is something stupid/simple.
Any help appreciated.
Indeed...
So, the PFC200 will respond if Slave ID = 0, whereas the other targets I have been using do not care, or were using Slave ID = 1. As that is how all of my Modbus poll files are setup.
Last edit: S1ack 2020-08-11
With SP16, UnitID 0 works because it is the broadcast address. The actual UnitID is 0xFF, and if you check out the ModbusTCP Spec at modbus.org, it says the UnitID should be 0xFF, unless you are using it as a gateway, eg. a modbus serial gateway.
Question: Is this new to SP16? If I revert to SP15 can a unit ID of 0x01 still be used? And not result in a gateway exception?
Because I can see a real problem here. Suppose I want a CoDeSys SP16 target to be a client to another CoDeSys SP16 server (and indeed I do).
When I configure that server in SP16, 0 and 255 (0xFF) are NOT ALLOWED as unit IDs in the configuration dialog.
So while Modbus Poll can deal with this change easily, CoDeSys apparently cannot.
I found a means to enable a Unit Id of 0xFF. Remove the unit Id completely and it will revert to the default value 0xFF.
"With SP16" can you please elaborate. Is this with the CoDeSys Control for PFC runtime on the target? Or with the version of the IDE? Or the version of the Ethernet device? I have saved my project as SP15 Patch40 (with matching compiler rev). And a Unit ID of 1 does not work. I have down reved the ethernet device to SP15, same result.
The Modbus TCP Slave Device must be SP16 or higher for the new functionality.
Tested with 0xFF on modbus poll, and it works with PFC and older platform. Thanks