https://forge.codesys.com/forge/talk/Engineering/thread/a4bb75ba9b/2020-08-18T11:53:42.697000ZRecent posts to CoDeSys Control for PFC200 ModbusTCP Server Returns Exception:' Gateway path unavailable'2020-08-18T11:53:42.697000Z2020-08-18T11:53:42.697000Zi-campbellhttps://forge.codesys.com/u/i-campbell/https://forge.codesys.comd856c4740f77c0147615e1cef9a100a869830a8c

<div class="markdown_content"><p>The Modbus TCP Slave Device must be SP16 or higher for the new functionality.</p></div>

2020-08-18T11:11:07.085000Z2020-08-18T11:11:07.085000ZS1ackhttps://forge.codesys.com/u/s1ack/https://forge.codesys.com897f7bbb7ef0fbdec868dcc023369b2ccaaa7359

<div class="markdown_content"><p>"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.</p></div>

2020-08-17T11:20:28.643000Z2020-08-17T11:20:28.643000ZS1ackhttps://forge.codesys.com/u/s1ack/https://forge.codesys.com67b9f56b65187ba344879d712c7dffd7d00a5ad1

<div class="markdown_content"><p>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. </p></div>

2020-08-17T10:38:23.754000Z2020-08-17T10:38:23.754000ZS1ackhttps://forge.codesys.com/u/s1ack/https://forge.codesys.come2bdf892aa9cf986c8a5d0391f272e2e0d6dbf95

<div class="markdown_content"><p>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?</p> <p>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).<br/> When I configure that server in SP16, 0 and 255 (0xFF) are NOT ALLOWED as unit IDs in the configuration dialog.</p> <p><a href="https://imgur.com/FWfKPNK" rel="nofollow"><img rel="nofollow" src="https://i.imgur.com/FWfKPNK.png" title="source: imgur.com"/></a></p> <p>So while Modbus Poll can deal with this change easily, CoDeSys apparently cannot.</p></div>

2020-08-12T12:07:05.706000Z2020-08-12T12:07:05.706000ZS1ackhttps://forge.codesys.com/u/s1ack/https://forge.codesys.com6c27ddee97fd3760770f863f8e1015090f2a5549

<div class="markdown_content"><p>Tested with 0xFF on modbus poll, and it works with PFC and older platform. Thanks</p></div>

2020-08-11T18:59:07.904000Z2020-08-11T18:59:07.904000Zi-campbellhttps://forge.codesys.com/u/i-campbell/https://forge.codesys.com824b3db82f6f69049c125024fe5e9c82e5dbdf5a

<div class="markdown_content"><p>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.</p></div>

2020-08-11T18:20:57.677000Z2020-08-11T18:20:57.677000ZS1ackhttps://forge.codesys.com/u/s1ack/https://forge.codesys.com59e5c3d0deae3cae103e5e706b29025fd0af63ef

<div class="markdown_content"><p>So, the PFC200 will respond if Slave ID = 0, whereas the other targets I have been using do not care, or were using Salve ID = 1. As that is how all of my Modbus poll files are setup.</p></div>

2020-08-11T17:07:52.493000Z2020-08-11T17:07:52.493000ZS1ackhttps://forge.codesys.com/u/s1ack/https://forge.codesys.com7cb8f0a141cf036676466abd4a7014c11966f5d6

<div class="markdown_content"><p>Have not seen this before, but then I haven't worked a long time with the Wago's as targets under CoDeSys. <br/> 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'.</p> <p>CoDeSys 3.5.16.10<br/> Some items to note:<br/> 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...</p> <p><a href="https://imgur.com/WbVyUBk" rel="nofollow"><img rel="nofollow" src="https://i.imgur.com/WbVyUBk.png" title="source: imgur.com"/></a></p> <p>I though perhaps it was related to the unit ID? It's 1 for the query and the response.<br/> Wire shark query....</p> <p><a href="https://imgur.com/fdB0wbv" rel="nofollow"><img rel="nofollow" src="https://i.imgur.com/fdB0wbv.png" title="source: imgur.com"/></a></p> <p>Wireshark response....</p> <p><a href="https://imgur.com/i4oTeH2" rel="nofollow"><img rel="nofollow" src="https://i.imgur.com/i4oTeH2.png" title="source: imgur.com"/></a></p> <p>PFC200 Ethernet setup....</p> <p><a href="https://imgur.com/hXvnbTN" rel="nofollow"><img rel="nofollow" src="https://i.imgur.com/hXvnbTN.png" title="source: imgur.com"/></a></p> <p>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.</p> <p>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...</p> <p><a href="https://imgur.com/ZmlpqID" rel="nofollow"><img rel="nofollow" src="https://i.imgur.com/ZmlpqID.png" title="source: imgur.com"/></a></p> <p>I have a feeling this is something stupid/simple.<br/> Any help appreciated.</p></div>