2008-09-15 14 views

risposta

7

Noi non abbiamo usato Profibus, ma abbiamo usato DeviceNET (un altro protocollo basato su CAN), Ethernet/IP eControlNet che tutti hanno sfide simili.

Lo facciamo dalla fine degli anni '90 e quindi facciamo affidamento principalmente sul nostro codice generato utilizzando l'hardware standard. Le aziende che hanno dimostrato la longevità durante quel periodo che mi ricordo sono: -

  • AnyBus (HMS, www.anybus.com) abbiamo recentemente iniziato a utilizzare i loro prodotti di gateway come possiamo mettere interfacce bus di campo vicino l'hardware e poi comunicare su normale Ethernet (di solito usando Ethernet/IP www.odva.org). Questo ha il vantaggio di separare hardware e PC usando solo un cavo di rete. Le classi Ethernet/IP .NET sono state scritte da noi stessi in quanto al momento non c'era molto sul mercato. Sono sicuro che una rapida ricerca su google troverà librerie di classi adeguate
  • SST (www.mysst.com) hanno avuto interfacce bus di campo per più di un decennio. L'ultima scheda SST che abbiamo usato per DeviceNET aveva ancora solo il codice di esempio VB6. Una buona selezione di supporto per bus di campo e diversi fattori di forma, ad es. PC104, PCI, PMCIA
  • Beckhoff/Wago (www.beckhoff.com, www.wago.com) usiamo tipicamente Beckhoff per l'I/O più delle schede di interfaccia, ma di nuovo una società che è in circolazione da molto tempo. Essi hanno anche i prodotti che supportano l'esposizione tramite OPC (un altro modo per voi per ottenere I/O informazioni senza comunicare direttamente con l'hardware/devicedrivers)

io non suggerisco di usare interfacce OPC all'hardware direttamente (è OK per la comunicazione utilizzando PC (.NET) -> PLC-> Profibus) poiché è necessario assicurarsi che il sistema di controllo risponda alla perdita di controllo dall'applicazione .NET. Suppongo che tu abbia bisogno di un master profibus qui (non uno schiavo), quindi fintanto che il tuo sistema di controllo è intrinsecamente sicuro, la perdita di comunicazione dovrebbe significare che il sistema di controllo entra in uno stato "Idle" e quindi la maggior parte I/O tornerà allo stato di fail safe.

Cerchiamo anche di non inserire codice relativo alla sicurezza in .NET. La maggior parte del nostro codice .NET è interfaccia utente da un PLC, ma in alcuni punti controlliamo direttamente il bus di campo ma assicuriamo che gli interblocchi hardware impediscano operazioni non sicure, utilizzando interruttori/relè di sicurezza o un piccolo PLC con il solo compito di interblocco . E soprattutto rende il sistema sicuro! La perdita di comunicazioni dal codice .NET deve arrestare l'automazione allo stato di sicurezza.

+0

Grazie per il tuo commento, buoni suggerimenti. Potrei aggiungere che dichiarare che tutto dovrebbe essere sicuro è un po 'ridondante, dato che il fail safe non dovrebbe essere il compito del PLC. (A meno che non stiate sborsando un sacco di soldi per un PLC di sicurezza) – GEOCHET

Problemi correlati