AVR Freaks

1. As I said I don't know what the baud rate(s) being used are, however I know it's between 19k2bps and 56kbps.
2. Assuming you mean the time it takes for the message to get from the PC to the target module, max delay is hard to say at this point. The majority of what is required from the system is motion control. And every module will of course feature it's own microcontroller which I'll be programming, so for operations that are particularly time critical I can give more responsibility to the firmware of that slave/ module. But generally speaking, the faster the better, obviously.
3. At the moment, the most we could possibly require is 9, however I know there is already a project in the pipeline where there will be 24+.
4. I'm not 100% sure what you're asking here, but communications between the control board and the modules, and module to module, is essentially UART converted to RS-232 via converter ICs, then back to UART once it gets to the destination
5. Yes, the system operates in an industrial environment so absolutely.

Ethernet did cross my mind yes, but I wasn't sure how suitable it would be in a harsh environment. I'll read up on it though seeing that you suggested it!

I did think about somehow integrating IoT into the system but as you said, not great for industrial environments, and in truth there isn't any real need for wireless comms. You could argue that it would eliminate the need for drag-chains and such but the systems being communicated with still need power so those drag-chains would still be required. Might as well utilize them and put comms cables in them!

To get around the issue of multiple slaves wants to communicate, I thought what I could do was that should the master notice this line go low, poll every connected slave in turn, from lowest to highest until one of them says 'yeah that was me' then the master can continue to listen to that slave as normal. Now lets says this slave has address 10 assigned to it in this case. Whilst this slave is being dealt with by the master, another slave who also pulled the signal low, lets say address 14, continues to keep the line low. Once the master and the slave at address 10 have finished, that slave releases the signal and goes back to Hi-Z, and at the same time the master, noticing the line is still low, starts polling again, only rather than starting from the lowest, it starts from the next address.

If you or anyone can see any flaw(s) or possible problems with that solution then by all means, point them out to me.

Continually polling did cross my mind, however I thought the extra signal might help me make things more efficient and save me constantly polling. 

I wasn't aware this was possible, thanks for pointing it out, I'll look it up!

That's a good point, I suppose really I need to factor in worst case scenario and calculate what the average poll-response time is in my case and decide if it's acceptable...

That's a nice idea, though I'm not sure what would happen if more than 1 slave sent a message at the same time? 

PS: Something I forgot to mention in my OP was whether I meant full-duplex or half-duplex RS-485 - at the moment I'm thinking full-duplex, unless anyone is aware of any draw-backs of full-duplex RS-485 that half-duplex caters for?

Thanks for all the feedback and suggestions so far!

Having read through all the comments, I'm now considering using either RS-485, Ethernet, or CAN. I'll read up on them all properly in due course, should I have any queries I'll be sure to post them here.

1. Yes

2. Full duplex actually

3. Yes

4. Yes

5. Yes

1. Close - at the moment I was thinking of using a UART-USB converter such as an FTDI FT232RL as it'll be quicker & easier, but USB CDC ACM is a possibility of course.

2 & 3. Hadn't considered the USB communication in this much detail yet but that does sound like a good approach.

4. The XMEGA will have a little more to do than that but yes, along those lines.

5. Yes. The PC will be running a UI application for the machinery and will handle the bulk of the application. The hardware is just a means of controlling the machinery, the UI will tell it what to do.

Going back to 2 & 3. What I was thinking about was simply have the PC treat the USB port connected to the XMEGA as a serial port, and with every message packet send and source and destination address. When the XMEGA receives the packet, it checks the destination (as well as error checking obviously) if the packet is for the XMEGA it processes it, else it passes it on the it's intended target on the RS-485/ Ethernet/ CAN bus.

Similarly, when the XMEGA receives a message from a slave on the bus, it either processes the message itself, or passes the message on to the PC depending on the destination address (or even to another slave on the bus unless the interface I decide to use has the ability of slaves transmitting to slaves, such as CAN as mentioned by Jim a few posts ago

A little bit more background info that may or may not be of importance or interest... The PCB that features the XMEGA will not only serve as a master for the RS-485/ Ethernet/ CAN bus, but will also serve as the main control board. Essentially we have a 'base' model machine. This will all be controlled by the main control board. Then on top of this we have add-on options, that enable the base machine to be configured to whatever the customers needs and spec are. Each one of these add-on options will essentially be a slave/ module.

Thanks again to everyone who has contributed so far.

EDIT: 

I saw someone mentioned this on another thread (it might well have been you in fact!) and I did look into it and I'd like to do this myself, however I can't see it being possible due to the fact that there is a vision system involved, consisting of two cameras and a frame grabber which connects the host PC.