El éxito de cualquier profibus comunicaciones .NETA?

Question

Alguien ha hablado con éxito profibus a partir de una .NETO de la aplicación?

Si no, ¿qué dispositivo/tarjeta que usaste para lograr esto, ¿qué fue de la aplicación, y le hizo uso de cualquier tipo de preexistentes o el código disponible?

Answer 1

No hemos utilizado Profibus, sino que se han empleado DeviceNET (otro protocolo basado en CAN), Ethernet/IP y ControlNet que todos tienen problemas similares.

Hemos estado haciendo esto desde finales de la década de 1990 y, por tanto, que se basan principalmente en nuestro propio código generado por el uso de la plataforma de hardware.Las empresas que han mostrado la longevidad durante ese período que recuerdo son:-

• AnyBus (HMS, www.anybus.com) recientemente hemos comenzado a utilizar sus productos de puerta de enlace como se puede colocar de bus de campo interfaces cerca del hardware y, a continuación, comunicarse a través de Ethernet normal (generalmente el uso de Ethernet/IP www.odva.org).Esto tiene la ventaja de separar el hardware y el PC con sólo un cable de red.La red Ethernet/IP .NET clases fueron escritos por nosotros mismos, no hay mucho que estaba en el mercado en el momento.Estoy seguro de que una rápida búsqueda en google a encontrar adecuado de bibliotecas de clase
• SST (www.mysst.com) han tenido interfaces de bus de campo durante más de una década.El último de SST de tarjeta que utiliza para DeviceNET sólo había VB6 código de ejemplo.Una buena selección de bus de campo, apoyo y diferentes factores de forma por ejemplo,PC104, PCI, PMCIA
• Beckhoff/Wago (www.beckhoff.com, www.wago.com) normalmente utilizamos Beckhoff para el I/O más de las tarjetas de interfaz, pero de nuevo una compañía que ha estado alrededor por un largo tiempo.También tienen productos que apoyan exponiendo usando OPC (otra manera de obtener información sobre e/S sin comunicarse directamente con el hardware/devicedrivers)

No sugiero el uso de OPC interfaces con el hardware directamente (es OK para la comunicación usando el PC (.NET)->PLC->Profibus) como usted necesita para asegurarse de que el sistema de control responde a la pérdida de control de su .NETO de la aplicación.Estoy asumiendo que usted está necesitando un Maestro profibus aquí (no un esclavo), así como su sistema de control es intrínsecamente a prueba de fallos, luego de la pérdida de comunicación significa que el sistema de control entra en un estado "Inactivo" y por lo tanto la mayoría de las I/O volverá a la falla de estado de seguridad.

También tratamos de garantizar que no se ponga la seguridad relacionados con el código .NET.La mayoría de nuestros .NET de código es userinterface de un PLC, pero en algunos lugares, que hacer control de bus de campo directamente, pero asegúrese de que el hardware de los dispositivos de enclavamiento evitará la onu-operación segura, ya sea utilizando los interruptores de seguridad/relés o un pequeño PLC con la tarea de enclavamiento sólo. Y, sobre todo, hacer que el sistema a prueba de fallas! Pérdida de comunicaciones de la .NET de código debería apagar la automatización para el estado a prueba de fallos.

Answer 2

Hemos utilizado carrera de obstáculos para conectarse a nuestra red profibus a nuestro automatizado de selección del sistema.

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

Answer 3

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