Networking Technology

I'm looking for a networking technology with the following characteristics: - multi-drop, i.e. you can daisy-chain from one node to the next off a single cable - preferably single twisted pair cabling. If really necessary I could go to two twisted pairs. - able to deal with at least 64 slaves and one master per bus segment. There could be up to 10,000 slaves in a particular system. These could all be slaves off one bus, but if, as I suspect, this is not technically feasible, then having to have a repeater or hub or decoder or similar for each group of 64 nodes would be OK - I may get away with no return path - just outgoing signals from the master to the slaves. Better would be a system that could have some kind of handshake and some kind of status information coming back. - The information going to the slaves is very simple - often just "on" or "off", sometimes a bit more than this, but only a few bytes of data max. - preferably able to update all slaves in 2ms. If this is not possible I might be able to get away with a system in which I can turn say 256 slaves individually "on" or "off" in 2ms, plus a "general off" command that turns them all off quickly. - if I have 64 slaves per network segment, and I just send all the data for each update, and there is just one bit per slave (on/off) then I need to send 8 bytes of data plus framing, error detection etc. In this case the data rate required on the slave network is obviously very modest - maybe

50-100kb/s. If I try to update the whole of a 10,000 slave system in the same way in 2ms, then the data rate is much more demanding, maybe 5-10Mb/s. - very low cost hardware in the slave. This implies that either the protocol is very simple so I can implement it in a low cost microprocessor, or that there is a low cost mass-produced chip that implements a more complex protocol. The slave is very simple. It just needs to decode commands sent to its address, or to the "general" address, and implement them (usually just "on" or "off"). - cost of the master is somewhat less important, since there are 64x fewer of these, but cost is still important (what matters in the end, of course, is the overall cost of the system). - A 64 slave node bus could be distributed over a distance of 10m. The total network could be 500m long.

The system is still in the definition and feasibility stage, so there are many tradeoffs that I can make to come up with an optimum design.

It would be really helpful if you could suggest any protocols and technologies that it would be worth me investigating for this system.

Many thanks - Rowan

--------------------------------------- This message was sent using the comp.arch.embedded web interface on

formatting link

Reply to
rowan.bradley
Loading thread data ...

Picking nits... do you want each node to *straddle* the "cable" -- or, do you expect the node to sit *in* the signal path? I.e., do you expect all nodes to be powered up and functional at all times?

Why not EIA485? (I think it stresses at your 64 per segment, though)

How large must the packet be to "update a particular slave"? Are there other characteristics of your protocol that slaves can observe/track? Or, must each message be completely free standing?

Define "very low cost". 10,000 nodes will use a significant amount of *wire*, plus the costs of stringing it, configuration management, etc. (or, do you not care about "installation costs"?)

M being meters? That puts the 64 node segment at ~6 inches between nodes (assuming they are evenly distributed). And, the

10,000 node "network" at an average node spacing of about *2* inches! (assuming I've done the math properly) Are you sure you're not just chasing an arbitrary (marketing) spec?

The system I am designing currently is designed for only a few hundred nodes (it could be extended for other applications but the application I am initially addressing would never realistically need more than a few hundred). I've opted for a wireless approach. This adds a bit to the cost of the node "in its box" but is an overall cost *saver* in that it cuts down on wire and labor to string wire. I can exploit that to make it more attractive for folks to consider adding "extra" nodes.

YMMV.

Reply to
D Yuniskis

1/2 or 1/4 unit load slaves would allow more than the one master and 31 slaves allowed with standard 1 Unit Load transceivers.

CANbus would also be a viable option.

Broadcast all the data periodically and let each slave pick the data of interest.

This complicates the situation considerably, since the master must either poll each slave sequentially or use CANbus and let the CAN hardware at each slave do the arbitration of spontaneous responses.

With up to 64 slaves in a segment, one could use all the available 64 data bits in CAN frame to control specific digital outputs. At 1 Mbit/s, the frame takes about 150 us. If there are multiple digital outputs, separate CAN-IDs can be used to set the state for all DO1, DO2 etc. digital outputs on the segment.

If RS-485 at 115k2 are used, still 128 specific digital outputs could be set in the specified 2 ms.

If you are using Ethernet as the high level system and CANbus as the low level system with up to 64 nodes on each segment, you can put the data for 128 Ethernet/CAN gateways into a single frame, thus 8192 digital outputs could be controlled simultaneous by a single raw Ethernet or UDP frame. The Ethernet would have to be 100 Mbit/s or more, if the individual CAN segments are at 1 Mbit/s. In order to command 8192 digital outputs within 0,3 ms. The gateway controller should have one 100 Mbit/s Ethernet port and one or more CANbus controller on the chip.

This should not be a problem for RS-485 nor to CANbus.

Is this the total combined cable length or the maximum distance between segments.

Connecting 64-256 nodes into a single segment can be problematic at speeds of 1 Mbit/s and above, since all interconnections must work reliably as a transmission line over the system life time. The cable harness can become quite expensive, especially if it is required that a slave can be replaced without disturbing the traffic to other nodes. Just remember the problems of maintaining 10base2 ThinWire Ethernet networks :-).

Reply to
Paul Keinanen

The fundamental requirements are that the cost per node (including electronics, connectors, cabling and installation) is minimised (since there are a lot of them). I am hoping to find a means of cabling to the nodes that achieves this, maybe by combining power and data, maybe by using Krone-type IDC connectors where one continuous wire can daisy- chain from one node to the next and just be staked into the connector on each, or maybe by some kind of non-contact inductive pickup for the data, where a continuous cable is looped through a ferrite pulse transformer on each node with a terminator at the end (these are just ideas at this stage). Once installed the nodes do not physically move and they are rarely reconfigured. Of course occasionally a node will fail and have to be replaced, or a cable or connection may be damaged or become unreliable and have to be repaired. It must therefore be possible to remove a node and replace it without reinstalling the whole system, but this doesn't happen often.

