Profinet, ethernet, industrial ethernet

[plfrmcmp83]

Buona sera,

Vorrei fare un po' di chiarezza circa le reti in oggetto. Avete qualche documento da consigliare? Alcuni dubbi:

-profinet, ethernet e industrial ethernet si possono definire bus di campo?

-connettori e cavi industrial ethernet possono essere utilizzati in reti profinet?

-profinet usa sempre e solo 4 conduttori mentre industrial ethernet ne usa 8?

-differenze tra ethernet ed industrial ethernet?

 

Grazie

[rguaresc]

In breve
Ethernet e' un protocollo di comunicazione nato per trasferire file tra PC. Come tale non e' un bus di campo. Un bus di campo industriale deve assicurare che i comandi siano eseguiti entro un tempo stabilito ed avere il riscontro di questo.
Con l'espressione Ethernet industriale si intende un insieme di due protocolli: Ethernet che trasporta i dati ed un secondo protocollo che provvede ad eseguire il comando controllandone l'esecuzione. Questo secondo protocollo, che di solito non viene nominato,  non e' unico e quindi gli abbinamenti di ethernet industriale vengono denominati in modo diverso: Profinet, EtherNet/IP, Modbus/TCP ecc.
La comunicazione e' assicurata tra partner dello stesso tipo, cioe' tutti Profinet, oppure tutti EtherNet/IP ecc.

E' ingannevole (trucco commerciale?) parlare semplicemente di Ethernet industriale, perche' la comunicazione e' possibile solo se i due protocolli coincidono. 

[Marco Mondin]

Cambiano anche i livelli su cui girano. Solitamente i BUS di campo con cui ho lavorato si sostituiscono ai due livelli TCP e IP(Sono due livelli distinti che girano sopra ethernet) o UDP e IP(Idem come sopra), usando direttamente frames ethernet.
Lavorano ad un livello abbastanza basso, questo gli permette di essere più affidabili del TCP in applicazioni industriali e con trucchetti vari permettono anche di essere deterministici (Ethercat, powerlink, profinet irt). Se non servisse il determinismo, per assurdo UDP sarebbe affidabile quanto profinet, ethercat, powerlink etc.
Quello che rende poco sicuro il TCP è che se non cade la connessione fisica tutti i pacchetti arrivano a destinazione a discapito della latenza. Tale latenza in applicazioni indurtriali potrebbe essere inaccettabile, mentre per internet è una manna, in quanto al limite un pacchetto arriva qualche secondo dopo ma arriva. UDP è già più simile ad un BUS di campo un po' più "RAW", un pacchetto che non arriva a destinazione o arriva corrotto è perso e basta. Al ciclo successivo arriverà quello corretto come in un qualunque BUS di campo in cui una certa soglia di pacchetti persi deve essere accettabile.

I problemi di UDP rispetto ai BUS di campo industriali, sono che tale protocollo è come una base di un BUS di campo da dover implementare ad un livello più alto e va organizzato (Possono coesistere tanti "master" e potrebbe essere un casino per le collisioni in reti molto complesse).
Modbus/TCP gira a livello applicativo, ancora sopra TCP, questo lo rende pesante per le CPU e meno affidabile in reti complesse, anche se devo dire che in reti semplici mi è capitato di usarlo trasmettendo 116 Word e ricevendone altrettante ogni 5-6 ms.
Un esempio di un protocollo che usa UDP abbastanza affidabile è il FINS di OMRON.

 

UDP lo uso per sincronizzare aree di memoria tra apparecchiature, ed è molto efficiente ed affidabile. Per esempio in C su pcl che ne permettano l'uso come (B&R) e in C o C++ su un PC(come faccio per esempio io) definisco due coppie di strutture dati:

 

Sul PC:

struct DataToPLC { 
   unsigned char byte1,
   unsigned char byte2,
   unsigned char byte3,
   unsigned char byte4,
};

struct DataFromPLC{
   unsigned char byte1,
   unsigned char byte2,
   unsigned char byte3,
   unsigned char byte4,
   unsigned char byte5,
   unsigned char byte6,
   unsigned char byte7,
   unsigned char byte8,
};

Sul PLC:

struct DataFromPC {
   unsigned char byte1,
   unsigned char byte2,
   unsigned char byte3,
   unsigned char byte4,
};

struct DataToPC{
   unsigned char byte1,
   unsigned char byte2,
   unsigned char byte3,
   unsigned char byte4,
   unsigned char byte5,
   unsigned char byte6,
   unsigned char byte7,
   unsigned char byte8,
};

Sul PLC ad ogni intervallo di 5mS(o un intervallo arbitrariamente scelto) invio un pacchetto UDP con la struttura serializzata, quando ricevo quello dal PC invece scrivo il pacchetto serializzato sulla struttura.
Sul PC appena ricevo il pacchetto del PLC lo deserializzo sulla struttura e immediatamente invio l'altra serializzata.

Così detta i tempi il PLC, se lavoro con linux sul PC ed uso un kernel RT, posso anche far dettare i tempi al PC con degli high precision timers (E' persino più preciso del PLC).
 

Premetto che non uso nomi come byte1, 2 3 e 4, l'esempio di sopra è solo per scopo didattico, in realtà le strutture le definisco con dati di svariate dimensioni e nomi significativi.
Si deve solo fare molta attenzione al'allineamento a 16, 32 o 64bit dei due interlocutori.

 

Se a scopo di curiosità può servire sotto metto un esempio reale:

  

struct DataToBeR {
    quint16 controlWordFrontSignals1; //This bits require an ACK in statusWordAckFronts1
    quint16 controlWordFrontSignals2; //This bits require an ACK in statusWordAckFronts2
    quint16 controlWordAckFronts1;    //Response ACK to statusWordFrontSignals1
    quint16 controlWordAckFronts2;    //Response ACK to statusWordFrontSignals2
    quint16 controlWordStaticSignals1;//Bits of static signals to B&R (No ACK needed)
    quint16 controlWordStaticSignals2;//Bits of static signals to B&R (No ACK needed)
    quint16 knotID;                   //Id of knot
    quint8  generalFeed;              //General feed percentage
    quint8  pickId;                   //ID of pick conveyor
    quint16 palletID;                 //ID of current pallet
    quint16 free1;                    //FreeData
    quint16 free2;                    //FreeData
    quint16 free3;                    //FreeData
    double  knotsX;                   //Double coordinate knots
    double  knotsY;                   //Double coordinate knots
    double  knotsZ;                   //Double coordinate knots
    double  homeParameterX;           //Double coordinate knots
    double  homeParameterY;           //Double coordinate knots
    double  homeParameterZ;           //Double coordinate knots
    double  jogSpeed;                 //Speed jog
};

struct DataFromBeR {
    quint16 statusWordFrontSignals1; //This bits require an ACK in controlWordAckFronts1
    quint16 statusWordFrontSignals2; //This bits require an ACK in controlWordAckFronts2
    quint16 statusWordAckFronts1;    //Response ACK to controlWordFrontSignals1
    quint16 statusWordAckFronts2;    //Response ACK to controlWordFrontSignals2
    quint16 statusWordStaticSignals1;//Bits of static signals from B&R (No ACK needed)
    quint16 statusWordStaticSignals2;//Bits of static signals from B&R (No ACK needed)
    quint16 freeData0;
    quint16 freeData1;
    double realTimeQuoteX;
    double realTimeQuoteY;
    double realTimeQuoteZ;
    quint8 errorString[SZ_ERROR_STR];
};

 

free1, free2, free3, freeData0 e freeData1 servono per allineare i dati a 64bit e dormire sonni tranquilli qualunque sia il peer.