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