As I understand it, the spec is only 31 nodes per segment. I'm not sure what limits this though. Maybe modern chips can do better than this?

I haven't designed the protocol yet - if I can find a protocol that already exists that will do this job, I'd prefer to use it. In most cases a node can only do two things - turn on or turn off. A packet would then simply have to address the node (if there are 10,000 nodes this implies a 14 bit address) plus one data bit. I need a "general off" command too. Some nodes have slightly more functionality (e.g. turn on and off again after a delay, or select one of 6 states) but they are all pretty simple. The biggest issue seems to be addressing the nodes in an efficient way.

The complete system is not "low cost". The individual nodes need to be low cost because there are a lot of them. What actually matters, as usual, is the cost of the complete solution including the individual nodes, any hubs or local controllers, wire, installation, central controller etc. I'm emphasising the cost of the node because I hope that this will minimise the cost of the whole system. Of course if reducing the cost of the nodes caused an excessive increase in the cost of hubs, cabling or installation, this wouldn't be the right answer. The current solution is to wire every node individually back to the central controller. This requires a humungous amount of wire - it is principally in reducing drastically the amount of wire and the cost of installing it that I think an opportunity may exist.

Yes

They will often be closer than this. 10m was intended to be the maximum length of a 64 node segment.

You're assuming that it's linear - it's not. There will be multiple 64- node segments distributed around the plant within a 3-D space. It would be much better if the cabling scheme could mirror this, i.e. the cable does not have to visit each of the 10,000 nodes in a linear order, but each 64-node segment could be wired back to a junction box or hub, which in turn could be wired back to the central controller (it's begining to sound very like ethernet - and maybe this is the best solution apart from within the 64-node segments).

Who says marketing specs are arbitrary? :-) It's my best attempt to define a system that will meet a very large percentage of the market requirement. I don't think it's arbitrary. Of course if a solution existed that would do 8,000 nodes much more cheaply but just could not do 10,000 at all, that might be a better solution and we will forget about the 1% of the market that needs more than 8,000 nodes, but you have to start somewhere...

Interesting. Can you say more? I think wireless might have an application here, but probably not to the individidual nodes (it seems intuitively likely to be a lot more expensive than a wired system, especially as the nodes are often only 2" apart). It seems a lot more likely to me that 64-node "segment controllers" could be wirelessly linked back to the central controller. Is there a latency problem with wireless? I.e. if an event occurs on the central controller, how long would it take to get a small data packet through the wireless network to a node? I'm thinking about elapsed time rather than data throughput. My data packets will be very small but must get there quickly... It would also have to operate without delays in the presence of electrical noise, people using mobile phones etc.

Many thanks for your inputs - Rowan

Reply to
Rowan

Are there chips that do 1/4 or 1/2 unit load? This sounds as if it solves the 31-node limit problem with RS485.

What's involved in designing a CANbus node (with very simple functionality - basically just to turn a power FET on or off). What chip or chips do I need to do this, at what sort of cost?

Yes, I think this may well be the best way. The only issue is that you don't know whether the system is working properly, i.e. whether the nodes are connected and are receiving their commands. It would be better if the system could detect faults in itself so alerts can be automatically raised. But maybe this is a luxury which isn't worth the cost and complexity.

I must learn more about CANbus!

Do products like this exist to buy? A quick web search shows a few, but they look quite expensive. Or are there chips designed for this specific function which would make a custom design reasonably easy?

It's the cable length, assuming some reasoably efficient cabling strategy. An individual site could be 200m from one end to the other. Usually much less than this.

See my earlier ideas about types of cabling. The cabling is a key part of the overal system cost.

I remember it only too well :-) but this situation is somewhat different. The system is installed by a professional installer, and then left alone until either it breaks or needs to be extended/ reconfigured in some way (which only happens rarely). Whereas in the case of 10base2 everyone was always plugging and unplugging computers. So I think some kind of daisy chain wiring is acceptable within a segment, provided there is a way of replacing a faulty node or repairing a wiring fault without a complete rewire. I can think of several methods which would appear to allow this (without having fully thought through the transmission line issues, which I agree has to be done).

Many thanks for your stimulating ideas!

Rowan

Reply to
Rowan

There are even 1/8 unit loads so up to 256 nodes could be connected e.g. SN65HVD06.

There are micro-controllers with built in CAN controller or an external CAN controller (such as SJA1000) could be used. The controller will handle the bus arbitration, adds and checks CRC.

You might find some micro-controller with both Ethernet and CAN controllers, otherwise get a micro-controller with ethernet and use some external CAN controller.

You might also look at EtherCAT, which is implemented completely with Ethernet. However, I have no idea what the EtherCAT slave chips cost these days.

Reply to
Paul Keinanen

load slaves would allow more than the one master and

Sure, see:

formatting link

Hope that helps, Best Regards, Dave

Reply to
Dave Nadler

load slaves would allow more than the one master and

The simplest I've seen are ICs like MCP25050 from MicroChip. I seem to recall someone else making something similar (Philips maybe?). I've not used these but I would be curious if anyone else has.

Robert

Reply to
Robert Adsett
[...]

Consider MC9S08DN16 and a CAN transceiver if you want a bit more than the MCP25050 offers. Similar cost, full flexibility.

Oliver

--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:
Reply to
Oliver Betz

go

l

of

or

I
s
s
a

he

r,

ewer

,

/

formatting link

There 'could' be some interesting wireless approaches (zigbee, infrared even) but wouldn't they require a pantload of batteries and all the issues that come with that? I dunno, maybe something similar to X10 or other domotics could work.

Reply to
1 Lucky Texan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.