Hi Otto, the idea was, that if for example a device (like a S7) supports S7, Modbus and OpcUA, that the result of the Discover would return 3 connection strings ... one for each supported protocol. <
Chris On 02.07.21 17:02, Otto Fowler wrote: > Some protocols the discovery process returns information about the device > (DCP, ENIP) , that might be important as well. How would this be handled / > modeled ? > > The idea here is that plc4x doesn’t store any of this right? You’d have to > handle the callback and store the information yourself? > > From: Christofer Dutz <[email protected]> > <[email protected]> > Reply: [email protected] <[email protected]> <[email protected]> > Date: June 30, 2021 at 13:53:32 > To: [email protected] <[email protected]> <[email protected]> > Subject: [DISCUSS] Discover and Browse API for PLC4J? > > Hi all, > > as you all know, I have threatened to bring API additions from plc4go > br/>back to plc4j and now the time has come. But I want to invollve you all > br/>in it as we all have to live with it ;-) < > > So in general in go I did it the following way: > > - I split the topic up into "Discovery" and "Browse" > > "Browse" I'll focus on as soon ad "Discovery" is defined. In general > br/>this should produce a stream of PlcBrowseEvents whichh provide a stream > br/>of PlcFField entries that can be used to query information. So this is > br/>inside an established connection to a device. It won't find devices > br/>(However this term is slightly ambbiguous because in KNX for example we > br/>consider a KNX devices GrouupAddress an address, even if in the > physical br/>world it actually iis a device) > > Discovery is the operation of finding out which devices we can connect > br/>to. The result is a list of PlcDiscoveryEvents. These contaain: > - protocolCode (like s7, modbus, ...) > - transportCode (like tcp, udp, serial, ...) > - transportUrl (which is the part after the "://" but before the "?" > - option (which is a map of key-value pairs making up the part after the > br/>""?" .... the part which Lukazs hates so much ;-) ) > > In go I extended the DriverManager to have a discovery function which > br/>simply iterates over all drivers it knows and if they supporrt > discovery, br/>the functionality is executed. < > > In the past we usually returned a Future and this became complete as > br/>soon as the operation was finished. However Discovery can ssometimes > take br/>quite long. Some protocols support a direct ""Please all devices > br/>supporting this report to me"" functionality, but some we will need to > br/>potentially probe by trying all IP addreesses in a given range. > Therefore br/>I think such a future approach is sub-ideal. > > In go I gave the discover function a callback argument where you set a > br/>handler that gets notified directly as soon as a device is found. I am > a br/>bit unsure if this should be the way to go. < > > What I would love to do, would be to have the option to add one > (possibly multiple) handlers to a DiscoveryRequest. Whenever something > br/>is found, then every handler is called and at the end the resuult is > put br/>into a list. As soon as the operation is complete, thee user could > then br/>use this list, just like our normal read-resultts and be happy > with it, br/>or he could use the callbacks if he wantts to be informed > directly. > > Unfortunately the Futures are so totally all-or-nothing. I would love to > br/>return something that knows the progress of the operatiion. In a > br/>Broadcast search it could simply be the progress towardd the timeout or > br/>when scanning an IP range it could be the percenntage of the addresses > br/>that were probed. This could help tools too show a nice progress on the > br/>auto-discovery. < > > What do you think? As I need this for my work on the PROFINET, I'm > br/>working on this on the feature/profinet-chris branch. < > > Chris >
