If there only is a single master with no slave sending messages while 
not being polled, even a bus built for multi master use results in a 
strictly deterministic timing, provided transmission errors are less of 
a concern.

So you might consider other criteria, like hardware and software 
overhead and node complexity.

Whats your "token ring bus" anyway? I know of token buses, being shared 
media buses with a logical ring topology built on top of it by passing 
software tokens from node to node. And I know of real physical rings 
(cabling pattern is a different issue, you can have a physical ring 
cabled as a star) passing tokens on the links between the nodes - but 
this is traditionally not called a bus.

Physical ring topologies have a few nice attributes, but unless it is 
UART based, you may end up making the required transceiver modules 
yourself. Also if you have to cope with powered down or dead nodes, a 
ring topology requires considerably more effort than a bus topology.

Both token based schemes however do not make a lot of sense in a single 
master environment where the master simply can poll addressed nodes 
sequentially, as can be easily implemented in RS485 based networks.

Also note that arbitration based networks having multiple masters do not 
necessarily result in nondeterministic timing of essential messages. 
While  non-switched ethernet is the traditional example of completely 
nondeterministic timing, the arbitration scheme of the CAN bus is 
strictly priority based without the necessity of re-arbitration by the 
winner.

Jakob Holderbaum wrote:
> The read-only client could became a problem with this solution

This is the first time I've ever heard that a simple shared media bus 
could have problem with some of the nodes being read-only. ;-)

Thank you for the replies.

The idea for the token implementation was relatively simple. The devices 
are connected in a physical ring, the master sends a token. Every node 
has a specific slot in the token, which implements logically some kind 
of multiplexing on the shared medium, triggered by the master.

But your arguments about simplicity in a single-master topology are 
truly valid.

With a RS485 bus topology, there can be a relatively simple solution 
utilizing e.g. MODBUS. Are you aware of other simple protocols which I 
should take in consideration for this bus aproach?

One problem I see with this, is the probably larger RTT. For every node 
in the system, one request package and one response package has to be 
sent.

In a ring would this become more efficient regarding to the consumed bus 
capacity per value. Or am I missing something here?

Of course, down-time of a node could have a drastical impact on the 
whole measurement process in such topologies. I hold this as a strong 
argument against a ring, whereas the subjective lean bandwidth 
consumption could make this a bit up.

But as I read yout replies correctly, the overall tendency goes toward a 
bus topology?

Cheers
Jakob

Jakob Holderbaum wrote:
> With a RS485 bus topology, there can be a relatively simple solution
> utilizing e.g. MODBUS. Are you aware of other simple protocols which I
> should take in consideration for this bus aproach?

You may use standard protocols, but you could also define your own, if 
permitted.

> One problem I see with this, is the probably larger RTT. For every node
> in the system, one request package and one response package has to be
> sent.

Do you plan to operate at the throughput/latency limit of the network in 
the first place?

> In a ring would this become more efficient regarding to the consumed bus
> capacity per value.

Hardware based token ring, where the token is not forwarded by software 
but by hardware, has a lower overhead. But this is far from being easily 
implemented and may require programmed logic in each of the nodes.

As soon as the token passing is done by software, ring or bus, I cannot 
see a big difference to a polled scheme, as the receive/transmit token 
processing time does not differ significantly to the request/response 
processing time of a single master polling its slaves.

Unless the distances are so big that the wire latency and the total 
number of bits stored on the wires are significant. So if you intend to 
run a many megabit network along the roads of a city, this might be a 
big deal. If all of the nodes are in a lab however...

> But as I read yout replies correctly, the overall tendency goes toward a
> bus topology?

Have you seen a physical ring of some kind being still alive? In general 
networking there was FDDI and IBM Token Ring, as well as IBM SSA and 
Fibre Channel loops in storage networking, all of them being dead or 
close to. And both of them were fairly complicated to implement.

My overview of all the industrial networks is somewhat limited though. 
Yet I've got the impression that most of them are pretty old. The "never 
change a running system" kind of old - well, I saw a fresh yet classic 
coaxial ARCNET installation for industrial control just a few years ago 
(a token bus invented in the late 70s).

Todays tendency in high thruput / low latency networking appears to be, 
to not try to reach near 100% utilization capability for small frames, 
but instead to make the network faster before you approach the limit.

Jakob Holderbaum wrote:
> But as I read yout replies correctly, the overall tendency goes toward a
> bus topology?

Actually to switched point to point links, if the capacity of simple 
buses is exceeded. Ethernet interfaces are dirt cheap and well 
integrated in controllers and systems, so everything which needs the 
speed of it and can be done with some specifically tuned ethernet 
hardware likely is done that way, sooner or later.

Thank you very much for participation, this discussion gave me quite a 
few interesting views, topics and insights on which I can base my 
further research.

I would consider this thread as solved, does the board engine give such 
possibilities? I could't find such thing.

Cheers
Jakob