Hi EmbDev.net/uC.net board! I am currently working on my mastersthesis, developing a virtual prototype of a distributes measurement system. One of the core topics will be the distributed data acquisition between the different nodes, rather than building concrete measurement sensors. After conducting a requirement analysis, I am now at the point to begin the planning for the first virtual prototype implementation. Basically, I need a deterministic BUS system, on which a master sequentially reads out data from different measurement nodes (slaves). The main requirement is a high precision on timing constraints. The BUS should not stall because of arbitration or other blocking operations. Another requirement I would like to propose is the extendability for (passive) read-only clients, like persistant storage devices or realtime displays. Those clients should be able to read every occuring BUS frame, independent of the designated receiver. For now, I am thinking about two directions: MODBUS on a serial shared BUS. There exist several libraries for ARM and other architectures, which eliminates the need to implement a self-baked protocol. The read-only client could became a problem with this solution, I have to check whether the existing lib support this. An implementation of a Token Ring BUS. This has the main advantage, that less overhad for BUS protokol and stuff like that is used. Instead, every node gets its position on the Token Frame which is periodically sent by the master. Advantage I see here is also, that read-only clients are dead simple to integrate. Main disadvantages can be reliability and there is perhaps a lot more to implement by hand. I do not want a solution to my problem, instead I am interested in BUS-Systems, you have used before. Any specific problems or positive experiences with star or ring wiring or event specific protocols? :) Thanks for your interest, have a nice day Jakob
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.
: Edited by User
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
So basically, you are re-inventing one of . GPIB, . VXI, . PXI or . VME. Jakob Holderbaum wrote: > Or am I missing something here? That's probably one of the issues you could work out in your thesis... Jakob Holderbaum wrote: > mastersthesis Du darfst übrigens auch auf Deutsch schreiben. Im englischsprachigen Raum heißts dann übrigens meistens "master's thesis".
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.
: Edited by User
Old time Interbus for example was logically a FIFO ring. Little overhead. All bus modules write their status in the FIFO registers, then all data including new data from the master is shifted through. After the end of shifting, all data is written into the modules, and status is written into the FIFO registers again. I think this is one of the fastest methods of data transfer for a given bandwidth, when data size is fixed. Interbus added some diag and configuration info (about 2 bytes per bus module) and ran on 250kbps-2mbps over cheap fiber or twisted pair and was built for industrial environment. We usually had bus cycles below 10ms for welding stations with a lot of robots and modules, even with the then-standard 500kbps. -- Now, I often see Profinet in newer installations, which basically is ethernet with managed switches and defined response times. It is faster due to much higher bandwidth, but requires an ethernet controller and a configuration interface in every module.
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.
: Edited by User
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