Hi, I agree that EtherCAT is dynamic in that it allows Hot Plugging of modules. But every time a module is added or removed the system is rescanned, all slaves are put into PREOP, Distributed clocks delays are recalculated etc then all configured slaves put back into OP.
So although you can dynamically plug in modules at any time, your application first of all needs to configure expected modules, and if they exist know what to do with them. So at some point your application needs to know all possible modules that could be plugged in. (EoE modules are slightly different though in that they also work in PREOP.) You say you don't use aliases on your EoE modules, but do you use aliases on the rest? (or at least the couplers?) If not how do you know what is currently plugged in? Regards, Graeme. -----Original Message----- From: Esben Haabendal [mailto:esbenhaaben...@gmail.com] On Behalf Of Esben Haabendal Sent: Friday, 2 March 2018 10:50 PM To: Graeme Foot <graeme.f...@touchcut.com> Cc: etherlab-dev@etherlab.org Subject: Re: [etherlab-dev] EoE patchs and questions Graeme Foot <graeme.f...@touchcut.com> writes: >> -----Original Message----- >> From: Esben Haabendal [mailto:esbenhaaben...@gmail.com] On Behalf Of >> Esben Haabendal >> Sent: Thursday, 1 March 2018 2:02 AM >> To: Graeme Foot <graeme.f...@touchcut.com> >> Cc: etherlab-dev@etherlab.org >> Subject: Re: [etherlab-dev] EoE patchs and questions >> >> Hi Graeme >> >> Graeme Foot <graeme.f...@touchcut.com> writes: >> > So the first patch does a few things: >> > >> > 1) adds explicit eoe_addif and eoe_delif tool functions so that you >> > can manually add/remove an eoe iface without the slave existing >> > 2) no longer deletes and eoe iface if the slave disappears >> >> This is a behavioral change compared to how eoe interface work now. >> And it will break our current system, which relies on the interfaces >> being created and deleted together with the slaves. > > The changes have added a couple of settings to the ethercat config > file (EOE_INTERFACES and EOE_AUTOCREATE). The default for > EOE_AUTOCREATE is true, so eoe interfaces will be autocreated as EOE > slaves are connected. The only "breaking" behavioral change here is > that they will no longer be deleted when the slave is removed. Yes, I see that. > The only issue I have with this is that if you connect a slave that > does not yet have an alias set, it will auto-create using position > naming (e.g. eoe0s4). We don't use aliases, but I have other issues with the change. We have created a daemon which listens to netlink(7) messages, taking appropriate actions when interfaces come and go, links go up and down. This is used to setup all network related configurations, including adding eoe interfaces to bridges. This will obviously not continue to work as it does if eoe interfaces suddenly is not deleted when slaves disappear. > Once the alias is set it will auto-create using the alias naming (e.g. > eoe0a16000) but keep the position named eoe port. As this is usually > at setup and configuration time then you are likely to reboot and it > will be gone. (Or you can explicitly call the eoe_delif > function.) > >> >> With EtherCAT being a dynamic structure, I don't see this new way is >> supposed to work in general use-case, where the bus configuration is >> not guaranteed to be fixed. > > When the EOE slave is removed the port transitions to a disconnected > state (like pulling the plug out of a normal network card). My > (unfounded) feeling is that this would be preferable to other software > using the port rather than deleting the interface all together. This way of looking at it implies a static EtherCAT bus configuration. By nature, EtherCAT is dynamic. Whenever changes are detected, the bus is rescanned, and slaves are added / deleted accordingly. When the bus configuration is changed, the new configuration might not be wrong, so insisting on the previous configuration could therefore be problematic. > It also means that if you have added the port to a bridge (my use > case) then it will remain in the bridge and resume once it is plugged > back in again. > If it is deleted then it is removed from the bridge and the next time > it is plugged in again it will need to be manually re-added it to the > bridge. As described above, we handle this in the dynamic case. If an interface is deleted, it is naturally removed from the bridge. If it is added again, it will added back to the bridge. > I would think that even in a dynamic structure if an EOE module has > been plugged in once it is likely to be plugged in again at some > stage. Maybe, maybe not. It really depends on the use-case. >> Would it be possible to make this new behavior optional, so that the >> default behavior is as it is now? > > Sure. Two options: > 1) Have another ethercat config file option: EOE_AUTODELETE (default > true) > 2) Have EOE_AUTOCREATE also mean that it will auto-delete. > > I prefer option 2 for ease of implementation, though option 1 would be > better if my assumptions above are correct. Try the attached > completely untested (and manually edited) patch file for option 2. I think I prefer option 2. I think it could cause to much trouble to enable auto-create without auto-delete. Think for example of a system where slaves have separate power supplies. When powering up the system, you might have some temporary bus configurations until all slaves are powered up. If you have auto-create and not auto-delete, you will risk having random garbage eoe interfaces created during that. > >> >> /Esben >> > > I'm interested to know what your application is to have such a dynamic > structure. Let me answer that in two ways. 1. I really believe EtherCAT is a protocol with an inherent dynamic bus structure. While you can specify a desired bus configuration, and try to do error checking with the scanned bus, the fact is still that bus structure really is dynamic. 2. Our systems are build on a number of separately powered racks. Sometimes installed far from each other. We need to handle power up of these in any order. And we need to handle random power cycles of distributed racks. And to make matter even "worse", we aim at building applications that can work with optional features, i.e. optional EtherCAT slaves might or might not be present. /Esbem _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
