¿Alguna comunicación profibus exitosa de .NET?

Question

¿Alguien ha hablado con éxito profibus desde una aplicación .NET?

Si lo hizo, qué dispositivo/tarjeta usó para lograr esto, ¿cuál era la aplicación y utilizó algún tipo de código preexistente o disponible?

Answer 1

Nosotros no hemos usado Profibus, pero hemos utilizado DeviceNET (otro protocolo basado CAN), Ethernet/IP yControlNet la que todos tienen problemas similares.

Hemos estado haciendo esto desde finales de la década de 1990 y, por lo tanto, confiamos principalmente en nuestro propio código generado utilizando hardware disponible en el mercado. Las empresas que han mostrado la longevidad durante ese periodo que recuerdo son: -

• AnyBus (HMS, www.anybus.com) que recientemente he empezado a utilizar sus productos de puerta de enlace como podemos colocar interfaces de bus cerca del hardware y luego comunicarse a través de Ethernet normal (generalmente usando Ethernet/IP www.odva.org). Esto tiene la ventaja de separar el hardware y la PC utilizando solo un cable de red. Las clases Ethernet/IP .NET fueron escritas por nosotros mismos ya que no había mucho en el mercado en ese momento. Estoy seguro de que una búsqueda rápida en Google encontraría las bibliotecas de clases adecuadas
• SST (www.mysst.com) han tenido interfaces de bus de campo durante más de una década. La última tarjeta SST que utilizamos para DeviceNET todavía tenía código de muestra VB6. Una buena selección de soporte de bus de campo y diferentes factores de forma, p. PC104, PCI, PMCIA
• Beckhoff/Wago (www.beckhoff.com, www.wago.com) solemos utilizar Beckhoff para las E/S más que las tarjetas de interfaz, pero una vez más, una empresa que lleva mucho tiempo. También tienen productos que apoyan la exposición utilizando OPC (otra manera para que pueda obtener de E/S de información sin comunicarse directamente con el hardware/devicedrivers)

No se sugiere emplear interfaces OPC al hardware directamente (que está bien para la comunicación usando PC (.NET) -> PLC-> Profibus) ya que necesita asegurarse de que el sistema de control responda a la pérdida de control de su aplicación .NET. Supongo que necesita un maestro profibus aquí (no un esclavo), por lo que siempre que su sistema de control sea intrínsecamente seguro, la pérdida de comunicación debería significar que el sistema de control ingrese en estado "inactivo" y, por lo tanto, la mayoría de I/O volverá al estado de falla de seguridad.

También intentamos asegurarnos de que no ponemos código relacionado con la seguridad en .NET. La mayoría de nuestro código .NET es interfaz de usuario de un PLC, pero en algunos lugares controlamos el bus de campo directamente, pero aseguramos que los enclavamientos de hardware eviten el funcionamiento no seguro, ya sea mediante interruptores/relés de seguridad o un PLC pequeño con la tarea de enclavamiento solamente . ¡Y sobre todo hacer que el sistema sea seguro! La pérdida de comunicaciones del código .NET debería cerrar la automatización al estado de seguridad.

Answer 2

Hemos utilizado Steeplechase para conectar nuestro profibus a nuestro sistema de selección automática.

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

Answer 3

Pruebe esto: http://libnodave.sourceforge.net