<p>Has anyone successfully talked <a href="http://www.profibus.com/" rel="noreferrer">profibus</a> from a .NET application?</p>

<p>If you did, what device/card did you use to accomplish this, what was the application, and did you use any kind of preexisting or available code?</p>

[{'answer_id': 97659, 'author': 'FortunateDuke', 'author_id': 453046, 'author_profile': 'https://Stackoverflow.com/users/453046', 'pm_score': 2, 'selected': False, 'text': '<p>We have used Steeplechase to connect to our profibus to our automated pick system.</p>\n\n<p><a href="http://www.phoenixcontact.com/automation/32131_31909.htm" rel="nofollow noreferrer">http://www.phoenixcontact.com/automation/32131_31909.htm</a></p>\n'}, {'answer_id': 163405, 'author': 'Rhys', 'author_id': 22169, 'author_profile': 'https://Stackoverflow.com/users/22169', 'pm_score': 4, 'selected': True, 'text': '<p>We\'ve not used Profibus, but have used <strong>DeviceNET</strong> (another CAN based protocol), <strong>Ethernet/IP</strong> and <strong>ControlNet</strong> which all have similar challenges.</p>\n\n<p>We\'ve been doing this since the late 1990\'s and therefore rely mainly on our own generated code using off-the-shelf hardware.  The companies that have shown longevity during that period that I remember are:-</p>\n\n<ul>\n<li>AnyBus (HMS, <a href="http://www.anybus.com" rel="noreferrer">www.anybus.com</a>) we\'ve recently started using their gateway products as we can place fieldbus interfaces close to the hardware and then communicate over normal Ethernet (usually using Ethernet/IP <a href="http://www.odva.org" rel="noreferrer">www.odva.org</a>).  This has the advantage of separating hardware and PC using only a network cable. The Ethernet/IP .NET classes were written by ourselves as nothing much was on the market at the time. I\'m sure a quick google search would find suitable class libraries</li>\n<li>SST (<a href="http://www.mysst.com" rel="noreferrer">www.mysst.com</a>) have had fieldbus interfaces for more than a decade.  The last SST card we used for DeviceNET still only had VB6 sample code. A good selection of fieldbus support and different form-factors e.g. PC104, PCI, PMCIA</li>\n<li>Beckhoff/Wago (<a href="http://www.beckhoff.com" rel="noreferrer">www.beckhoff.com</a>, <a href="http://www.beckhoff.com" rel="noreferrer">www.wago.com</a>) we typically use Beckhoff for the I/O more than the interface cards but again a company that has been around a long time.  They also have products that support exposing using OPC (another way for you to get I/O information without directly communicating with the hardware/devicedrivers)</li>\n</ul>\n\n<p>I suggest not using OPC interfaces to the hardware directly (it’s OK for communication using PC (.NET)->PLC->Profibus) as you need to ensure that the control system responds to loss of control from your .NET application. I’m assuming that you are needing a profibus Master here (not a slave), so as long as your control system is intrinsically fail safe, then loss of communication should mean the control system enters an "Idle" state and therefore most of the I/O will return to the fails safe state.</p>\n\n<p>We also try to ensure that we do not put safety related code in .NET.  Most of our .NET code is userinterface from a PLC, but in some places we do control the fieldbus directly but ensure hardware interlocks will prevent un-safe operation, either using safety switches/relays or a small PLC with the the task of interlocking only.  <strong>And above all make the system fail-safe!</strong>  Loss of comms from the .NET code should shutdown the automation to the fail-safe state.</p>\n'}, {'answer_id': 3722786, 'author': 'avra', 'author_id': 368260, 'author_profile': 'https://Stackoverflow.com/users/368260', 'pm_score': 1, 'selected': False, 'text': '<p>Try this: <a href="http://libnodave.sourceforge.net" rel="nofollow noreferrer">http://libnodave.sourceforge.net</a></p>\n'}]
['https://Stackoverflow.com/questions/66687', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/5640/']