Re: silly ravenscar question

[jan.de.kruyf@gmail.com]

Here is something for your poster wall, (I will digest ypour writing later)


"In case of discrepancy, you must ignore what they ask for
and give what they need, ignore what they would like and
tell them what they don't want to hear but need to know."
-- E.W. Dijkstra




On Thursday, February 26, 2015 at 11:47:31 AM UTC+2, Dmitry A. Kazakov wrote:


> > On Wednesday, February 25, 2015 at 7:55:59 PM UTC+2, Dmitry A. Kazakov wrote:
> > 
> >> 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?
> 
> i7, I don't remember the frequency, some average CPU and motherboard. BTW,
> a high end motherboard may turn actually slower in terms of latencies. As
> for the network topology it was an industrial-grade one, a cross-over cable
> (:-)).
> 
> [ Switches we measured imposed latencies somewhere between 6 and 15
> microseconds. ]
> 
> > 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.
> 
> I never worked with it, but from the short description I read, looks like
> they try to mimic CANOpen-nonsense and have master/slave architecture. Not
> good.
> 
> We are using a proprietary TCP/IP based protocol (LabNet) for distribution
> between the nodes.
> 
> It is a design question about the field bus network topology, in particular
> switch vs. chained nodes (like in EtherCAT). Real-time crowd will try to
> convince us that the only way is chained nodes, but I honestly believe that
> normal networks will eventually win.
> 
> >> 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.
> 
> OK. However, it is not much an issue to reduce latencies in time
> synchronization as to actually to use it to compensate clock drift (not
> necessarily by tuning the clocks) in order to allow the subscriber to get
> data stamped by the *subscriber's* clock. The problem with actual protocols
> is that they do it by the *publishe's* clock.
> 
> 0.005ms accuracy of clocks shift estimation is achievable using normal
> network stack. The best ADC we ever had had 0.040ms conversion time. So it
> need not to be hardware clock synchronization, but nice to have, of course.
> 
> > Otherwise I do not see great problems getting your data collection issue
> > sorted out.
> 
> Yes. But you know, once you give customers 8 10kHz channels they start
> looking forward 16 channels... (:-))
> 
> > 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.
> 
> Maybe, but we must keep a big picture. It does not make sense to sacrifice
> for making latencies 50% shorter. Latencies are not the issue most of the
> time, though customers will always tell you otherwise. They lie. The real
> problem is having it configurable, scalable, usable.
> 
> > But then there is still the digesting of the data. Do you plan to store a
> > sample in memory for some time?
> 
> Usually data are stored away to be analyzed later. Typically it is a
> data-logger which continuously writes a log file. Another subscriber to the
> data is the HMI, which may render some curves. Yet another is a health
> monitoring subsystem etc.
> 
> > any hardrive activity will most likely bug
> > the cycle response,
> 
> Not really. The architecture is usually such that the controlling unit is
> physically separate from the logger, or the HMI. E.g. consider an EtherCAT
> installation. There is a controller (an industrial PC) running Linux or
> VxWorks with an EtherCAT master. It does all real-time work. It also
> samples the high-speed channels and publishes them over the middleware. The
> data logger is another PC which subscribes to it.
> 
> But there would be no problem to use a hard drive because the control
> cycles are 1-10ms. At least in the application area I am working in, there
> is no processes requiring control under 1ms. Any normal PC can do that.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de