riceman0
September 28th, 2006, 12:31 PM
Hi. Sorry in advance for the long-winded question.
We are developing a valve control system, in which we have to write software to download to microprocessors embedded in valves. The valves communicate with each other, but they are also designed to actuate autonomously, in case communication is lost. Another key is that we have to write custom windows software to monitor, control, and administer the valves.
We are fresh off of a similar, smaller project, in which we used a popular fieldbus (although not one of the big ones) generally used for light commercial work (we shoulda known). I believe this fieldbus is probably reliable for making very simple, off-the-shelf devices interoperate. But we had all sorts of problems, I think because we were writing our own moderately sophisticated device applications, and particularly because we were trying to write our own windows software to monitor/control the network (using the API developed by the developer of the fieldbus, to allow it to send/receive commands over their protocol, along with myriad vendor apps to gate traffic to IP, etc). For the latter half of the project, it took us much more time to work around shortcomings in the "features" of this API, then it would've to write our own API from scratch.
So, being the guy who had to work through all of these problems, and faced with specifying a new valve system, my tendency is to go ethernet; embed microprocessors with only TCP/IP stacks and ethernet ports into the valves, and write windows programs that communicate with these devices via the PC tcp/ip stack. This would be "roll your own", we would have to write more of our own code to transmit data, come up with our own message codes, etc., but at LEAST we would have the power to make things work right, rather than live with shortcomings of an underlying infrastructure (standing on the shoulders of clumsy, possibly drunk, giants).
But this obviously has its risks. This is a safety system, and it would have to be very reliable and available. We are experienced with software development and software QA, but still whatever we write ourselves is original software and more subject to design flaws.
The alternative is a more reputable infrastructure like PROFIBUS. I haven't used PROFI, but assuming it has all the infrastructure for deployment, and some sort of windows libraries, and all the features we need (and many we don't) like message acknowledgement, etc... it could save us a lot of work, and would be more mature software out of the box.
That makes some sense, but so does the logic (to me) that all the prefab solutions will have some shortcomings we have to live with, whereas with ethernet we could tune and tailor it, even redesign it, until we have it JUST how we want it.
So actual questions:
1) Am I right that we could build a monitor and control system using ethernet more-or-less from scratch? Am I characterizing this correctly, PROFIBUS (and the other big boys) is sort of prefab, and ethernet is sort of roll-your-own?
2) Does anybody have similar experience down either fork of these crossroads I'm at, and could offer cautionary tale?
3) (sort of a follow-on) does PROFIBUS work well for true distributed, peer-to-peer devices (like our autonomous valves that take advantage of network comm IF available), and do they have HIGHLY reliable libraries for integrating with windows machines?
Thanks for reading this far, and thanks in advance for the help...
We are developing a valve control system, in which we have to write software to download to microprocessors embedded in valves. The valves communicate with each other, but they are also designed to actuate autonomously, in case communication is lost. Another key is that we have to write custom windows software to monitor, control, and administer the valves.
We are fresh off of a similar, smaller project, in which we used a popular fieldbus (although not one of the big ones) generally used for light commercial work (we shoulda known). I believe this fieldbus is probably reliable for making very simple, off-the-shelf devices interoperate. But we had all sorts of problems, I think because we were writing our own moderately sophisticated device applications, and particularly because we were trying to write our own windows software to monitor/control the network (using the API developed by the developer of the fieldbus, to allow it to send/receive commands over their protocol, along with myriad vendor apps to gate traffic to IP, etc). For the latter half of the project, it took us much more time to work around shortcomings in the "features" of this API, then it would've to write our own API from scratch.
So, being the guy who had to work through all of these problems, and faced with specifying a new valve system, my tendency is to go ethernet; embed microprocessors with only TCP/IP stacks and ethernet ports into the valves, and write windows programs that communicate with these devices via the PC tcp/ip stack. This would be "roll your own", we would have to write more of our own code to transmit data, come up with our own message codes, etc., but at LEAST we would have the power to make things work right, rather than live with shortcomings of an underlying infrastructure (standing on the shoulders of clumsy, possibly drunk, giants).
But this obviously has its risks. This is a safety system, and it would have to be very reliable and available. We are experienced with software development and software QA, but still whatever we write ourselves is original software and more subject to design flaws.
The alternative is a more reputable infrastructure like PROFIBUS. I haven't used PROFI, but assuming it has all the infrastructure for deployment, and some sort of windows libraries, and all the features we need (and many we don't) like message acknowledgement, etc... it could save us a lot of work, and would be more mature software out of the box.
That makes some sense, but so does the logic (to me) that all the prefab solutions will have some shortcomings we have to live with, whereas with ethernet we could tune and tailor it, even redesign it, until we have it JUST how we want it.
So actual questions:
1) Am I right that we could build a monitor and control system using ethernet more-or-less from scratch? Am I characterizing this correctly, PROFIBUS (and the other big boys) is sort of prefab, and ethernet is sort of roll-your-own?
2) Does anybody have similar experience down either fork of these crossroads I'm at, and could offer cautionary tale?
3) (sort of a follow-on) does PROFIBUS work well for true distributed, peer-to-peer devices (like our autonomous valves that take advantage of network comm IF available), and do they have HIGHLY reliable libraries for integrating with windows machines?
Thanks for reading this far, and thanks in advance for the help...