Pergunta

Alguém já falou com sucesso profibus de um aplicativo .NET?

Se sim, que dispositivo/cartão você usou para fazer isso, qual era o aplicativo e você usou algum tipo de código pré-existente ou disponível?

Foi útil?

Solução

Não usamos Profibus, mas usamos DispositivoNET (outro protocolo baseado em CAN), Ethernet/IP e ControlNet que todos têm desafios semelhantes.

Fazemos isso desde o final da década de 1990 e, portanto, dependemos principalmente de nosso próprio código gerado usando hardware disponível no mercado.As empresas que demonstraram longevidade nesse período que me lembro são: -

  • AnyBus (HMS, www.anybus.com) recentemente começamos a usar seus produtos de gateway, pois podemos colocar interfaces fieldbus próximas ao hardware e então nos comunicarmos por Ethernet normal (geralmente usando Ethernet/IP www.odva.org).Isto tem a vantagem de separar o hardware e o PC usando apenas um cabo de rede.As classes Ethernet/IP .NET foram escritas por nós mesmos, pois não havia muita coisa no mercado na época.Tenho certeza de que uma rápida pesquisa no Google encontraria bibliotecas de classes adequadas
  • TSM (www.mysst.com) possuem interfaces fieldbus há mais de uma década.A última placa SST que usamos para DeviceNET ainda tinha apenas código de amostra VB6.Uma boa seleção de suporte a fieldbus e diferentes formatos, por ex.PC104, PCI, PMCIA
  • Beckhoff/Wago (www.beckhoff.com, www.wago.com) normalmente usamos Beckhoff para E/S mais do que para placas de interface, mas novamente uma empresa que já existe há muito tempo.Eles também têm produtos que suportam exposição usando OPC (outra maneira de obter informações de E/S sem se comunicar diretamente com o hardware/drivers de dispositivo)

Sugiro não usar interfaces OPC diretamente com o hardware (é aceitável para comunicação usando PC (.NET)->PLC->Profibus), pois você precisa garantir que o sistema de controle responda à perda de controle de sua aplicação .NET.Estou assumindo que você está precisando de um Profibus Master aqui (não de um escravo), portanto, desde que seu sistema de controle seja intrinsecamente à prova de falhas, a perda de comunicação deve significar que o sistema de controle entra em um estado "Inativo" e, portanto, a maior parte do A E/S retornará ao estado de segurança contra falhas.

Também tentamos garantir que não colocamos códigos relacionados à segurança no .NET.A maior parte do nosso código .NET é interface de usuário de um PLC, mas em alguns lugares controlamos o fieldbus diretamente, mas garantimos que os intertravamentos de hardware evitarão operações inseguras, seja usando interruptores/relés de segurança ou um pequeno PLC com a tarefa apenas de intertravamento . E acima de tudo, torne o sistema à prova de falhas! A perda de comunicação do código .NET deve desligar a automação para o estado à prova de falhas.

Outras dicas

Usamos o Steeplechase para conectar nosso profibus ao nosso sistema de coleta automatizado.

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

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top