Very simple......

First off ditch your return RS232 dasiy chain scheme. As someone else commented earlier, if one of your controllers looses its power all controllers downwind from the unpowered one are locked out. Use RS422 as I suggested earlier. Or use RS485 if you want to cut down on the amount of wiring. It is also the nature of networked communications to encounter cable lengths that exceed those that are reliable single ended RS232 protocol.

Next, as you have already described that you understand, establish a master / slave protocol. All communications is understood to be packet oriented. Each packet from the master (sounds like you are using a PC for this) will generally result in the return of one packet from a properly addressed slave. You also devise a maximum response time window time to expect the reply packet from the addressed slave. This time window allows the master to establish a timeout process upon which retry or suspension of communications to a particular slave can be managed. In this scheme disallow any possibility of unsolicited packet transmissions from the slave.

You may devise the concept of a "broadcast" packet type from the master that all slaves receive. These packets are understood to have no replies.

Each packet sent by the master can use a simple CRC algorithm to append an error checking code to the outgoing packet. As you indicated this code is easy to find and has been discussed on this forum before. A 16 bit CRC support requires a couple of 256 byte tables and a 'few microseconds per byte' support subroutine. At the slaves each received packet is checked for proper CRC before any other action is taken. If a packet arrives at the slave and the CRC is incorrect that packet is simply thrown away and no further action is taken. (Although some implementations like to install one or two things within a slave. One of these can be an LED that can be lit when the slave sees a relatively large number of CRC errors. Another thing is that an error accumulator may be kept in the slave that counts the number of CRC errors seen. There could be a command that the slave recognizes to permit the master to gather these statistics).

It is also common for the master to keep a variable in its memory called a sequence counter. As each packet is sent out this variable is first incremented and is then copied into the outgoing packet.

After a slave recognizes a packet with valid CRC then an address field in the packet is compared against the address of the slave. If there is a compare then that slave knows it is being talked to. In your system design you must have the addressed slave respond to this packet with some type of reply. Also the reply must occur in the prescribed time window discussed above. These reply packets can generally be of two types. One type will be a simple ACK/NACK type reply to tell the master that the slave received the packet from the master and did or did not understand the payload in the packet. The other type of packet from the slave will be a data return packet where the slave sends payload back to the master in the reply. This can be either status information or data that fits the application at hand. Note that generally the replies of this second type are implied as a positive acknowledgement of the forgoing packet from the master that requested the information in the first place.

The return packets from the slave should include several pieces of information as a minimum. These pieces of information permit the master to better keep track of the proper communication sequence with the slaves. First the response packets should include a CRC similar to that described for the outgoing master packets. The reply packet should also include a return of the addressing information back to the master. And finally the sequence number from the request packet is echoed back to the master in the reply if this has been implemented. Of course the rest of the application specific packet data is included as well.

Identificaton of packet types is commonly handled by an byte that tells of the format of the packet and the intended purpose of the packet. It is also common to include packet length information in a packet, although this is often not necessary. Fixed length packets are often the easiest to implement. It may even be that the function type byte may imply the packet length. It is only really necessary to actually have a length byte in a packet if packets will have a variable length format. However most implementers like to put the length byte in the packet because it makes it easier to CRC check the packet and make the communications protocol extendable to additional packet types without having to re-write the low level packet send/receive logic.

A master will receive the reply packet and verify it by a four step validation process. First did it arrive in time. Next verify the CRC. Then did it come from the proper slave address and finally does the echoed sequence number match the one sent out in the request packet. The sequence number permits the master to ensure a level of synchronization with the slaves above the packet level. If the reply packet comes back with an error in the validation process it may be apropriate to initiate a re-try process or to alert the system operator of the problem.

I have implemented small systems communications around these simple guidelines many times. The protocol is reliable, easy to implement, and can offer as much performance as you require based upon how fast the communications takes place (i.e baud rate) and how much processor horsepower you put behind the serial port to process packets in order to keep up with the communication speed.

There are all these other communications protocols and standards out there that you can look at, such as CAN, Device Net, TCP, GPIB, etc etc etc, but I suggest that there is no particular incentive to use these in a small system unless there is some real driving force behind it. This could come from a corporate edict, necessity to interoperate with certain equipment with which you have no control, or scaleability of your equipment into a existing architecture.

I hope this helps summarize a simple and reliable communications system that you can use.
Michael Karas