Something I've learnt about ADS in the last few days

[Christofer Dutz <ch...@c-ware.de>]

Hi all,

I guess we‘ll have to think a bit about the ADS protocol.
So-far we have been connecting to the PLC using ADS, but I have just recently learnt that we can actually do a lot more.

For example, the thing with the AmsNetId, where we simply add “.1.1” to the IP. I can also reach the TwinCAT master that is attached to my PLC by connecting to the same IP, but using the AmsNetId “.3.1” at the end.
Also did I notice that what we do with: reading out the symbol tables and the datatypes only seems to work with the PLC instance. If I connect to the Device Manager for reading out telemetry, this doesn’t work. Also don’t the multi-item-requests work.
Now I’m experimenting with reading data from some IO cards, that are attached to my PLC via EtherCat adapter.

I really should find out how to detect which features work and to add fallback layers (Like switching from Multi-Item-Requests to Single-Item-Requests if that’s not supported).

But really interesting stuff you can theoretically do with our driver in it’s current state.


Chris

Re: Something I've learnt about ADS in the last few days

[Łukasz Dywicki <lu...@code-house.org>]

Hey Chris,
The "back" connection from PLC could be the reason why PLC4X connection 
does not show "connected" status in route window when using Beckhoff 
engineering tools. I remember that using TC2 stuff a while ago I often 
saw a "read_device_request" coming from PLC end to the PLC4X client.

According to other repositories I found at bitbucket [1] there is 
probably a wider range of operations performed over ADS. Stuff which is 
being published at Beckhoff's github did grew over past couple of years, 
but its still fairly small, even comparing to findings implemented in 
our project. From bitbucket repositories I mentioned there seem to be a 
"device specification" of some kind which allow to use ADS function 
blocks on PLC end while fetching or writing the data to other network 
participant. Looking at official documentation there is nothing more 
than a packet structure. Either there is better docs or it is being 
distributed across so many places that nobody can sum it up into 
something more consistent.

[1] https://bitbucket.org/jmikucki/cpp-ads/ [it does not compile, be 
aware it does not declare any license too]

Best,
Łukasz

On 14.01.2023 15:52, Christofer Dutz wrote:
> Hi all,
> 
> I guess we‘ll have to think a bit about the ADS protocol.
> So-far we have been connecting to the PLC using ADS, but I have just recently learnt that we can actually do a lot more.
> 
> For example, the thing with the AmsNetId, where we simply add “.1.1” to the IP. I can also reach the TwinCAT master that is attached to my PLC by connecting to the same IP, but using the AmsNetId “.3.1” at the end.
> Also did I notice that what we do with: reading out the symbol tables and the datatypes only seems to work with the PLC instance. If I connect to the Device Manager for reading out telemetry, this doesn’t work. Also don’t the multi-item-requests work.
> Now I’m experimenting with reading data from some IO cards, that are attached to my PLC via EtherCat adapter.
> 
> I really should find out how to detect which features work and to add fallback layers (Like switching from Multi-Item-Requests to Single-Item-Requests if that’s not supported).
> 
> But really interesting stuff you can theoretically do with our driver in it’s current state.
> 
> 
> Chris
> 
>