Rete Profibus - diagnostica

[MrC]

Rete profibus:

Mi sto informando su come impostare una rete profibus composta da

MASTER CPU 412-2

SLAVE: 4 INVERTER MM440, 2 OP170B, 2 MISURATORI DI PESO;

Una volta configurata la rete con Step7, chiaramente funziona tutto bene,

ma cosa succede se ad esempio si spegne un pannello, a un inverter ?

In genere, voi come gestite la diagnostica ?

Pensavo di usare gli OB e le SFC di sistema, quali mi consigliate ?

Oltre all'eventuale spegnimento/guasto di uno slave, ci sono altre problematiche da valutare?

Grazie

[athos]

A livello di sicurezza è prescritto che in caso di avaria della rete Profibus venga immediatamente arrestato l'inverter.

E' anche logico che così sia fatto in quanto perdo completamente il controllo dell'oggetto.

Questa funzione viene abilitata nella configurazione dell'inverter stesso.

Per quanto riguarda gli slave DP (ET200M/S..) può essere diagnosticato lo stato e la funzionalità con FC std Siemens GLOBAL_DP_DIAG, poi, in funzione del tipo e/o utilizzo del nodo, si può decidere il da farsi (solo allarme, stop PLC ...)

Athos

[Gne]

Gli OP inseriti in un PROFIBUS non sono slave ma MASTER che non dispongono di periferia.

Infatti non devono essere configurati nell'hardware del "master", semplicemente quando il "gettone" tocca aloro, tramite le funzioni S7 (quelle del PG), interrogano la CPU.

L'unica cosa che richiedono alla CPU con cui comunicano e' la occupazione di una risorda di comunicazione.

Per quanto riguarda il controllo del corretto collegamento CPU<->OP esistono alcuni bit nell'area di interfaccia.

[Matteo Montanari]

come sfc standard ne hai uno che controlla la comunicazione con i vari nodi profibus inseriti nella rete SFC13

riguardanti comunicazione con rete profibus hai i seguenti SFC:

SFC 7: Attivazione di un interrupt di processo nel master DP con la SFC 7 "DP_PRAL"

SFC 11: Sincronizzazione di gruppi di slave DP con la SFC 11 "DPSYC_FR"

SFC 13: Lettura di dati di diagnostica (diagnostica slave) di uno slave DP con la SFC 13 "DPNRM_DG"

SFC 14: Lettura di dati coerenti di uno slave DP standard con la SFC 14 "DPRD_DAT"

SFC 15: Scrittura in modo coerente di dati utili ad uno slave DP standard con la SFC 15 "DPWR_DAT"

Personalmente utilizzo SFC 13 con impostazione del relativo Nodo che mi interessa controllare, se non è in comunicazione con il PLC viene generato un BIT di allarme, che utilizzo sul pannello operatore (collegato in MPI)

i pannelli hanno un bit di stato, normalmente viene modificato ogni secondo o 1/2 secondo, puoi eventualmente analizzare la variazione di questo bit, nel caso sia alto o basso per troppo tempo, allora hai un problema di comunicazione con il pannello interessato.

[emanuele.croci]

Io uso anche il OB86, che viene richiamato dal sistema ogni volta che "perdi" o "ritrovi" un nodo

(ovviamente ti dice anche di che nodo si tratta).

Così facendo so se qualche slave ad esempio è spento.

Ciao, Emanuele

[beppeconti]

Io di solito faccio cosi con PLC S7-300:

Nel OB86 vado a intercettare l'allarme sul profibus leggendo il contenuto della variabile #OB86_FLT_ID, se ha un valore diverso da zero allora c'è un allarme GENERICO sul profibus.

Successivamente nel blocco dove gestisco lo scambio dati con i drives Siemens vado a verificare quale slave è in allarme andando a leggere la risposta che ricevo ad ogni scambio dati.

Per esempio:

chiamo la routine di scrittura dei dati coerenti sul profibus

CALL SFC 15

___LADDR := indirizzo PZD dello slave profibus

___RET_VAL:= risposta ricevuta dallo slave

___RECORD := area dati di scrittura verso lo slave

chiamo la routine di lettura dei dati coerenti dal profibus

CALL SFC 14

___LADDR := indirizzo PZD dello slave profibus

___RET_VAL:= risposta ricevuta dallo slave

___RECORD := area dati di lettura dallo slave

