[etherlab-users] Knowing when the packet has finished cycle

[Shahbaz Yousefi]

Hi Jun,

Yes we are, it is called Roboskin <http://www.roboskin.eu/>. I am a
finished-master-soon-to-be-PhD student in MacLab, DIST in University of
Genova. If you ever passed by here, you can meet the whole group (well one
of the partners of the project).

And again yes, this feature is needed, to dynamically detect delay of the
network, or at the very least, just in an initial phase for
self-calibration to be done. Good to know you agree with us. Now just to
get Richard convinced too... ;)

On Wed, Dec 14, 2011 at 10:03 PM, Jun Yuan <j.yuan at rtleaders.com> wrote:

> Hi Shahbaz,
>
> you're developing some kind of robot skin? We must meet someday. I'm a PhD
> student in Robotics And Embedded Systems Group at TUM.
>
> I thought it was a EtherCAT project in industrial plant, so you can just
> configure it and go. Now I understand your situation. The user will change
> the network, and the cycle time needs to adapt with the new network
> automatically to optimize the delay.
>
> Alright, you've convinced me. I'm with you now. I think it's better to
> have such a feature. Otherwise you'll need that formula.
>
>
> Best Regards,
>
> Jun
>
>
> On Wed, Dec 14, 2011 at 3:43 PM, Shahbaz Yousefi <shabbyx at gmail.com>wrote:
>
>> Hi Jun,
>>
>> There is a fundamental problem here. There is no way to find out the
>> value 5ms! Yes, with our formula, our guesses and some measures, we think
>> it should be 5ms, but we can't be sure. If it were so, then of course, wait
>> 6ms and everything is perfect. Another reason we cannot hardcode a value
>> (if not knowing the value is not enough!!) is that the user of the skin
>> (yes, we are creating a skin) might just add another piece of skin to the
>> network, increasing the delay. So, the delay may increase, skin would fail,
>> no tactile data, and the robot might just crush your hand shaking hands
>> with you.
>>
>> I did indeed think about extending the master with this feature, but
>> there is one thing holding me back. In fact, I would be happy if you (or
>> Richard) would answer this question. Imagine you have a big domain for
>> which each *ecrt_master_send* would require splitting its data into
>> different packets. Now, if you, by shear bad luck, do an *
>> ecrt_master_receive* while only half of the packets have arrived, what
>> happens? I mean, the fact that master thinks something went wrong I can fix
>> in the master code, but would receiving another time after that make
>> everything correct? Or would those half of packets be thrown away and
>> therefore another read would again cause an error?
>>
>> I'm not sure if I'm being clear so let me go with a simple example.
>> Imagine your domain is big and so each *ecrt_master_send* needs to send
>> 10 packets. The delay is 2ms. Now exactly 2ms after, you issue an *
>> ecrt_master_receive*. At this time, 4 packets have arrived, the 5th is
>> being read and 5 others are on the way. If you issue an *
>> ecrt_master_receive*, the master gives you an error. Fine. Now if you
>> see that error, wait 1ms more so that all the remaining packets arrive,
>> would *ecrt_master_receive* work correctly?
>>
>> Regards,
>> Shahbaz
>>
>>
>> By the way, it's a waste of bandwidth if the have different cycle times.
>> So if one type of sensor produces data at 1000hz and the other at 100hz,
>> then we do split them in two, but all the 1000hz ones would be in one
>> domain and all the 100hz ones in the other.
>>
> sorry, I don't follow you. Why is that a waste of bandwidth?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20111215/5a0c6039/attachment-0005.htm>