Des communications profibus réussies à partir de .NET?

Question

Quelqu'un at-il parlé avec succès profibus depuis une application .NET?

Si oui, quel périphérique / quelle carte avez-vous utilisé pour cela, quelle était l'application et avez-vous utilisé un type de code préexistant ou disponible?

Answer 1

Nous n'avons pas utilisé Profibus, mais nous avons utilisé DeviceNET (un autre protocole basé sur CAN), Ethernet / IP et ControlNet , qui ont tous défis similaires.

Nous le faisons depuis la fin des années 1990 et par conséquent, nous nous appuyons principalement sur notre propre code généré à l'aide de matériel standard. Les entreprises qui ont fait preuve de longévité au cours de cette période dont je me souviens sont: -

• AnyBus (HMS, www.anybus.com ) a récemment commencé à utiliser ses produits de passerelle autant que possible. placez les interfaces de bus de terrain à proximité du matériel, puis communiquez sur Ethernet normal (généralement à l'aide d'Ethernet / IP www.odva.org ) . Cela présente l'avantage de séparer le matériel et le PC en utilisant uniquement un câble réseau. Les classes Ethernet / IP .NET ont été écrites par nous-mêmes car il n’y avait pas beaucoup de choses sur le marché à l’époque. Je suis certain qu'une recherche rapide sur Google trouverait des bibliothèques de classes appropriées
• SST ( www.mysst.com ) utilise des interfaces de bus de terrain depuis plus d'une décennie. La dernière carte SST que nous utilisions pour DeviceNET n'avait encore qu'un exemple de code VB6. Une bonne sélection de supports de bus de terrain et différents facteurs de forme, par ex. PC104, PCI, PMCIA
• Beckhoff / Wago ( www.beckhoff.com , www.wago.com ) nous utilisons généralement Beckhoff pour les E / S plus que pour les cartes d’interface, mais c’est encore une entreprise qui existe depuis très longtemps. Ils ont également des produits qui prennent en charge l'exposition via OPC (un autre moyen d'obtenir des informations d'E / S sans communiquer directement avec le matériel / devicedrivers)

Je suggère de ne pas utiliser directement d'interface OPC avec le matériel (cela convient pour la communication via PC (.NET) - > PLC- > Profibus) car vous devez vous assurer que le système de contrôle répond aux pertes de contrôler à partir de votre application .NET. Je suppose que vous avez besoin d'un maître Profibus ici (pas d'un esclave), aussi longtemps que votre système de contrôle est intrinsèquement sûr, une perte de communication signifie que le système de contrôle entre dans une position "inactive". et donc la plupart des E / S reviendront à l’état de sécurité.

Nous essayons également de ne pas mettre de code lié à la sécurité dans .NET. La plupart de notre code .NET est une interface utilisateur à partir d'un automate, mais à certains endroits, nous contrôlons directement le bus de terrain, mais nous nous assurons que les verrouillages matériels empêcheront un fonctionnement non sécurisé, en utilisant des commutateurs / relais de sécurité ou un petit automate ayant pour tâche de verrouiller uniquement . Et surtout, assurez la sécurité du système! La perte de communication depuis le code .NET devrait arrêter l'automatisation à l'état de sécurité.

Answer 2

Nous avons utilisé Steeplechase pour connecter notre système Profibus à notre système de prélèvement automatisé.

http://www.phoenixcontact.com/automation/32131_31909.htm

Answer 3

Essayez ceci: http://libnodave.sourceforge.net