Re: silly ravenscar question

[jan.de.kruyf@gmail.com]

On Wednesday, February 25, 2015 at 7:55:59 PM UTC+2, Dmitry A. Kazakov wrote:


> 
> Normally, high-speed channels are not used for control, it means that we
> don't need to react each 0.1ms, but we must catch each value, stamp it and
> pass further, e.g. to the data logger or to the software oscilloscope.
> 
> > in any case to focus the thinking, I did some quick sums:
> > A packet with a payload of 50 bytes, according to the theory should be
> > able to do the roundtrip (100 m cable, 1 switchbox, no packet contention)
> > in 25 usecs through an stm34 board, with time to spare. that includes DMA
> > and offloading and onloading of data.
> 
> > So that makes 40 packets per msec. Leave some space for syncframes, arp
> > frames and data loss, then 20 roundtrip packets /msec should be doable,
> > provided the jitter is strictly controlled. 
> > An individual terminal has all the time in the world to handle the data
> > between commframes, but I bet that, depending on what you want out of the
> > system, the pc might feel the strain at that rate. (and the rt scheme must
> > be up to scratch in the pc)
> 
> We managed 0.2ms with 4 channels without oversampling, transported over XCP
> under VxWorks. XCP is a UDP-based protocol. The data were coalesced into
> one frame.
> 

what processor, what clockspeed, what net topology?
But it is probably as good as it gets with prefab software. 
openPowerlink was reported to have a latency up to 450usecs Sync to 1st. Response between 2 VIA Nehemiah processors running at 1GHz with linux-RT. The main reason I dropped it. Off course modern boards are better, but I also have to deal with STM running at 168MHz


> 
> This is one case when you trade latencies for throughout. In other cases
> latencies are more important, e.g. for control and for time
> synchronization. The latter is the weakest spot of all existing field
> buses. Most of them do not have any, others have a garbage clock
> synchronization, like EtherCAT's distributed clock is.
> 

STM implements the hardware for Precision time protocol IEEE1588 PTP.
So its up to me to implement the software properly. It promises precision in the sub usec range. Personally I think its quite doable, provided the latency from packet arrival through software has little or no jitter.

Otherwise I do not see great problems getting your data collection issue sorted out. But we might forgo on CAN and the like until we really need it (i.e at the interfacing with the data-digesting software.

The numbers I gave you are definitely squeezable, that was just a budget.
The pc side is another kettle of fish though. There is a software stack around that promises things like 10usec cycletime on RTAI but there is no indication of the packet size or the net topology. 
But then there is still the digesting of the data. Do you plan to store a sample in memory for some time? any hardrive activity will most likely bug the cycle response, unless you have a dual port plugin that does nothing but comms
and temp storage, until it can get DMA'ed to the main board.

Ok time for some real work,
cheers,

j.