Re: silly ravenscar question

[jan.de.kruyf@gmail.com]

On Friday, February 27, 2015 at 10:58:30 AM UTC+2, Dmitry A. Kazakov wrote:

> But TCP/IP is more flexible. Furthermore, 1Gbaud Ethernet is fast enough to
> outperform anything we could do at the nodes. It is not the bottleneck, so
> far. E.g. practically all field bus couplers are 100Kbaud. You will easily
> beat them with TCP/IP + NO_DELAY by going 1GBaud.

Yes, on bigger systems, but on cheap and not so nasty embedded stuff we might still have 100M ethernet for a while. So I do see the need still to limit my verbosity in the software (and in the frame size). Otherwise I will be back at the bandwidth you quoted from the measurements you did.

> 
> Right, but the problem is that in most cases the terminals run some
> asynchronous tasks which must be time stamped. For this they would use
> internal counters and you have the problem of translation these counters
> into the master clock and then into the PC clock. This is what does not
> work in EtherCAT.
> 
> Consider as an example an analogue input. You should be able to latch the
> clock at the end of a conversion and convert it into the PC clock. This
> would be "free run" mode.
> 
> As another example take a synchronous case with triggered AD conversions in
> multiple terminals. This does not work with EtherCAT either. It only looks
> synchronous, because you need to distribute the trigger signal to all
> terminals. Since the signal's frame arrives at the terminals with different
> latencies you must have time stamp (of some near future) in it. So, in
> fact, this is also asynchronous.
> 

I seem to smell some contradiction in you reasoning but nevermind that.
(I am a bit tired) 
On my side of things I need perfectly synchronized slaves for fast motion control. The hard real time is less important, so that is how I got to my last opinion.
then if I am ever in a position that I have to split the work over 2 pc's (and that might be closer as what I wish) I might just be very pleased when both the slave groups have the same sense of time.
On your side you need to be able to stamp your measurements with hard real time I understand. Or at least deduct the hard real time in some way.

So I did some more research on the ieee protocol, it looks as if it can handle it without a great investment in design time, etc.
There are 2 good linux stacks around, together with a hardware-time-stamping network card it would work well to sync the whole caboudle to hard real time. And in the case the master drops, one of the other boxes in the network becomes master. There can be some voting process every now and again.

>
> Yes, though to keep it balanced, one still could argue that the switch is
> the new weak point then, and that wiring is more complicated. Nevertheless
> star topology will win as it did when going from 10BNC to twisted pair.

Probably double the wiring cost. That is a great killer with the junior project managers. (my son is one, so I hear these noises on and off) 
I do not feel that a switch is a weak point. Only if you try to get away with office quality RJ45 without bolting down the cables right next to the switch, as you aught to do in any case, for grounding purposes.

> 
> If it consistently manipulates all time sources on the board, then OK. From
> our experience, it is better to leave clocks alone (and have no problem
> with negative adjustments) and only translate time stamps.

Before I got deeply into this fieldbus thing I set up a small model on the laptop to demonstrate some motordriver idea. I did have a jitter averaging design in there that worked quite well. It was basically the same as what is in the ieee circuitry in the STM controller. It works as a PI controller on the drift correction. Except my algorithm locked a lot faster than basic PI.

But that I did on the basis of a sync pulse every scan period like powerlink.
Ettercat has not got that I believe.
In any case that still only gives network time that then  must be translated for data gathering.

So with ieee you slowly walk past all stations once every 2 seconds or even slower and measure the cable delay. and add or subtract 1 bit to/from the drift register as needed. that is, as soon as the course time correction has been determined.


> M = mega? Wow!

Yes, but in my experience you might have to stop the processor clock for a bit while you measure. Especially on cheap 2 layer boards.

cheers, and thanks for your time. I highly appreciate your feedback.

j.