Re: silly ravenscar question

[jan.de.kruyf@gmail.com]

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


> 
> [ Switches we measured imposed latencies somewhere between 6 and 15
> microseconds. ]
> 

found some HP boxes with a guaranteed latency, and it has a spy connector
all at reasonable price.

> 
> 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.

dont. it makes your eyes go squint when you try to read the code.

> 
> We are using a proprietary TCP/IP based protocol (LabNet) for distribution
> between the nodes.

is not -fast-
bare E-frames is better, i would think. Just repeat the poll/response cycle when no good data arrives. And 3 tries is death. (or whatever)

> 
> 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.

How do you do IEEE1588 ? this way around the loop or that way?
The whole scheme becomes dependent on the jitter tolerance of the pc because the pc is part of the delay loop. Nah!
while if one of the outstations takes the syncer role then the pc can be as floppy as it likes, we dont care. It will only show up in the inter-poll gaps.
But the terminals all run in perfect step and have one sense of time.

So yes, I am agnostic as far as the software writing goes. The changes are not very big, And yes more traffic is possible, because there is less cruft. But it involves non standard hardware with 2 phys or a 3way phy.
(STM will deal graciously with either that is not the point.) And the timing will be less acurate. 
Further when 1 station is down its is a major upheaval, if you look carefully at an etherCAT mac / phy you will know why. And that structure is not readily emulated.
While in a star one can unplug a box, which then will be declared dead by the software, until the time that a new box announces itself.

The pc does get offloaded a bit. less cruft in the frames to throw away, But there are many ways to kill a mocking bird.
I just realized to my horror that using a STM terminal connected through ---- just wait for it --- a parallel card handles the data load easily and acts like a beautiful buffer. and the system will for sure have less jitter, so can handle more outstations. Crazy hey. (Dont try to sell this to the RT guys) But then again a micro controller connected via a pci interface on a plugin card at E400.- will please everybody mightily, and it might do the same job.


> 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.

Your wishes have been fulfilled, there is drift correction incorporated in the hardware, that is controlled via software from IEEE1588.

>
> The best ADC we ever had had 0.040ms conversion time.

Those were wonderful ADC's then. but now how about this:
 ADC conversion rate with 12 bit resolution is up to:
     2.4 M.sample/s in single ADC mode,
     4.5 M.sample/s in dual interleaved ADC mode,
     7.2 M.sample/s in triple interleaved ADC mode.

24 channels split over 3 ADC's (that is where the 'triple interleaved' comes in)

Nice hey, we might do a bit of oversampling now to get the accuracy right.

> 
> Yes. But you know, once you give customers 8 10kHz channels they start
> looking forward 16 channels... (:-))

its there, just don't sell it all at once. my uncle would say: "Remember the Philips shaver. They full well knew they were eventually going to make a 3 headed one." (back in 1950 or so, when they still made them with 1 head)

> 
> 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.

Tell me more . . .
(And remember old Miesel, Dijkstra. I dont know if you have read any of his notes, all written in beautiful long-hand, and all about computer science.
But customer relations was not one of his fortes.)

> 
> 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.
> 

Ok, so we dont need a parallel port, he, I was sweating already. . . .


cheers,

j.