Hello all,
I'm not sure where we might carry on such a discussion, but I'd like to discuss which protocols are available, which might be, and for what they are useful.
To this end, I've created a table below as a start.

Meanings:
1. Protocol - Common name
2. Status - is the protocol being used and stable, maturity level
3. Speed - given the overhead of the protocol, is it fast or slow, and does it have real-time provisions (Hard real-time)
4. Issues - how does it have problems
5. In Proview? - is it implemented in Proview or not
6. Easily available? - on an installation and cost basis, is it easy to have. Examples: I've listed modbus-tcp as yes, because it exists virtually every operating system at no cost, and is still being worked on. Profinet, on the other hand, I have listed as no, because getting onto an OS of choice is both monetarily costly, and requires compilation.
7. Uses - reasonable use cases for the protocol in question

Protocol	Status	Speed	Issues	In Proview?	Easily available?	Uses	Website(s)
Modbus-TCP	Mature	Non-realtime, fast	No security	Yes	Yes	Control and Acquisition for non-realtime systems on a secured network	Modbus Organization Modbus wiki-page
Profinet	Mature	Realtime, fast	Expensive, Almost Siemens only	Yes	No	Control and Data Acquisition including real-time on a secured network	Profibus/net Website Profibus/net Wiki-page
openPowerlink	Mature	Realtime, fast	CANOpen Embedded B&R Hardware	Yes/Maybe	Yes	Control and Data Acquisition including real-time on a secured network	openPowerlink Website There are a bunch of cool looking dead links for openPowerlink. Copies of those would be interesting.
OPC UA	Mature	Unsure	Unsure	Not Currently	No	General IO with virtually everything. Communicate with other GP computers, remote IO, and other other control types. Everything.	OPC Foundation
DNP-3	Mature	fast	?	No	No	Control and Data Acquisition on the internet using accepted security guidelines	DNP-3 Wikipage DNP-3 IEEE Standard
IEC 60870-5-104[/url]	Mature	fast	?	No	No	Control and Data Acquisition including WAN using accepted security guidelines	IEC 60870-5-104 Wikipage IEC 60870-5-104 Store
BACnet	Mature	non-realtime, fast	building automation, so afterthought for I&C	No	No	Control and Data Acquisition on a secured network. Air conditioning, ventilation.	TBA
CANOpen	Mature	fast	?	No	No	Control and Data Acquisition including WAN	CAN-CIA Website

We are using Modbus-TCP and have some legacy SIMOCODE systems.
I'm starting to warm up to the idea that Powerlink might be the way to go, over the long term.
I have also observed that the Powerlink equipment is more likely to be "network versatile" out of the box, relative to S7 anyway, if one should want to change protocols for some reason.

In the end, I am looking for things that are allow my facility to move forward with the best equipment we can, at the lowest cost, but probably most important, with the greatest longevity.

I look forward to seeing what you all think.

Related to this, I'll be putting up a list of equipment we are currently using in the hardware section and what works, and what doesn't.


Thanks,
Matt

Hi Matt,

openPOWERLINK is CANopen Ethernet Embedded. These protocols are deterministic (real-time, fast), multimaster and slave to slave exchange and with collision avoiding system to stay deterministic (which is not the case with Modbus TCP/IP).
They are open source.
There is openPOWERLINK in ProviewR made by KALYCITO few years ago with the help of B&R, but it must be recompiled to work since 4.8.
Take a look here:
www.proview.se/v3/index.php/forum/3-help...pported?limitstart=0
It would be fine if it works on next version of ProviewR (with eclipse add-on to produce the *.cdc definition file)
There is a bunch of sensors under CANopen (see CAN in automation) too, but unfortunately not (yet) I/O support in ProviewR

/Bruno

Thanks Bruno,
I appreciate the addition. I'll add a column to cite the sources of the protocol.

Right now, it seems that Modbus rules the day for network protocols. This seems somewhat antiquated to me, but it works.

So, if I understand you correctly, CANopen is a protocol you'd like to see implemented?
Maybe I should consider adding a second chart of protocols one would like to see?

Thanks,
Matt

Matt,

I believe you may find Common Industrial Protocol (CIP) interesting?

drive.google.com/file/d/1Xn41y8EmRGzFrhY...HWC/view?usp=sharing

Founded in 1995, ODVA (www.odva.org) is a global association whose members comprise the world’s leading
automation companies. Combined with the support of its members, ODVA’s mission is to advance open,
interoperable information and communication technologies in industrial automation. The basis of the membership community is its primary common interest in developing standards and promoting adoption of the Common Industrial Protocol (CIPTM), ODVA’s media independent network protocol, and the network adaptations of CIP –EtherNet/IP, DeviceNet, CompoNet and ControlNet. ODVA manages these technologies, and develops and distributes the specifications for these four networks in a common structure to help ensure consistency and accuracy.

Many vendors have adopted CIP as their automation communication protocol standard. Most notably, Rockwell uses CIP for Control Logix PLC network protocol. If looking to implement a new communication protocol for Proview, CIP is a very interesting choice.

With Proview 5.5, Modbus TCP/IP is probably the best choice for I/O that is readily available. It is robust enough for many applications. Even though antiquated, it's been around a long time and will continue to be around much longer, mostly due to it's simplicity and ease of implementation. There are many I/O choices available that support Modbus RTU or Modbus TCP/IP. Proview supports both.

www.ccontrols.com/basautomation/iomodbus.php

Another protocol you have not mentioned is OPC. In the US at least, most DCS and PLC vendors support OPC DA servers for third parties to read and write data. Unfortunately, OPC DA is a MicroSoft only protocol. But, Proview supports OPC XML DA clients to connect to others and also an OPC XML DA server for others to connect to a Proview database. Simple Python scripts can read and write to a Proview database through an OPC XML DA server.

There are several vendors that sell OPC DA to OPC XML DA protocol converters: Kassl.de opcXGate, Softing.com opcDataFEED Suite and KepWareServerEx to name a few. We have tried them all with limited success. Currently, we are continuing to develop code to achieve a robust interface that communicates well with industrial automation OPC servers.

On a slightly different note, OPC UA protocol is gaining traction with the emergence of the Internet of Things (IOT):

industrial-iot.com/2016/05/opc-ua-becoming-opc-iot/

For future longevity, OPC UA may be a top choice for Proview support. It is an XML SOAP standard, human-readable protocol, easily debugged with WireShark and connects to, well..., everything.

Depending on your need for hard, real-time I/O, checkout sealevel.com They sell industrial I/O boards with Linux driver support. Might be adapted to Proview fairly easily?

www.sealevel.com/support/software-com-ex...re-and-driver-links/

Also, depending on project size, let's not overlook the possibility of USB I/O with available Linux drivers.

www.mccdaq.com/usb-data-acquisition/USB-1024-Series.aspx

For demonstration purposes, the Velleman_k8055 has a small amount of USB accessible I/O supported by Proview. Thanks to Marc's video, I was able to get that magic to work awhile back...

Ron

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

Hi Matt,

Perhaps Claes can clarify or comment on the following statements?

I believe SSAB has it's own line of custom I/O that communicates directly via QCOM?

If yes, I wonder if SSAB would consider either selling I/O to the general public or maybe sharing I/O circuit diagrams? Assuming SSAB is not interested in selling I/O, then we might explore the idea of building a line of industrial I/O directly compatible with Proview? We have several electrical engineers and access to custom board manufacturers.

Ron