[etherlab-users] etherlab-users Digest, Vol 53, Issue 15
Jeff Krasky
jeff.krasky at dspcg.com
Thu Oct 20 16:59:21 CEST 2011
> Ok. I can reduce the cycle time. For example make it 10 times faster. This
> way, since my hardware doesn't have data this fast, I would wake up in
> period 1, send request and sleep, wake up in period 2, receive and
process,
> sleep all the periods 3 to 10.
Why sleep all that time? Your complaint was that (before reducing cycle
time by 10) you have too much idle time. So after reducing cycle time by a
factor of 10, if new data is available at cycle 4, read it and process it!
> You see, the thing is, if you know the packet will arrive after let's say
> 4ms (regardless of how fast the hardware generates data), then yeah, you
> can send, sleep 4ms, receive process and wait period. But how do you find
> that 4ms?
If you don't know that, then an isochronous sync protocol is not the
solution for you. Again, EtherCAT probably isn't what you want. However,
if you have equipment that you know can generate data in specific timing
intervals, then you indeed can use an isochronous sync protocol.
> What I'm saying is, you tell me to reduce the cycle time, I won't have a
> problem with that, but how do you know how much to reduce it if you can't
> measure the turnaround time?
Again, it sounds like the nature of your problem is not something that
EtherCAT, or any other isochronous sync protocol, is designed to solve.
More information about the Etherlab-users
mailing list