bsahilu:
Guys,I've been doing a bit of tinkering with bus networking for a particular project I'm working on. Initially I attempted to implement ModBus protocol running on an RS-485 physical layer using 3 arduino slaves and one Mega master. My over-all intention/objective is to prototype for a large 100+ node-support each performing simple tasks. Each slave/node has ONE output and TWO inputs which they need to monitor and report to a master controller. A GUI app will be tied to the master node making use of the data for an operator.
This was successfully done using ModBus, however, the major draw-back is that for my project I will NOT have the ablity to individually preset the slave IDs. On the flip-side, I will be embedding a UNIQUE serial IC that will guarantee each node to have a non-repeating addressable value.
The CANopen NMT protocol will solve this for you. It has a Master node that keeps track of what nodes are on the bus, sends out periodic requests for new nodes to announce themselves, allocates them an unused address and implicitly gives them permission to participate in the bus with that new address.
bsahilu:
That's where I stumbled upon switching to a CAN bus. Being that I can load identical firmware on each node and (in theory) I can have a multi-master situation where each node can broadcast onto the bus, this seemed pretty promising. First of all, am I understanding correctly? Can I in fact upon connecting to the network send out a message that has a destination address of the MASTER node to say 'hey, I'm new, give me a node address?.' Or even have the MASTER node send out a broadcast message periodically asking 'hey, is there anyone new?.'
Yes, CAN is multi-master. But you generally want to design your network so that only one special head node runs particular master services like address-space management. The CANopen NMT is similar to what you suggest, with a dedicated NMT Master service running on a central node and managing who has access to the bus with what address. The specification provides for several levels of intelligence from both the NMT master and each of the slaves, from fully-dynamic and capable of error-reporting, down to basically brain-dead operation from jumpered addresses.
If you go with a recognised presentation protocol like CANopen, it also gives you formalisms for communicating the input and output values of each node that will possibly be compatible with other commercial (factory automation) systems. Plus other useful things like the ability to download configuration data/code to your slaves and whole lot more.