Hey Chris, I do agree that browse and discovery is different and it might be either expanded or narrowed.
For example openHAB stuff I did based on CANopen driver does following: - Discovery of CAN enabled interface For linux it is quite straight cause you can use either a "net" part of sysfs or even a dbus [1] in order to find interesting network nodes. - Discvoery of CANopen nodes Depending on strategy this could be a scan with predefined address range or simply listen who talks to the bus. For CANopen scan is quite straight, cause there is up to 127 nodes. You can submit a read out request for well known register address, ie. manufacturer code. Listening is also possible cause each node should (in theory) emit a heartbeat. - Discovery of CANopen fields readable or writable via driver. This is scan of node registers within predefined address ranges or ranges retrieved from initial node read out. I don't have this part (nor didn't plan to work on it anytime soon). This is probably a thing which is most interesting in case of data acquisition. Process is following: - [discovery] Physical interface [0..N] - [discovery] Discovery connection string [1:1] (?) - [discovery/browse] Finding accessible nodes [0..N] - [browse] Fields for a specific node [0..N] Discovery of Beckhoff stuff I did works in a following way: - Find network interfaces - Send broadcast over network interface - For each answered node - Try setting up a ADS route (requires PLC username and password) - Connect - Retrieve symbols (I did not implement this) Beckhoff uses a UDP for discovery and connection to PLC is over TCP thus you can clearly see that there are two different transports used. I believe KNX is same. For Profinet-DCP what I managed to complete with Adrian is focused only on two parts: - Finding accessible profinet devices Since they do answer with their own datas we can get their MAC which is later on used to communicate with them. Initial mapping of DCP ident response I did mapped that response to PlcStruct. Mainly because there are multiple fields which can come, including device name, DHCP settings or its ip address. Given the nature of node discovery it should by default stick with callbacks and not request/response modes. Browse is something we briefly spooked before, but it also fails into same category. We never know if discovery or browse is finite or not. For that reason API should rather assume later than earlier and let driver decide. For address range queries we indeed can have a progress indication, while for PN-DCP I don't think we should make any assumptions. I am not quire sure how big PN network can be, so I'll let others speak. In my understanding, also based on above openHAB experiences, discovery and browse APIs are kind of related, yet have different syntax. For Beckhoff definitely we get some parts for transportUrl options such as node AMS id which is advertised in identification response. For AMS there is also an authentication, however I don't think we're able to scrap this. In new versions I think there might be also a device certificate signature. Anyhow, these would be my 0.02€ of input. Best, Łukasz On 02.07.2021 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 >
