C
Hi all
I have been checking out low cost I/O options for the LinuxPLC. Phil found some stuff from Optimate that meets all my criteria save one. The problem is the protocol. This is a major headache and I'd like some opinions from the field. Ethernet I/O is very desirable as it lets us avoid the whole fieldbus issue. Ethernet I/O is fast, the network is cheap and ubiquitous and the installed cost is at least an order of magnitude cheaper than proprietary fieldbus (and there is no Open fieldbus).
The problem is in the protocols. This is the second EIO solution I have looked at. The Opto22 ENET racks were the first. They are expensive
but support Modbus/TCP, the closest thing to an Open Protocol. The problem is, they don't support it very well. It's an add-on. What they want you to use is a published proto based on IEEE1394 (firewire) block transfers. This is those packets over ethernet not firewire.
This is a non-standard proto that is used by them alone as far as I can tell. It would be much faster than their implimentation of Modbus/TCP
because they support only five (5) of the Modbus/TCP operations.
This new Optimate stuff is much cheaper, offers higher density, but the protocol used is entirely proprietary. It is not even published that I could
see. Phil says they're Linux friendly so, I'm sure they will give you the info to write a driver.
This is what is destroying the promise of Ethernet. Everybody whos uses it puts their own proto on top of it. This turns Ethernet which is a great Open success in the IT industry, into simply another non-interoperable mess. To use Ethernet sounds good for advertising but the way they are doing it negates most of the value IMHO.
What do we do, support the closed protos to get functionality or hold out for interoperability?
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I have been checking out low cost I/O options for the LinuxPLC. Phil found some stuff from Optimate that meets all my criteria save one. The problem is the protocol. This is a major headache and I'd like some opinions from the field. Ethernet I/O is very desirable as it lets us avoid the whole fieldbus issue. Ethernet I/O is fast, the network is cheap and ubiquitous and the installed cost is at least an order of magnitude cheaper than proprietary fieldbus (and there is no Open fieldbus).
The problem is in the protocols. This is the second EIO solution I have looked at. The Opto22 ENET racks were the first. They are expensive
but support Modbus/TCP, the closest thing to an Open Protocol. The problem is, they don't support it very well. It's an add-on. What they want you to use is a published proto based on IEEE1394 (firewire) block transfers. This is those packets over ethernet not firewire.
This is a non-standard proto that is used by them alone as far as I can tell. It would be much faster than their implimentation of Modbus/TCP
because they support only five (5) of the Modbus/TCP operations.
This new Optimate stuff is much cheaper, offers higher density, but the protocol used is entirely proprietary. It is not even published that I could
see. Phil says they're Linux friendly so, I'm sure they will give you the info to write a driver.
This is what is destroying the promise of Ethernet. Everybody whos uses it puts their own proto on top of it. This turns Ethernet which is a great Open success in the IT industry, into simply another non-interoperable mess. To use Ethernet sounds good for advertising but the way they are doing it negates most of the value IMHO.
What do we do, support the closed protos to get functionality or hold out for interoperability?
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc