Ron,
Thanks for your in depth effort here!
1. I will definitely look further into CIP.
2. As far as OPC goes, I've only seen that as a translation layer, typically between other standards and for storage.
I'd love to hear a counter-argument for this. I'm not saying that it isn't useful, but I don't see it as a "stand-alone" protocol used to communicate directly with the hardware (which is what I'm trying to focus on here). Would a "translation protocol" list be useful? FTR, I do see how these could be classified together.
3. From what I have read (and you seem to be re-enforcing) OPC-UA may change this "middle-ware" use-case for OPC. Part of my work is to remove as much middle-ware style conversion work from the system as practical.
4. Sea Level is interesting, thanks! While this sort of data is useful, I'm trying to limit this thread to protocols, and I should have been more specific and said "tcp/ip or ip protocols".
5. Again, this falls outside TCP/IP and IP networks (even though USB is most certainly a network).
6. Velleman_k8055, see previous two.
On points 4-6, as I discuss the ProviewR with my confederates, I'm finding the same sort of questions, notably:
1. What hardware does it support?
2. What are the capabilities of the software for a given hardware set? Something like, "I have a dual Xeon 2.3 GHz, 16 GB, etc...; How many IO points can it support at a given cycle speed?"
4. Which protocols are supported?
As a first attack on those 4 questions, I already have another thread on the specific hardware we are using. I recommend that you place some of this data there. I, for one, love to read first hand experiences of others with the hardware they use.
Proview Hardware Forum
My Facility Hardware at UF
An additional thread that might handle some of the other questions would be solid benchmarking methods that could be used to analyse systems in place or that are being tested, and those results.
Thank you again for your work!
-Matt