Mere moments ago, quoth I: > Did you see my other patch specifically for FoE busy? My slave is > working fine for busy reads with both of my patches applied. (There was > a third patch included in the same email as the busy patch, but that's > optional and just increases debug logging.) > > My patch also fixes handling of error packets.
These are at http://lists.etherlab.org/pipermail/etherlab-dev/2013/000324.html, if you're having trouble finding it. > As for incrementing the packet number or not, it's been a while since I > looked at that so I don't remember whether it increments or not with my > patches applied, but I think I remember making it do whatever the SSC > was expecting. I had a quick look at my SSC patches, so now I think I remember -- my version would continue incrementing the packet number (which is partly why I ran into the 256 packet limit that prompted the other patch). You're correct that ETG.1020 indicates that the packet number should not be increasing though; I missed that part. (It worries me a bit when both master AND slave code have to be changed to make something fundamental like this work, and it makes me wonder about existing devices -- but I guess FoE read is not implemented all that often.) One of us should probably make a combined patch set that fixes all three issues, for ease of future players (and maybe even merging, one of these days). I'll probably get to it in a few days when I (hopefully) get back to EtherCAT-related work, if you don't beat me to it. :) _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev