Re: [etherlab-dev] Multiple mailbox protocols and other issues
On 3 March 2015 01:49, quoth Knud Baastrup: Thanks, attached updated patches. See inline comments. Looks good, as far as I can see. :) Although speaking of syslog spam, I'm getting quite a lot of Busy - processing internal SDO request! now. Although speaking of the EC_REGALIAS code, if that's enabled and if the register 0x0012 alias is different from the SII alias, then this patch might malfunction (it should probably skip reading the SII alias and go straight for the register). Having said that, normally the two should be the same, unless someone is in the process of changing the alias (in which case rebooting the slave afterwards should fix everything). There might be some odd slaves out there though, which could be why EC_REGALIAS was added in the first place..? The patch should not be malfunctioning, but yes if alias (or a serial number) is updated after a re-scan the stored sii_image cannot be matched in the coming re-scan and a new sii_image will be created for that particular module. The issue would be if some slave always had some wrong value in its SII but loaded some other value to register 0x0012 on startup (eg. from onboard dipswitches). This is not as unlikely as it sounds as it can be quite awkward for the slave to access its own SII, especially with the default Etherlab configuration (EC_SII_ASSIGN is not defined by default, and I'm fairly sure it's not implemented correctly anyway). This could either work by coincidence (if the wrong value was still unique), or cause either a cache miss or in the worst case a hit on the wrong data (if that alias value is shared with another slave). Fortunately the standards require that in this case the wrong SII value must be zero, which would just make your patch ignore the alias instead of getting an invalid cache hit, but it's always possible there's some slave that violates this. (Also the standard says that in case they're both non-zero it doesn't need to signal an error until the INIT-PREOP transition, and the scan may occur before this.) So I was thinking that in the EC_REGALIAS case your patch should just read register 0x0012 sooner instead of reading the SII alias at first and then reading 0x0012 later (but not using the latter for the SII lookup). It'd save several network cycles too. Having said that, I don't know how common use of EC_REGALIAS is (I don't use it myself). Maybe it doesn't really matter. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
On 13 February 2015 21:39, quoth Knud Baastrup: Nice! Although there still seem to be some funny things going on with the whitespace, eg. see patch 0013's master/fsm_slave_config.c's second hunk (ec_fsm_slave_config_enter_mbox_sync). I guess I need more help to figure this out. I cannot (with my current knowledge of patch management) see anything wrong in this specific hunk (line 374 to 476). Do you get some kind of warning when applying the patch or how do you observe the issue? The second hunk covers lines 467 to 524 in the patched file. There's no patching errors or anything like that, it's just that the inserted lines have only four spaces instead of eight, so the indentation appears wrong when compared to the surrounding code. I didn't examine the patches with a fine-toothed comb (though I did spend a bit of time looking through them, of course), so I don't know if there are other instances of this or if this was the only one, but I happened to notice this case so I thought I'd mention it. Obviously it doesn't affect the actual operation of the patch, it's just a code style issue. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
Thanks, it is just fine you mention these kind of issues as well as I any way would not know as you mention your selves. I can see the lines having only one indentation after a line break and not two and it is actual an indentation error that is also present in the stable-1.5 branch and it has not been corrected with the patch. Thanks, Knud -Original Message- From: Gavin Lambert [mailto:gav...@compacsort.com] Sent: 15. februar 2015 23:36 To: Knud Baastrup Cc: etherlab-dev@etherlab.org Subject: RE: [etherlab-dev] Multiple mailbox protocols and other issues On 13 February 2015 21:39, quoth Knud Baastrup: Nice! Although there still seem to be some funny things going on with the whitespace, eg. see patch 0013's master/fsm_slave_config.c's second hunk (ec_fsm_slave_config_enter_mbox_sync). I guess I need more help to figure this out. I cannot (with my current knowledge of patch management) see anything wrong in this specific hunk (line 374 to 476). Do you get some kind of warning when applying the patch or how do you observe the issue? The second hunk covers lines 467 to 524 in the patched file. There's no patching errors or anything like that, it's just that the inserted lines have only four spaces instead of eight, so the indentation appears wrong when compared to the surrounding code. I didn't examine the patches with a fine-toothed comb (though I did spend a bit of time looking through them, of course), so I don't know if there are other instances of this or if this was the only one, but I happened to notice this case so I thought I'd mention it. Obviously it doesn't affect the actual operation of the patch, it's just a code style issue. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
See my in-lined comments! BR, Knud -Original Message- From: Gavin Lambert [mailto:gav...@compacsort.com] Sent: 12. februar 2015 23:50 To: Knud Baastrup Cc: etherlab-dev@etherlab.org Subject: RE: [etherlab-dev] Multiple mailbox protocols and other issues On 13 February 2015 03:30, quoth Knud Baastrup: I have attached a new set of patches (now by using git format-patch, which also imply that the patch names are given by the commit text). I believe that I have addressed the issues you highlighted in prior mails including the alias support that might be relevant for us as well sometime in the future. Nice! Although there still seem to be some funny things going on with the whitespace, eg. see patch 0013's master/fsm_slave_config.c's second hunk (ec_fsm_slave_config_enter_mbox_sync). [Knud] I guess I need more help to figure this out. I cannot (with my current knowledge of patch management) see anything wrong in this specific hunk (line 374 to 476). Do you get some kind of warning when applying the patch or how do you observe the issue? The locks that conflicts with RTAI could be removed with a define guard, e.g. re-use the EC_RTDM define already available? They're not conflicts, and I wasn't suggesting any specific changes (as I said, I don't use RTDM myself so I don't really know specifics). It was just a comment to indicate why the master originally didn't do any locking there, and that your original problem *could* theoretically have been solved by doing the locking in the application code instead, as it's only an issue with concurrent realtime tasks, which are likely to need some application-level locking anyway. It's a possible reason that Florian might not want to accept the patch, but that doesn't mean that you should modify or withdraw it -- that's something he can decide. [Knud] Agree, we will keep the locks and let Florian decide to what extend he will include the patch. I'll integrate your new patchset into my build and do a bit more testing; I'm hoping to post my full patch queue in a few days. This will include your patches as well -- I hope you don't mind? (They'll be clearly attributed, of course.) [Knud] That is fully ok. I believe it will just further improve the chances for getting the patches merged into trunk by Florian. Feel free to do any improvements on the patches as well. Just some further thoughts on patch 0010 (deferring the sdo dictionary fetch): one of the interesting things about fsm_slave over fsm_master is that the former can run in parallel while the latter only in series. In principle, this means that if someone issues ethercat sdos with no filters on a large network, the fetch time could be reduced considerably. (It won't reduce the time to that of a single slave, as it has caps on the number of slave FSMs it can run in parallel to prevent blowing out the number of frames and causing latency.) Currently your patch forces this to still run sequentially anyway, because the ioctl is blocking and it only does one slave at a time. I was thinking about having a go at trying to make that change myself, but having said that, given that running ethercat sdos on multiple slaves is not particularly useful (since networks usually contain many duplicates) and that this is generally only used during development or commissioning, I'm not sure whether it's really worth it. [Knud] I agree, it is tempting now to take next step and do this in parallel. It currently requires a patient user to wait several minutes for an ethercat sdos command (with no progress information) to complete. Today we as well only fetch the dictionary for debug and test purposes so we do not plan to further improve this for the moment. I was also wondering if it should do a more limited dictionary fetch by default (just of the PDOs), which could improve some of the logging, but even then those messages only appear when the debug level is increased, so most of the time it wouldn't be all that useful. And someone can just look at the slave docs (or a local dictionary scan) if they want to interpret logs to find out what a particular SDO entry is called from its index:subindex. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
On 13 February 2015 03:30, quoth Knud Baastrup: I have attached a new set of patches (now by using git format-patch, which also imply that the patch names are given by the commit text). I believe that I have addressed the issues you highlighted in prior mails including the alias support that might be relevant for us as well sometime in the future. Nice! Although there still seem to be some funny things going on with the whitespace, eg. see patch 0013's master/fsm_slave_config.c's second hunk (ec_fsm_slave_config_enter_mbox_sync). The locks that conflicts with RTAI could be removed with a define guard, e.g. re-use the EC_RTDM define already available? They're not conflicts, and I wasn't suggesting any specific changes (as I said, I don't use RTDM myself so I don't really know specifics). It was just a comment to indicate why the master originally didn't do any locking there, and that your original problem *could* theoretically have been solved by doing the locking in the application code instead, as it's only an issue with concurrent realtime tasks, which are likely to need some application-level locking anyway. It's a possible reason that Florian might not want to accept the patch, but that doesn't mean that you should modify or withdraw it -- that's something he can decide. I'll integrate your new patchset into my build and do a bit more testing; I'm hoping to post my full patch queue in a few days. This will include your patches as well -- I hope you don't mind? (They'll be clearly attributed, of course.) Just some further thoughts on patch 0010 (deferring the sdo dictionary fetch): one of the interesting things about fsm_slave over fsm_master is that the former can run in parallel while the latter only in series. In principle, this means that if someone issues ethercat sdos with no filters on a large network, the fetch time could be reduced considerably. (It won't reduce the time to that of a single slave, as it has caps on the number of slave FSMs it can run in parallel to prevent blowing out the number of frames and causing latency.) Currently your patch forces this to still run sequentially anyway, because the ioctl is blocking and it only does one slave at a time. I was thinking about having a go at trying to make that change myself, but having said that, given that running ethercat sdos on multiple slaves is not particularly useful (since networks usually contain many duplicates) and that this is generally only used during development or commissioning, I'm not sure whether it's really worth it. I was also wondering if it should do a more limited dictionary fetch by default (just of the PDOs), which could improve some of the logging, but even then those messages only appear when the debug level is increased, so most of the time it wouldn't be all that useful. And someone can just look at the slave docs (or a local dictionary scan) if they want to interpret logs to find out what a particular SDO entry is called from its index:subindex. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
Thanks Gavin, I was just curious to know if this master configurator were a tool that I did not know about. /Knud -Original Message- From: Gavin Lambert [mailto:gav...@compacsort.com] Sent: 3. februar 2015 08:26 To: Knud Baastrup Cc: etherlab-dev@etherlab.org Subject: RE: [etherlab-dev] Multiple mailbox protocols and other issues On 3 February 2015 20:08, quoth Knud Baastrup: Yes, I decided not to use the alias as matching criteria for the slave data due to the tree points intended use of aliases. Currently we do not use aliases on our modules, but we are planning to introduce this in the near future to prevent that some modules get the wrong configuration if a rack of modules (with same vendor and product code as the following rack) are disconnected due to wire/power break. What do you mean by the master configurator ? Depending on context, either the software that sets up the network layout (assigning aliases, saving persistent parameters, etc), or the person in charge of doing that work for a particular installation. Depending on how your application and network operate, sometimes that's an explicit step, and sometimes it's part of the application. Since I'm a lazy person, when our modules are assigned a serial number during production they get that assigned as their alias as well (although they can also be explicitly assigned a different alias if the network configurator wishes), which simplifies network configuration quite a bit. But then, these are discrete units rather than racks so there's a higher chance they'll get wired in an unexpected order, so I think this provides the best compromise in network flexibility. YMMV. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
On 3 February 2015 13:38, quoth Graeme Foot: Sent: Tuesday, 3 February 2015 13:38 To: Gavin Lambert; 'Knud Baastrup' Cc: etherlab-dev@etherlab.org Subject: RE: [etherlab-dev] Multiple mailbox protocols and other issues From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Gavin Lambert On 2 February 2015 20:18, quoth Knud Baastrup: 16_improved_ethercat_rescan_performance.patch: The SII data and PDOs will now be stored when the EtherCAT master is in its operation phase. The stored SII data and PDOs will be detached from the slaves prior to a scanning and re-attached during the scanning without the need to fetch the SII data and PDOs once again. The SII data and PDOs will however only be stored if the slave have a serial number defined as this serial number will be used when re-attaching the SII data and PDOs. Ooh, thanks for that one. That's one of the performance holes that I was planning on investigating myself soonish. None of my modules seem to have serial numbers (Beckhoff IO and yaskawa amps), or is that a bug that's got a patch? I'm running the original 1.5.2 (+ misc patches). It's not a bug, or really related to the master software at all. It's up to the device manufacturer whether a given device has a serial number or not. In my case they do, but I'm mostly using in-house hardware. Beckhoff modules as a general rule don't seem to have serial numbers. This is separate from the alias which is used in network addressing and is typically (but optionally) set by the network designer via the master configurator. The EtherLab master lacks specific commands to set aliases but it can recognise aliases set by other masters, and some slaves support a CoE download to reconfigure their alias (which can be accessed via the command line), and some others have dipswitches. Generally aliases are only needed at tree points in the network graph, so if you're only using simple chains they're less useful. Technically the serial number can be altered by the master / network designer as well via an EEPROM download, but this is less encouraged. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Gavin Lambert On 2 February 2015 20:18, quoth Knud Baastrup: 16_improved_ethercat_rescan_performance.patch: The SII data and PDOs will now be stored when the EtherCAT master is in its operation phase. The stored SII data and PDOs will be detached from the slaves prior to a scanning and re-attached during the scanning without the need to fetch the SII data and PDOs once again. The SII data and PDOs will however only be stored if the slave have a serial number defined as this serial number will be used when re-attaching the SII data and PDOs. Ooh, thanks for that one. That's one of the performance holes that I was planning on investigating myself soonish. Hi, None of my modules seem to have serial numbers (Beckhoff IO and yaskawa amps), or is that a bug that's got a patch? I'm running the original 1.5.2 (+ misc patches). G. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
On 2 February 2015 20:18, quoth Knud Baastrup: 16_improved_ethercat_rescan_performance.patch: The SII data and PDOs will now be stored when the EtherCAT master is in its operation phase. The stored SII data and PDOs will be detached from the slaves prior to a scanning and re-attached during the scanning without the need to fetch the SII data and PDOs once again. The SII data and PDOs will however only be stored if the slave have a serial number defined as this serial number will be used when re-attaching the SII data and PDOs. Ooh, thanks for that one. That's one of the performance holes that I was planning on investigating myself soonish. (A somewhat related one is that when a slave drops to SAFEOP+ERROR as a result of a comms watchdog error, it *should* be safe for the master to bring it straight up to OP, especially when the slave has a serial and can be unambiguously identified, but currently it's doing a full back-to-PREOP reconfigure.) I've been meaning to post the full patchset that I'm using at the moment (in the hopes that a few pieces at least can get integrated), but I'm still investigating a few issues (and working on unrelated things), so it's not quite ready yet. Although (at least partly due to inertia) I'm currently using Frank's mailbox patches rather than yours. :) ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
On 3 February 2015 20:08, quoth Knud Baastrup: Yes, I decided not to use the alias as matching criteria for the slave data due to the tree points intended use of aliases. Currently we do not use aliases on our modules, but we are planning to introduce this in the near future to prevent that some modules get the wrong configuration if a rack of modules (with same vendor and product code as the following rack) are disconnected due to wire/power break. What do you mean by the master configurator ? Depending on context, either the software that sets up the network layout (assigning aliases, saving persistent parameters, etc), or the person in charge of doing that work for a particular installation. Depending on how your application and network operate, sometimes that's an explicit step, and sometimes it's part of the application. Since I'm a lazy person, when our modules are assigned a serial number during production they get that assigned as their alias as well (although they can also be explicitly assigned a different alias if the network configurator wishes), which simplifies network configuration quite a bit. But then, these are discrete units rather than racks so there's a higher chance they'll get wired in an unexpected order, so I think this provides the best compromise in network flexibility. YMMV. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
Yes, I decided not to use the alias as matching criteria for the slave data due to the tree points intended use of aliases. Currently we do not use aliases on our modules, but we are planning to introduce this in the near future to prevent that some modules get the wrong configuration if a rack of modules (with same vendor and product code as the following rack) are disconnected due to wire/power break. What do you mean by the master configurator ? BR, Knud -Original Message- From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Gavin Lambert Sent: 3. februar 2015 02:00 To: 'Graeme Foot' Cc: etherlab-dev@etherlab.org Subject: Re: [etherlab-dev] Multiple mailbox protocols and other issues On 3 February 2015 13:38, quoth Graeme Foot: Sent: Tuesday, 3 February 2015 13:38 To: Gavin Lambert; 'Knud Baastrup' Cc: etherlab-dev@etherlab.org Subject: RE: [etherlab-dev] Multiple mailbox protocols and other issues From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Gavin Lambert On 2 February 2015 20:18, quoth Knud Baastrup: 16_improved_ethercat_rescan_performance.patch: The SII data and PDOs will now be stored when the EtherCAT master is in its operation phase. The stored SII data and PDOs will be detached from the slaves prior to a scanning and re-attached during the scanning without the need to fetch the SII data and PDOs once again. The SII data and PDOs will however only be stored if the slave have a serial number defined as this serial number will be used when re-attaching the SII data and PDOs. Ooh, thanks for that one. That's one of the performance holes that I was planning on investigating myself soonish. None of my modules seem to have serial numbers (Beckhoff IO and yaskawa amps), or is that a bug that's got a patch? I'm running the original 1.5.2 (+ misc patches). It's not a bug, or really related to the master software at all. It's up to the device manufacturer whether a given device has a serial number or not. In my case they do, but I'm mostly using in-house hardware. Beckhoff modules as a general rule don't seem to have serial numbers. This is separate from the alias which is used in network addressing and is typically (but optionally) set by the network designer via the master configurator. The EtherLab master lacks specific commands to set aliases but it can recognise aliases set by other masters, and some slaves support a CoE download to reconfigure their alias (which can be accessed via the command line), and some others have dipswitches. Generally aliases are only needed at tree points in the network graph, so if you're only using simple chains they're less useful. Technically the serial number can be altered by the master / network designer as well via an EEPROM download, but this is less encouraged. ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
Re: [etherlab-dev] Multiple mailbox protocols and other issues
Hello Kund, On Thu, Jul 10, 2014 at 02:04:20PM +, Knud Baastrup wrote: I have attached the complete list of patches that we use for our IgH EtherCAT master: thanks you very much. I will inspect them and come back to you. -- Best regards, Florian Pose http://etherlab.org ___ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
