It shouldn't be difficult to "pick data out of a single domain destined for multiple endpoints". When you register the domain, you'll get an offset to each entry in the ec_pdo_entry_reg_t -- this is where the data is read from or written to. It's a simple byte offset from the domain's base data pointer, which in turn means that it's very easy to obtain pointers to each individual entry for each slave, as long as you save these offsets/pointers somewhere that you can get at when processing the domain.
Using a single domain reduces the overhead of the data transfer since it packs pure data into the byte-space, whereas multiple domains have some extra datagram metadata overhead. Using a single domain can make it harder to deal with individual offline devices -- the domain state changes to EC_WC_INCOMPLETE but can't tell you which of the slaves' data is missing unless you can determine that from the data itself. (Many slaves will provide an input that toggles or increments on every cycle to make that easier, however.) With individual domains it becomes easier to tell which data is missing as each domain will typically either be EC_WC_ZERO or EC_WC_COMPLETE, without any incomplete domains. Multiple domains also allow you to use different cycle times for some slaves, simply by not queuing/processing that domain in some cycles. (It's also possible to use separate cyclic tasks, but that requires more care.) Some (old) slaves actually require using separate domains for their input and output data, since they only support LRD and LWR datagrams and not LRW datagrams. Usually though the guideline is to use a single domain for each "cluster" of slaves (where the whole set are likely to go online or offline together, such as an EK1100 group or a hotplug tree branch), to avoid the datagram overhead, or to use a single domain per cycle rate if you can otherwise determine when data is stale. Multiple domains can be transferred in the same frame (assuming you make a single call to ecrt_master_send), but each one adds 12 bytes of overhead to the frame since each domain must be a separate datagram. This increases the time required, and if you have many domains, it increases the chance that multiple frames will have to be sent due to the overhead size. FWIW, my own app works in a similar dynamic-discovery fashion. It uses a single large domain because the slaves do provide a way to detect when they haven't updated their data. Gavin Lambert Senior Software Developer COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand Switchboard: +49 2630 96520 | https://www.tomra.com The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication. -----Original Message----- From: Gary Grobe Sent: Thursday, 14 November 2019 12:59 To: [email protected] Subject: [etherlab-users] Multiple Domains I have a user-space app that discovers slaves on the network and dynamically builds the ec_pdo_entry_reg_t struct to be used in registration of PDO's for a domain based on a mix of discovery and user configuration. I've since found that it's quite difficult to pick data out of a single domain destined for multiple endpoints which has led me to consider the use of multiple domains as an option. If I did go with multiple domains, the data in this case would be exchanged at the same frequency. My reasoning for considering multiple domains is so that each endpoint receives only the data required for that endpoint. I was hoping to get some recommended guidelines when it comes to implementing multiple domains, up to how many, what are the impacts on performance (whether same or different frequencies), etc...? Any suggestions/advice much appreciated. _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
