Hey Richard, If you want to confirm protocol to mspec mapping then use ParserSerializerTestsuite. It ensures that parsing and serializing is linear. All these tests confirm that we get exactly same binary output from given binary input. This helps a lot to spot gaps in mappings or incorrect endianness. If you wish to verify protocol and behavior of driver then you need to use DriverTestsuite. It allows to simulate a PLC4X client API call as well as trigger bogus PLC answers. Transport used for test is a virtual pipeline which makes it quite easy to inject invalid or wrong packets. Driver test can be seen as sequence of steps which happen one by one. As long as your driver does not do any background threads it will work. A typical sequence is like this: 1) API request for field "foo" 2) driver emits frame X 3) plc responds with frame y 4) API result is "bar" I don't think we have support for subscriptions in driver test suites. I guess we need to add it. We definitely have support for read and write. ;)
Regarding the "<raw>" tag you asked. This part for serializetion test comes from "data" section of TCP or UDP packet/frame. Each of them have header with sender, receiver and so on. These headers are not relevant from PLC4X protocol implementation as these are handled by operating system network stack and put into various structs of Java standard library. What we process is actually a "data" or "payload" section of an incoming packet. Please note that in case of TCP which handles segmentation test suites assume that data is fully assembled. There is no way to simulate chunked TCP stream. Best, Łukasz On 13.08.2021 18:04, Richard Meister wrote: > Hi Łukasz, > > thank you for these hints! I've just created a PR. > > Maybe I'll add some test cases as well, but currently I'm not sure where to > put them, DriverTestsuite or ParserSerializerTestsuite (or both?). > > <raw>00002c000000c0a8171401015303c0a817c801015303020004000c000000000000000200000005f000000000801a01000000</raw> > Are these raw elements constructed by hand or take from a recording/pcap file? > > > Best regards, > Richard > > -----Ursprüngliche Nachricht----- > Von: Łukasz Dywicki [mailto:l...@code-house.org] > Gesendet: Mittwoch, 4. August 2021 18:48 > An: dev@plc4x.apache.org > Betreff: Re: ADS Subscriptions for >0.8 > > Hey Richard, > Before you go and spend time on Request Transaction Manager (RTM) - please > note that it does impact sending of requests, also for subscriptions, but > does not block incoming packets. This is an coordination mechanism for plc4x > to control data link access. > Since I haven't looked nor compared ADS driver logic between releases you did > mention I suppose that we simply missed a handling of subscriptions in this > or other way. This logic should be portable with little effort. My suggestion > towards you is to compare these parts of drivers to see how 0.8 or 0.9 > evolved. > > The only case when RTM comes into the play is when you do want to send > another request once you receive answer for previous one. In such cases you > need to do everything inside transaction runnable which accquired the 'lock'. > Also make sure that you release it both for success and failure scenarios. > If you fail to release transaction then your subsequent requests will get > stuck. It is fairly easy to spot if you do smaller changes. > > Kind regards, > Łukasz > > śr., 4 sie 2021 o 17:41 Richard Meister <richard.meis...@ascon-systems.de> > napisał(a): > >> Hi Christofer, >> >> thank you for the quick response and good to hear there is no specific >> technical reason. I will give it a go and come back with a PR and >> (probably) more questions :) >> >> >> Regards, >> Richard >> >> -----Ursprüngliche Nachricht----- >> Von: Christofer Dutz [mailto:christofer.d...@c-ware.de] >> Gesendet: Mittwoch, 4. August 2021 17:05 >> An: dev@plc4x.apache.org >> Betreff: AW: ADS Subscriptions for >0.8 >> >> Hi Richard, >> >> first of all, welcome and happy you like our little project :-) >> >> There is no technical reason for us not supporting subscriptions. In >> general the only reason is that when I re-wrote the driver from 0.6 to >> 0.8 I switched from single-item requests to multi-item requests. There >> was some semi-documentation on this for read and write. However not >> for subscriptions. So this would require some reverse-engineering work >> and I simply didn't have the time for that. >> >> I think this would definitely be something we'll be providing in the >> future ... I just can't say when I'll have the time for it. >> >> If this however is something you and your company need, feel free to >> work on this ... I'd be willing to be of assistance as long as the >> results go back into the open-source project. >> >> Or if you're willing to put a few bucks on the table this definitely >> can help shift some priorities ;-) >> >> Chris >> >> >> -----Ursprüngliche Nachricht----- >> Von: Richard Meister <richard.meis...@ascon-systems.de> >> Gesendet: Mittwoch, 4. August 2021 16:30 >> An: dev@plc4x.apache.org >> Betreff: ADS Subscriptions for >0.8 >> >> Hi everyone, >> >> first of all, thank you for creating and maintaining this project! >> PLC4X helped us to get started with ADS in Java quickly and painlessly. >> >> The matter of my writing is that we use subscriptions as the primary >> communication mode for ADS, so to the best of my knowledge we're bound >> to v0.6(.1). We've applied a patch to set the cycleTime in >> AdsTcpPlcConnection to zero, because otherwise we would miss changes >> that occur more frequently than once per 400ms. >> Probably there are some good reasons that subscriptions do not work >> with the generated driver. I have poked a bit into the code of v0.8 >> and presume it is a restriction of the RequestTransactionManager. But >> before taking a deep dive into the code I thought I'd hear your thoughts on >> this first. >> Maybe someone can point me into the right direction and enable me to >> contribute. I'm willing to spend time on this and I have access to a >> Beckhoff iPC with TwinCat 2 for testing. >> >> >> Cheers, >> Richard >> >> >> >>