leggo le due risposte, se valgono 0 allora tutto è ok, altrimenti c'è un errore sul profibus dello slave

CIAO

[walterword]

l'SFC13 puo esserti d'aiuto , gli passi in esadecimale l'indirizzo di diagnostica ( di solito il primo per default e' 1022 che in esa e' w#16#3FE .poi appoggi almeno 6 byte che ti restituisce l'SFC su un'area (p#m0.0 byte 6)

e confronti come ti e' stato detto sopra.

ci sono anche 3 bit mappati da qualche parte che ti danno lo stato dello slave , alimentazione ok , mancanza e altro.

ciao

walter

[Ospite Lucarossi82]

Scusate...

Questo messaggio è stato cancellato perchè non conforme al regolamento del forum

Modificato: 5 maggio 2004 da Livio Orsini

[beppeconti]

x bebbeconti :Ho tolto il riferimento!

E questo cosa centra con l'argomento della discussione?

considera che le prestazioni sono 20 volte superiori alle attuali macchine PLC

Sei un pò generico, 20 volte superiori rispetto a quale PLC e a quale CPU. Le prestazioni non sono tutto in un PLC vanno presi in considerazione anche altri fattori.

CIAO

Modificato: 5 maggio 2004 da Livio Orsini

[emanuele.croci]

Questi portenti di cui parli gli onnipresenti venditori non me li hanno ancora presentati.

Non ho nemmeno visto nelle fiere cartelloni a caratteri cubitali con scritto "accorrete!!! è arrivata la rivoluzione nei PLC!!!"

Quindi nel merito non posso risponderti, sono disinformato....

tuttavia dimmi: nei PLC...

...che fetta di mercato ha Siemens?

...che fetta di mercato ha GE?

...tutti pirla?

Ciao, Emanuele

[lele65]

Nel OB86 vado a intercettare l'allarme sul profibus leggendo il contenuto della variabile #OB86_FLT_ID, se ha un valore diverso da zero allora c'è un allarme GENERICO sul profibus.

Nell' OB86_RACKS_FLTD c'è anche l'indirizzo della stazione che va in fault e se controlli anche gli eventi uscenti dice anche quando torna il collegamento.

Ho provato con una stazione e funziona, non sò con + stazioni come si comporta.

Saluti

[emanuele.croci]

Sì, è proprio così:

il parametro OB86_EV_CLASS (byte 0 dei parametri di passaggio OB86) ti dice quale evento è capitato:

W#16#39 (cioè 39 esadecimale)= hai perso lo slave

W#16#38 (cioè 38 esadecimale)= è tornata lo slave

il parametro OB86_Z23 (in realtà non è il suo nome "originale" ma Siemens consiglia di rinominarlo così nel suo esempio, comunque sto parlando della DWORD all'indirizzo 8 dei parametri di passaggio) ti dice di quale slave stiamo parlando, identificato con il suo numero di nodo profibus.

Funziona bene, anche con più stazioni, testato.

Ad es. la mia routine fa + o - così....

L #OB86_EV_CLASS

L W#16#39

<>I

SPB fine

//Errore in arrivo (39H)

SET

S M 86.6 //Errore sul profibus

//Leggo la stazione in errore

L #OB86_Z23

T MD 88

//Errore MasterDrive al nodo 21

SET

L MB 91

L 21

==I

S M 86.0 //Errore MD al nodo 21

SPB fine

//Errore scheda ingressi al nodo 22

SET

L MB 91

L 22

==I

S M 86.1 //Errore scheda ingressi al nodo 22

SPB fine

//.... qui posso continuare con tutti i nodi che voglio...

Ciao, Emanuele

Modificato: 5 maggio 2004 da emanuele.croci

[beppeconti]

x lele65 e emanuele.croci

Io in realtà faccio una gestione più semplice andando direttamente a verificare se lo scambio dati va o no.

La gestione fatta tutta nell'OB86 come descritta da voi mi sembra però la più corretta.

Grazie per le info

CIAO

[lele65]

Se perdo 2 stazioni contemporaneamente (rottura cavo profibus) l'OB86 viene elaborato 2 volte consecutive?

Prima mi dà l'indirizzo di 1 stazione poi alla seconda elaborazione quello della seconda??

Saluti

[emanuele.croci]

secondo me sì, penso che sia chiamato ogni volta che il master interroga una stazione e non la trova...

però non ho mai provato, quindi è da testare.

Ciao, Emanuele