I doubly encourage adopting Sheldn's approach.
In the past, presently, and in the future, I will continue to insist absolutely on seperating the I/O subsystems from any ethernet network. Not because of the deterministic nature of ControlNet, but rather due to the fact that Ethernet, more specifically, IP and it's variants, will inevetably fall to the IT department's domain. Even with the very best managed networks, disaster can strike. Want real fun some day? Find an ethernet switch or hub somewhere with two ports open on it... take a patch cable, and plug the switch into itself... watch the ensuing fun! (NO! DO NOT DO THIS!!! EVER!!!!).
Unless the network is configured with switches that support STP (Spanning Tree Protocol), and is properly isolated by STP switches, this will cause every single IP addressed device to shut down due to seeing a duplicate IP address. Smart, or even managed switches, without STP will not shut this down as a packet-storm, as they think everything is fine based on the MAC ID's.
I do put the HMI's on Ethernet, as it makes centralized data-collection, as well as quickly going online for troubleshooting, or backing something up, very easy. Of course, I also insist on having hard-wired Start/Stop, and of course ESTOP circuits. I never run line starts from an HMI. Personal preference.
Even without the IT department monkeying around (and, if they don't have one today, they will in a year, or 5, or 10), segments of and Ethernet network, if not the whole network, can be taken down by an uncooperative (or failing) device. I have one computer that will work fine for a few hours, but eventually will start locking up ethernet because it has a bad network card. It's fun to have around as a demonstration of what can happen.