TCP/UDP for deterministic safety system - TCP-IP

This is a discussion on TCP/UDP for deterministic safety system - TCP-IP ; Albert Manfredi wrote: > No, I don't think that's the case. A late collision could possibly > occur at one port of a switch, e.g. if that port is set to half duplex > and connected to an excessively long ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 35 of 35

Thread: TCP/UDP for deterministic safety system

  1. Re: TCP/UDP for deterministic safety system

    Albert Manfredi wrote:

    > No, I don't think that's the case. A late collision could possibly
    > occur at one port of a switch, e.g. if that port is set to half duplex
    > and connected to an excessively long a series of hubs. Or if that port
    > is set to half duplex and the Ethernet segment of that port is way too
    > long (could occur in 100BASE-TX). However, across the switch to
    > another port, there can be no danger of late collisions.


    A switch *tries* to do this and usually can and does do this. But it
    cannot guarantee that it does this. So you cannot rely on it doing
    this.

    For example, suppose you have ten chained switches. Assume half-
    duplex, 100Mbps on all ports. Assume all the downstream links are
    saturated. Assume cut-through switching.

    The packet gets to the last switch-to-switch link. The downstream port
    is saturated, and the switch elects to propagate a collision up the
    chain. Assume each switch likewise is out of buffer space and also
    elects to propagate a collision up the chain. If the collision reaches
    the first sender *AFTER* it has finished sending the packet, the
    packet is lost.

    The collision can, in fact, occur later and later on ports closer and
    closer to the originator.

    Switches try, as an optimization, to limit the propagation of
    collisions. But a generic switch does not guarantee any particular
    level of isolation. This is the same as how switches try to limit the
    propagation of unicast frames.

    > The switch
    > isolates the domains between ports, assuming we all agree that
    > "switch" means "layer 2 bridge," and is not some random name given to
    > any type of fan-out device.


    No, it does not. It tries to when it can, as an optimization. It
    cannot be relied upon to do so, unless you know the specific
    characteristics of a specific switch. A switch per-se is not
    guaranteed to do this. The topology rules have to assume the worst
    case for every device and every link. (And as a result, you can often
    violate them significantly with no harm at all, because real hardware
    is usually not worst case hardware.)

    DS

  2. Re: TCP/UDP for deterministic safety system

    On Aug 9, 7:46*pm, David Schwartz wrote:

    > A switch *tries* to do this and usually can and does do this. But it
    > cannot guarantee that it does this. So you cannot rely on it doing
    > this.
    >
    > For example, suppose you have ten chained switches. Assume half-
    > duplex, 100Mbps on all ports. Assume all the downstream links are
    > saturated. Assume cut-through switching.
    >
    > The packet gets to the last switch-to-switch link. The downstream port
    > is saturated, and the switch elects to propagate a collision up the
    > chain. Assume each switch likewise is out of buffer space and also
    > elects to propagate a collision up the chain. If the collision reaches
    > the first sender *AFTER* it has finished sending the packet, the
    > packet is lost.


    Okay, I agree that when all switch ports in a source-sink path are set
    to half duplex and the system is fully saturated, you will have this
    "collision" propagated upstream, to try to get the source to hold off.
    But this *should* never result in a late colision or any such
    weirdness (assuming the individual link lengths are within spec),
    because what is actually being propagated upstream is a local PAUSE
    command based on a purely local decision by the switch.

    > The collision can, in fact, occur later and later on ports closer and
    > closer to the originator.


    In a properly designed switch, that should never happen. The
    "collision" being signaled upstream from a given port should only be
    the result of a local queue at THAT switch, or perhaps even at that
    switch PORT, having exceeded a certain level. And that threshold level
    is less than 100 percent, or you will be dropping frames occasionally.
    The switch should not be making the decision on sending the
    "collision" signal, actually a PAUSE command, based on what's
    happening several switches downstream. That's why late collisions
    should never be an issue with bridges (switches).

    Bert

  3. Re: TCP/UDP for deterministic safety system

    On Aug 9, 5:54*pm, tns1 wrote:

    > Yes, just one packet in flight. The RS485 network uses a shared medium -
    > one twisted pair for both tx&rx traffic. All traffic uses the same
    > modulation - NRZ, so half-duplex is a real physical restriction even
    > with only one host and one slave. If I understand it, 'baseT always uses
    > separate twisted pairs for tx&rx, even in half-duplex mode.


    Yes, however in half duplex mode, the "BASE-T" standards all emulate
    the operation of a coax, single-medium Ethernet. So even though the Tx
    and Rx are separate wire pairs, they cannot be used to send data
    traffic simultaneously in both directions. If set to full duplex, then
    you can simutaneously transmit and receive. In your case, you can use
    either scheme. Since the slaves cannot talk unless told to, and since
    we are using UDP/IP, there should never be a case of simutaneous up
    and down traffic.

    > This brings up some questions on possible wiring.
    > If using a shared utp medium will actually work for me and still let me
    > use UDP/IP, then my first thought was I would wire it so that all slave
    > transmitters tap directly onto the master receiver twisted pair, and
    > visa-versa for the master transmitter pair. Wired like this, slaves
    > can't 'read' each other's transmissions, and could never talk to one
    > another directly. Packets could still collide if the slaves did not obey
    > the protocol rule, "speak only when you are spoken to".


    Well, you especially cannot wire the transmitters of multiple hosts in
    parallel, in a BASE-T system. The reason is simple enough. The
    transmitters are low impedance. If you attempt to parallel multiple
    transmitters together, so all reach the master on the same twisted
    pair, then you will in essence be shorting out all of them.

    But if you use Ethernet "hubs" rather than switches, what you describe
    above would be the way the system would work. The command from the
    master would reach every slave, and the reply from any slave would
    reach all other slaves as well as the master.

    But these Ethernet hubs, i.e. repeaters, are not sold much anymore.
    Maybe on ebay, if you insist. Instead now you would use "learning
    bridges," or switches. So the command from the master will
    (eventually) only be propagated to the intended slave. It won't be
    flooded to all slaves. Similarly, the reply from the slaves will only
    be propagated to the master. Because the switches "learn" which MAC
    addresses are resident at which switch ports, and they only forward
    frames where they think they are actually wanted.

    > This is one difference in the single pair RS485 network since everyone
    > sees everyone else's transmissions. I think an ethernet PHY could be
    > wired up just like this using a single pair. I don't see any advantage,
    > but it would still work wouldn't it?


    It won't work right, and I also don't see any advantage. I'd always
    follow the standards, unless there's some sort of "in extremis"
    situation.

    > The alternative to this is like I originally proposed where each
    > upstream/downstream port has its own active MAC/PHY. Cost and complexity
    > is greater, so I wouldn't do this unless I had to. When would I have to?


    This is the only way to go, using a switch, or more than one if
    necessary, as fan-out. Cost and complexity are minimal. Switches are
    very cheap these days, especially those that are not managed. we're
    talking 10s of dollars here. And no one has to make up any special
    cable with paralleled Tx pairs.

    Bert

  4. Re: TCP/UDP for deterministic safety system

    On Aug 10, 3:01*pm, Albert Manfredi wrote:

    > > The collision can, in fact, occur later and later on ports closer and
    > > closer to the originator.


    > In a properly designed switch, that should never happen. The
    > "collision" being signaled upstream from a given port should only be
    > the result of a local queue at THAT switch, or perhaps even at that
    > switch PORT, having exceeded a certain level. And that threshold level
    > is less than 100 percent, or you will be dropping frames occasionally.
    > The switch should not be making the decision on sending the
    > "collision" signal, actually a PAUSE command, based on what's
    > happening several switches downstream. That's why late collisions
    > should never be an issue with bridges (switches).


    If a switch detects a collision on one of its output ports, and it's
    using cut-through switching, one of the things it can do is elect to
    propagate that collision on the input port. What do you think will
    happen if the first collision on the last switch occurs after the
    first switch has completely finished sending the packet?

    DS

  5. Re: TCP/UDP for deterministic safety system

    On Aug 10, 6:43*pm, David Schwartz wrote:

    > If a switch detects a collision on one of its output ports, and it's
    > using cut-through switching, one of the things it can do is elect to
    > propagate that collision on the input port.


    To the extent that cut-through switches are even relevant anymore,
    they used to only allow cut-through under specific circumstances. One
    example, the obvious one, was that cut-through was never used if the
    in and out ports were running at different speeds. Another limit
    SHOULD have been that cut-through would not be used if the buffer at
    that port had anything in it. You can't do cut-through if there's even
    one frame sitting there, waiting. And a switch without a buffer is not
    a switch. It's a repeater (hub).

    > What do you think will
    > happen if the first collision on the last switch occurs after the
    > first switch has completely finished sending the packet?


    Nothing.

    Assume the first collision to occur on the last switch-host link. It
    tells that last switch to hold off. This might occur if there are
    several hosts on that last Ethernet segment, connected together with a
    hub, for example.

    That last switch continues to accept frames, but loads them in a
    buffer (no cut-though allowed here). When that buffer has reached
    (e.g.) 80 percent of capacity, that last switch signals upstream. Stop
    sending. If using PAUSE commands, a couple more frames will trickle
    down. If using a "collision" signal, the flow should stop immediately.
    The second to last switch goes through exactly that same process. When
    80 percent full, it signals upstream.

    And so on. So each upstream switch is still accepting frames intially,
    when the last switch first stops forwarding.

    Eventually, the first switch in the path stops accepting new frames,
    by signaling a "collision" to the source host. If the host at the sink
    end is still not able to accept frames, you'll have a bunch of almost-
    full buffers down the line.

    In practice, this probably won't happen. In practice, if there are
    many switches in the path, the downstream switches will probably get
    their buffers unloaded before the first switch has to shut off the
    source host.

    Bert

  6. Re: TCP/UDP for deterministic safety system

    On Aug 10, 6:43*pm, David Schwartz wrote:

    > If a switch detects a collision on one of its output ports, and it's
    > using cut-through switching, one of the things it can do is elect to
    > propagate that collision on the input port. What do you think will
    > happen if the first collision on the last switch occurs after the
    > first switch has completely finished sending the packet?


    A switch (bridge) should never do that, if it's designed correctly.
    I'm not saying that SOME cut-through switches might not have operated
    that way, I just don't know that. But I am saying that it would be
    plain wrong.

    What you are describing is exactly how a hub (repeater) operates.
    That's why hubs have a limit of 4 concatenated in an Ethernet. What
    makes a bridge a bridge is that it isolates the L2 domains on either
    side. This also holds for cut-through switches.

    But in any event, all of this is creating noise in the circuit. What
    the OP was asking is eminently doable. Cut-through switches are
    virtually extinct. And improperly designed cut-through switches are
    mostly an interesting academic discussion, but not a credible
    deterrent to what the OP was wanting to do, IMO.

    Bert

  7. Re: TCP/UDP for deterministic safety system

    Albert Manfredi wrote:
    > On Aug 9, 5:54 pm, tns1 wrote:
    >
    >> Yes, just one packet in flight. The RS485 network uses a shared medium -
    >> one twisted pair for both tx&rx traffic. All traffic uses the same
    >> modulation - NRZ, so half-duplex is a real physical restriction even
    >> with only one host and one slave. If I understand it, 'baseT always uses
    >> separate twisted pairs for tx&rx, even in half-duplex mode.

    >
    > Yes, however in half duplex mode, the "BASE-T" standards all emulate
    > the operation of a coax, single-medium Ethernet. So even though the Tx
    > and Rx are separate wire pairs, they cannot be used to send data
    > traffic simultaneously in both directions. If set to full duplex, then
    > you can simutaneously transmit and receive. In your case, you can use
    > either scheme. Since the slaves cannot talk unless told to, and since
    > we are using UDP/IP, there should never be a case of simutaneous up
    > and down traffic.
    >
    >> This brings up some questions on possible wiring.
    >> If using a shared utp medium will actually work for me and still let me
    >> use UDP/IP, then my first thought was I would wire it so that all slave
    >> transmitters tap directly onto the master receiver twisted pair, and
    >> visa-versa for the master transmitter pair. Wired like this, slaves
    >> can't 'read' each other's transmissions, and could never talk to one
    >> another directly. Packets could still collide if the slaves did not obey
    >> the protocol rule, "speak only when you are spoken to".

    >
    > Well, you especially cannot wire the transmitters of multiple hosts in
    > parallel, in a BASE-T system. The reason is simple enough. The
    > transmitters are low impedance. If you attempt to parallel multiple
    > transmitters together, so all reach the master on the same twisted
    > pair, then you will in essence be shorting out all of them.
    >
    > But if you use Ethernet "hubs" rather than switches, what you describe
    > above would be the way the system would work. The command from the
    > master would reach every slave, and the reply from any slave would
    > reach all other slaves as well as the master.
    >
    > But these Ethernet hubs, i.e. repeaters, are not sold much anymore.
    > Maybe on ebay, if you insist. Instead now you would use "learning
    > bridges," or switches. So the command from the master will
    > (eventually) only be propagated to the intended slave. It won't be
    > flooded to all slaves. Similarly, the reply from the slaves will only
    > be propagated to the master. Because the switches "learn" which MAC
    > addresses are resident at which switch ports, and they only forward
    > frames where they think they are actually wanted.
    >
    >> This is one difference in the single pair RS485 network since everyone
    >> sees everyone else's transmissions. I think an ethernet PHY could be
    >> wired up just like this using a single pair. I don't see any advantage,
    >> but it would still work wouldn't it?

    >
    > It won't work right, and I also don't see any advantage. I'd always
    > follow the standards, unless there's some sort of "in extremis"
    > situation.
    >

    OK, so every ethernet node using utp has the low impedance termination
    in place across the pairs and every link is buffered from the next one
    by passing thru a switch/hub/repeater. There is no direct tap. The RS485
    multi-drop network is direct tap. It only has termination at the extreme
    ends of the shared twisted pair, otherwise every node is high-impedance
    when not driving the cable. Sound right?

    >> The alternative to this is like I originally proposed where each
    >> upstream/downstream port has its own active MAC/PHY. Cost and complexity
    >> is greater, so I wouldn't do this unless I had to. When would I have to?

    >
    > This is the only way to go, using a switch, or more than one if
    > necessary, as fan-out. Cost and complexity are minimal. Switches are
    > very cheap these days, especially those that are not managed. we're
    > talking 10s of dollars here. And no one has to make up any special
    > cable with paralleled Tx pairs.
    >

    So in summary, the minimal network would look like so:
    From the master PC to port1 of a 2port switch, from port2 of this
    'master' switch to the upstream port of station1 which consists of: a
    3port switch with upstream, downstream, and local ports. The local port
    connects to the station1 'puter, the downstream port goes to the next
    station in the chain etc...
    Protocol is UDP/IP, possibly using broadcast/multicast for backward
    compatibility with legacy code (the payload itself carries a station ID).

    Since the station is going to include a custom board processor board, it
    could actually incorporate the switch functionality, although there are
    some isolation and safety requirements which may favor using stand-alone
    multi-port switches even though they are mounted inside the station
    enclosure.

    There is additional complexity to this network which I have not
    mentioned yet, but if I can at least nail down these basics it will be a
    great help.












  8. Re: TCP/UDP for deterministic safety system

    On Aug 11, 12:47*pm, tns1 wrote:

    > OK, so every ethernet node using utp has the low impedance termination
    > in place across the pairs and every link is buffered from the next one
    > by passing thru a switch/hub/repeater. There is no direct tap. The RS485
    > multi-drop network is direct tap. It only has termination at the extreme
    > ends of the shared twisted pair, otherwise every node is high-impedance
    > when not driving the cable. Sound right?


    The output impedance of the Ethernet transmitters is low impedance,
    yes. And in RS-485, as you say, the transmitters are basically
    switched out when not actually transmitting.

    > So in summary, the minimal network would look like so:
    > *From the master PC to port1 of a 2port switch, from port2 of this
    > 'master' switch to the upstream port of station1 which consists of: a
    > 3port switch with upstream, downstream, and local ports. The local port
    > connects to the station1 'puter, the downstream port goes to the next
    > station in the chain etc...
    > Protocol is UDP/IP, possibly using broadcast/multicast for backward
    > compatibility with legacy code (the payload itself carries a station ID).


    I don't think there should be anything special about the topology. Can
    you use a star configuration? If not, for cable length considerations,
    then something along the lines of what you're describing should work.
    When all the needed switches are connected together, the switches (if
    so configured) will automatically compute the "cheapest" spanning tree
    in the mesh. Or this can be statically configured. My inclination is
    always to keep the longest path in the spanning tree as short as
    possible.

    > Since the station is going to include a custom board processor board, it
    > could actually incorporate the switch functionality, although there are
    > some isolation and safety requirements which may favor using stand-alone
    > multi-port switches even though they are mounted inside the station
    > enclosure.
    >
    > There is additional complexity to this network which I have not
    > mentioned yet, but if I can at least nail down these basics it will be a
    > great help.- Hide quoted text -


    I don't think you should need one switch for every host. Although if
    you want to eliminate single points of failure, you can create a mesh
    of many switches, interconnected many ways (i.e. a dense mesh), then
    let the RSTP algorithm do its thing to compute the spanning tree, and
    to automatically recover in the event of link or switch failures. This
    is something the switches would do on their own, invisible to your
    system's own protocols. I think that the topology can be made a lot
    more robust than the RS-485 topology was, and that the protocols
    layered on top of this can remain identical to what you had before.

    Bert

  9. Re: TCP/UDP for deterministic safety system

    Albert Manfredi wrote:
    > On Aug 11, 12:47 pm, tns1 wrote:
    >
    >> OK, so every ethernet node using utp has the low impedance termination
    >> in place across the pairs and every link is buffered from the next one
    >> by passing thru a switch/hub/repeater. There is no direct tap. The RS485
    >> multi-drop network is direct tap. It only has termination at the extreme
    >> ends of the shared twisted pair, otherwise every node is high-impedance
    >> when not driving the cable. Sound right?

    >
    > The output impedance of the Ethernet transmitters is low impedance,
    > yes. And in RS-485, as you say, the transmitters are basically
    > switched out when not actually transmitting.
    >
    >> So in summary, the minimal network would look like so:
    >> From the master PC to port1 of a 2port switch, from port2 of this
    >> 'master' switch to the upstream port of station1 which consists of: a
    >> 3port switch with upstream, downstream, and local ports. The local port
    >> connects to the station1 'puter, the downstream port goes to the next
    >> station in the chain etc...
    >> Protocol is UDP/IP, possibly using broadcast/multicast for backward
    >> compatibility with legacy code (the payload itself carries a station ID).

    >
    > I don't think there should be anything special about the topology. Can
    > you use a star configuration? If not, for cable length considerations,
    > then something along the lines of what you're describing should work.
    > When all the needed switches are connected together, the switches (if
    > so configured) will automatically compute the "cheapest" spanning tree
    > in the mesh. Or this can be statically configured. My inclination is
    > always to keep the longest path in the spanning tree as short as
    > possible.
    >
    >> Since the station is going to include a custom board processor board, it
    >> could actually incorporate the switch functionality, although there are
    >> some isolation and safety requirements which may favor using stand-alone
    >> multi-port switches even though they are mounted inside the station
    >> enclosure.
    >>
    >> There is additional complexity to this network which I have not
    >> mentioned yet, but if I can at least nail down these basics it will be a
    >> great help.- Hide quoted text -

    >
    > I don't think you should need one switch for every host. Although if
    > you want to eliminate single points of failure, you can create a mesh
    > of many switches, interconnected many ways (i.e. a dense mesh), then
    > let the RSTP algorithm do its thing to compute the spanning tree, and
    > to automatically recover in the event of link or switch failures. This
    > is something the switches would do on their own, invisible to your
    > system's own protocols. I think that the topology can be made a lot
    > more robust than the RS-485 topology was, and that the protocols
    > layered on top of this can remain identical to what you had before.
    >

    The topology is a key element. See post#1. Certain features of the
    existing high-level protocol will be broken if the system is not
    daisy-chained as I described. It cannot change. The only reason for
    considering ethernet is to gain some connection and protocol standards.
    If I gain some additional robustness that's good too, but secondary. It
    all has to work with the existing topology.

    To see if I'm still on track, let's say I have an extreme case of 30
    stations with switches wired up as I described with 300ft between
    stations. The PC master sends a UDP broadcast to guarantee it doesn't
    get filtered. Does it make it all the way to the end of the line? One
    post says NO, a switch is too smart (or dumb) and will not allow that
    many hops (or flight time), so instead each station is a bridge that
    must either repackage the datagram and resend it, or you need to send
    the data from a low enough stack layer that there is no consideration of
    hops & times. This does not sound like UDP.

    For each station I was hoping to use an embedded processor with a single
    MAC/PHY and some low end switch/hub stuff, but maybe that is out the
    window.







  10. Re: TCP/UDP for deterministic safety system

    On Aug 11, 5:28*pm, tns1 wrote:

    > The topology is a key element. See post#1. Certain features of the
    > existing high-level protocol will be broken if the system is not
    > daisy-chained as I described.


    Can you explain why you think this is the case?

    Let's say you do this the simplest possible way. The entire network is
    built as one IP subnet. Each command message is broadcast, so each
    command message reaches every slave device.

    In the UDP/IP datagram, carried as payload, is exactly the same
    formatted command message you were using before, with the RS-485-style
    address of the intended slave device.

    Each slave device opens the UDP datagram and looks at the payload
    (much like in the RS-485 scheme). When the slave being addressed sees
    its RS-485 address in the payload, it responds with a UDP/IP
    broadcast. The broadcast goes to the master and to all the other
    slaves.

    This is the very simplest way to implement this scheme, and it
    couldn't care less about topology. You could have one switch connected
    to 30 stations and to the master, and it would work just fine. If
    using twisted pair copper, each link is limited to 100 meters, so that
    should be your main consideration. If using fiber optic cable, you can
    go way beyond that limit.

    > To see if I'm still on track, let's say I have an extreme case of 30
    > stations with switches wired up as I described with 300ft between
    > stations. The PC master sends a UDP broadcast to guarantee it doesn't
    > get filtered. Does it make it all the way to the end of the line?


    IP broadcasts MUST go to every host within that IP subnet. Switches
    must flood the broadcasts to all active ports. So yes, the broadcast
    will go to every host.

    If it were an IP multicast instead, each host would have to indicate
    an interest in joining the multicast group, to receive the packets. So
    it adds a little complexity, the IGMP "join" protocol. If this is an
    isolated network used only for this system, IP multicast doesn't
    really add any value.

    Or you can unicast each command to the individual slave only. This is
    probably the best way to update the system. Now you would have to
    change the way the slaves are addressed. You would use the IP address
    of each slave for the master's round robin querying routine. And you
    can eliminate the RS-485 addressing scheme entirely, if you want.

    > For each station I was hoping to use an embedded processor with a single
    > MAC/PHY and some low end switch/hub stuff, but maybe that is out the
    > window


    Each station could certainly consist of a single MAC, and the switches
    you use can be shared among more than one of the stations. The only
    limit there is how long the links will become. You have to remain
    within 100 meters if you're using twisted pair copper.

    But I don't see anything at all to limit the topology to a daisy
    chain.

    Bert

  11. Re: TCP/UDP for deterministic safety system

    On Aug 11, 6:10*pm, Albert Manfredi wrote:

    > If it were an IP multicast instead, each host would have to indicate
    > an interest in joining the multicast group, to receive the packets. So
    > it adds a little complexity, the IGMP "join" protocol. If this is an
    > isolated network used only for this system, IP multicast doesn't
    > really add any value.


    In fact, to make things even simpler, this comment I made is only true
    if you're using "IGMP snooping" switches.

    If not using IGMP snooping switches, then IP multicasts are flooded to
    all active ports of a layer 2 switch, so that would work very much
    like broadcast, in a one-IP-subnet network.

    Bert

  12. Re: TCP/UDP for deterministic safety system

    Albert Manfredi wrote:
    > On Aug 11, 5:28?pm, tns1 wrote:
    > > To see if I'm still on track, let's say I have an extreme case of
    > > 30 stations with switches wired up as I described with 300ft
    > > between stations. The PC master sends a UDP broadcast to guarantee
    > > it doesn't get filtered. Does it make it all the way to the end of
    > > the line?


    > IP broadcasts MUST go to every host within that IP subnet. Switches
    > must flood the broadcasts to all active ports. So yes, the broadcast
    > will go to every host.


    > If it were an IP multicast instead, each host would have to indicate
    > an interest in joining the multicast group, to receive the packets. So
    > it adds a little complexity, the IGMP "join" protocol. If this is an
    > isolated network used only for this system, IP multicast doesn't
    > really add any value.


    I've only been watching cursorily (is that even a word?) but would add
    a slight nit. It might be good to make the distinction between the IP
    broadcast/multicast and the link-layer broadcast/multicast frames
    carrying them.

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  13. Re: TCP/UDP for deterministic safety system

    On Aug 11, 7:20*pm, Rick Jones wrote:

    > I've only been watching cursorily (is that even a word?) but would add
    > a slight nit. *It might be good to make the distinction between the IP
    > broadcast/multicast and the link-layer broadcast/multicast frames
    > carrying them.


    True. Actually, the entire system could in principle function directly
    over Ethernet, no need for any IP and UDP layers on top of that. But
    it's easier to build applications to run over IP.

    Anyway, the so-called "all 1s" IP broadcast maps into an all 1s MAC
    broadcast, so in this case, it should make no difference. Keeping
    everything within a single IP subnet, and using UDP instead of TCP,
    kind of removes any true value added by L3 and L4. That is, unless you
    go to the trouble of using IGMP snooping switches and IP multicast.

    Bert

  14. Re: TCP/UDP for deterministic safety system

    Albert Manfredi wrote:
    > On Aug 11, 5:28 pm, tns1 wrote:
    >
    >> The topology is a key element. See post#1. Certain features of the
    >> existing high-level protocol will be broken if the system is not
    >> daisy-chained as I described.

    >
    > Can you explain why you think this is the case?


    Take your pick: One big reason is to maintain some backward
    compatibility with existing systems. Also Legacy $$$oftware. Also
    ethernet will be just one option in addition to two existing
    daisy-chained comm schemes - a 2nd topology would be extra work. The
    environment is restrictive and a clean,simple install matters - you
    can't just plop down a piece of equipment or route a cable anywhere you
    please. Hooking up and debugging a daisy chain requires almost zero IT
    knowledge and this does not change as it gets longer. These multi-port
    switches you are dreaming about would likely be placed right next to the
    master PC and you would have 30cables to muscle around instead of one.
    The system allows any unit on the chain to isolate all the downstream
    units, and also the 'boot' sequence can be stepped down the chain.

    Now I am no expert on the current system and it may be possible to
    change one or two things on this list, but that's about it.

    >
    > Let's say you do this the simplest possible way. The entire network is
    > built as one IP subnet. Each command message is broadcast, so each
    > command message reaches every slave device.
    >
    > In the UDP/IP datagram, carried as payload, is exactly the same
    > formatted command message you were using before, with the RS-485-style
    > address of the intended slave device.
    >
    > Each slave device opens the UDP datagram and looks at the payload
    > (much like in the RS-485 scheme). When the slave being addressed sees
    > its RS-485 address in the payload, it responds with a UDP/IP
    > broadcast. The broadcast goes to the master and to all the other
    > slaves.
    >
    > This is the very simplest way to implement this scheme, and it
    > couldn't care less about topology. You could have one switch connected
    > to 30 stations and to the master, and it would work just fine. If
    > using twisted pair copper, each link is limited to 100 meters, so that
    > should be your main consideration. If using fiber optic cable, you can
    > go way beyond that limit.
    >
    >> To see if I'm still on track, let's say I have an extreme case of 30
    >> stations with switches wired up as I described with 300ft between
    >> stations. The PC master sends a UDP broadcast to guarantee it doesn't
    >> get filtered. Does it make it all the way to the end of the line?

    >
    > IP broadcasts MUST go to every host within that IP subnet. Switches
    > must flood the broadcasts to all active ports. So yes, the broadcast
    > will go to every host.
    >
    > If it were an IP multicast instead, each host would have to indicate
    > an interest in joining the multicast group, to receive the packets. So
    > it adds a little complexity, the IGMP "join" protocol. If this is an
    > isolated network used only for this system, IP multicast doesn't
    > really add any value.
    >
    > Or you can unicast each command to the individual slave only. This is
    > probably the best way to update the system. Now you would have to
    > change the way the slaves are addressed. You would use the IP address
    > of each slave for the master's round robin querying routine. And you
    > can eliminate the RS-485 addressing scheme entirely, if you want.
    >
    >> For each station I was hoping to use an embedded processor with a single
    >> MAC/PHY and some low end switch/hub stuff, but maybe that is out the
    >> window

    >
    > Each station could certainly consist of a single MAC, and the switches
    > you use can be shared among more than one of the stations. The only
    > limit there is how long the links will become. You have to remain
    > within 100 meters if you're using twisted pair copper.
    >
    > But I don't see anything at all to limit the topology to a daisy
    > chain.
    >

    Yes I understand and I wish it were so, but all those restrictions above
    make a daisy-chain mandatory. I asked for a pizza without anchovies and
    you are trying to sell me on how good they are

    Now that you have a clearer picture, is the ethernet daisy-chain a go or
    a no-go?


  15. Re: TCP/UDP for deterministic safety system

    On Aug 11, 8:31*pm, tns1 wrote:

    > Take your pick: One big reason is to maintain some backward
    > compatibility with existing systems.


    Given that the cable itself has to be replaced, probably to a cat-5e,
    the "backward compatibility," I have to believe, is in the protocol
    used by the master and slaves. And that aspect is independent of the
    topology, entirely.

    > Also Legacy $$$oftware.


    You do need to add the Ethernet and the IP and UDP layer, unless you
    decide to just layer your RS-485 protocol directly over Ethernet and
    do without the IP and UDP. Other than that, there should be no change
    to the legacy software caused by topology at layer 2. As I said, if
    you layer your existing protocol over an IP broadcast scheme, or even
    an Ethernet broadcast and no IP, it should work exactly as it does
    now, no matter what the cable plant looks like.

    > Also
    > ethernet will be just one option in addition to two existing
    > daisy-chained comm schemes - a 2nd topology would be extra work. The
    > environment is restrictive and a clean,simple install matters - you
    > can't just plop down a piece of equipment or route a cable anywhere you
    > please. Hooking up and debugging a daisy chain requires almost zero IT
    > knowledge and this does not change as it gets longer. These multi-port
    > switches you are dreaming about would likely be placed right next to the
    > master PC and you would have 30cables to muscle around instead of one.
    > The system allows any unit on the chain to isolate all the downstream
    > units, and also the 'boot' sequence can be stepped down the chain.


    If you feel more comfortable with a daisy chain layout, there's
    nothing in IEEE 802.1D that forbids this. But multiport switches are
    hardly something I dream about. They are commodity items. And the good
    ones allow you to go in and check the health of each port, with a
    remote workstation, without having to send people out to do this
    locally.

    I'll use a car analogy instead of the pizza analogy, if you permit.
    This is sort of like someone with a Model T Ford asking whether he can
    get a car with a more comfortable hand crank. Well, I suppose so. But
    you can go with electric starters these days. And it's not a pipe
    dream.

    Bert

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2