Fieldbus – Parte generale
Terminologia
Il telegramma di output è il telegramma specifico del protocollo (PDO di sicurezza) dal controllore di sicurezza al dispositivo di campo sicuro. Questo telegramma contiene i dati di output al dispositivo di campo sicuro. | |
Il telegramma di input è il telegramma specifico del protocollo (PDO di sicurezza) dal dispositivo di campo sicuro al controllore di sicurezza. Questo telegramma contiene i dati di input dal dispositivo di campo sicuro. | |
Istanza driver: per ogni I/O logico configurato, viene creato un codice per un'istanza driver del tipo di protocollo supportato (ad esempio, un'istanza driver di tipo |
Descrizione dell'interfaccia
Il controller di sicurezza monitora la trasmissione dei dati I/O da e verso il dispositivo di campo sicuro. Un I/O logico viene generato dal sistema di sviluppo per ogni dispositivo di campo sicuro. Un'istanza del driver viene creata automaticamente per ogni dispositivo logico.
Con la creazione dell'istanza del driver, viene generato un codice implicito che produce quanto segue per le variabili di input o output:
Fase 1 (fase di input): elaborazione dei telegrammi di input (impliciti)
L'istanza del driver riceve il telegramma di input e lo verifica in base alle specifiche del protocollo, ad esempio PROFIsafe.
I dati di input o, in caso di errore, i valori sostitutivi vengono copiati nelle variabili di input mappate dell'applicazione.
Fase 2: Elaborazione della domanda utente
I dati di output vengono generati in base ai dati di input e allo stato dell'applicazione.
Fase 3 (fase di output): elaborazione dei telegrammi di output (impliciti)
I dati di output mappati dell'applicazione vengono consegnati all'istanza del driver. L'istanza del driver genera il telegramma di output in conformità con la sua specifica di protocollo e lo invia al dispositivo di campo sicuro.
Comportamento predefinito del driver
Avviso Drv_1 (avvio dell'applicazione)
Quando l'applicazione viene avviata, può accadere che a partire dal primo ciclo i dati di processo vengano scambiati tra il campo e l'applicazione. L'uso di FB con un blocco di avvio (S_StartReset = FALSE) o l'implementazione di altre misure di sistema e di applicazione (vedere Manuale utente sulla sicurezza. "Regole per l'utilizzo di blocchi funzione conformi a PLCopen") garantisce che non si verifichi alcun avvio imprevisto (o involontario) della macchina all'avvio dell'applicazione.
Avviso Drv_2 (errore di comunicazione all'avvio)
Di default, i soliti errori di comunicazione all'avvio non impediscono l'avvio automatico della comunicazione dei dati di processo. Invece, viene solo ritardata. Vedere Input per il riconoscimento automatico degli errori di avvio (errore di avvio automatico).
Il comportamento predefinito del driver per l'avvio dopo un reset o per il riavvio dopo un errore di comunicazione è definito dal valore iniziale del rispettivo input. Per sovrascrivere il comportamento predefinito, il blocco funzione nell'applicazione deve essere chiamato e il rispettivo input deve essere impostato di conseguenza:
L'avvio automatico della trasmissione dei dati di processo dopo l'avvio viene impedito dal programma richiamando il blocco funzione nell'applicazione e impostando l'input errore di avvio automatico A FALSE (Vedere. Input per il riconoscimento automatico degli errori di avvio).
La ripresa automatica della trasmissione dei dati di processo viene abilitata dal programma richiamando il blocco funzione nell'applicazione e impostando l'ingresso interruzione automatica di riconoscimento ingresso a TRUE (Vedere. Input per il riconoscimento automatico dopo l'interruzione).
Input per il riconoscimento automatico degli errori di avvio
Nome | Tipo di dati | Valore iniziale | Descrizione, valori dei parametri |
|---|---|---|---|
<errore-di-avvio-auto-ack> |
|
| Comportamento all'avvio dopo un reset (comandi: Ripristino a freddo – Sicurezza E Ricomincia) dell'applicazione, ad esempio PowerON.
|
Importante
notare che Avviso Drv_2 (errore di comunicazione all'avvio): Il valore iniziale per l'input per il comportamento di avvio dopo un ripristino è TRUETutti gli errori relativi al comportamento all'avvio vengono riconosciuti dopo un ripristino.
Quindi la comunicazione dei dati di processo inizia non appena l'errore di comunicazione iniziale è scomparso.
Importante
notare che Avviso Drv_1 (avvio dell'applicazione): Collocamento errore di avvio automatico A FALSE non impedisce l'avvio automatico della comunicazione dei dati di processo. Se non si verificano errori durante l'avvio, lo stack può avviarsi automaticamente, anche se errore di avvio automatico è impostato su FALSEL'utente deve tenerne conto nella domanda.
Input per il riconoscimento automatico dopo l'interruzione
Nome | Tipo di dati | Valore iniziale | Descrizione, valori dei parametri |
|---|---|---|---|
<interruzione-auto-riconoscimento> |
|
|
|
Avviso Drv_3 (input per conferma automatica dopo interruzione)
Attenzione
Se <errore-di-avvio-auto-ack> E <interruzione-auto-ack> Sono TRUE, allora tutti gli errori vengono riconosciuti. Ciò è sensato solo in alcuni casi eccezionali.
Comportamento di riavvio dopo un errore di comunicazione
Il valore iniziale per l'input per il comportamento di riavvio dopo un errore di comunicazione è FALSE; l'errore relativo alla trasmissione della comunicazione non viene riconosciuto automaticamente.
È necessaria una chiamata esplicita dell'istanza del blocco funzione con la corrispondente connessione degli ingressi.
Input per il bordo di conferma (conferma manuale)
Gli errori possono essere riconosciuti con un fronte positivo sull'input per la conferma, a condizione che (output per la richiesta di conferma) è impostato.
Se tutti gli errori vengono riconosciuti automaticamente (cosa sensata solo in casi eccezionali), questo input non è necessario e può rimanere scollegato.
Se al momento non è richiesta alcuna conferma, l'input viene ignorato: pertanto lo stesso segnale può essere collegato all'input per il fronte di conferma di tutte le istanze del driver per realizzare una conferma non specifica dei problemi di comunicazione.
Nome | Tipo di dati | Valore iniziale | Descrizione, valori dei parametri |
|---|---|---|---|
<ack-bordo> |
|
| La ripresa della funzione di sicurezza viene confermata dopo un errore con un fronte di salita sull'ingresso. |
Avviso Drv_4 (ack-edge)
Attenzione
IL <ack-bordo> l'input è utilizzato per il riconoscimento da parte dell'utente. Non deve essere impostato dal programma, ma collegato con un segnale di input.
Suggerimento
IL <ack-bordo> l'input richiede un fronte di salita. Dopo che l'utente ha interrotto la conferma, dovrebbe andare FALSE nuovamente per concludere la conferma. Solo allora viene richiesta la conferma successiva all'ingresso <richiesta-riconoscimento> al prossimo errore di comunicazione.
Output per richiesta di conferma
L'uscita è TRUE se si è verificato un errore di comunicazione (errore di avvio o interruzione) e questo deve essere solo confermato manualmente per riprendere la comunicazione.
Se l'uscita <richiesta-riconoscimento> È TRUE, quindi la connessione richiede una conferma da parte dell'utente. Normalmente l'utente viene informato che la sua conferma è richiesta (ad esempio con l'ausilio di una variabile di scambio al controller standard e visualizzata nella visualizzazione)
Se l'uscita è impostata, l'errore può essere riconosciuto all'ingresso per la conferma.
Nome | Tipo di dati | Valore iniziale | Descrizione, valori dei parametri |
|---|---|---|---|
<richiesta-riconoscimento> |
|
|
Suggerimento
Il display in uscita richiesta di conferma può aver luogo solo se:
L'errore di comunicazione non viene riconosciuto automaticamente, vale a dire se <errore-di-avvio-auto-ack> O <interruzione-auto-ack> È
FALSE.IL <ack-bordo> l'input è attualmente
FALSE, vale a dire se è stata avviata una conferma manuale ma non ancora conclusa.
Pertanto, se si verifica un nuovo problema di comunicazione mentre l'utente sta ancora riconoscendo un problema verificatosi in precedenza, il nuovo problema di comunicazione verrà visualizzato ed elaborato solo dopo che l'utente avrà completato il riconoscimento del problema precedente.
Chiamata esplicita del blocco funzione
Se il blocco funzione viene esplicitamente chiamato dall'utente nell'applicazione (fase 2), allora gli input del blocco funzione possono essere impostati e gli output del blocco funzione possono essere letti, sebbene il blocco funzione stesso non esegua alcuna operazione. Per ogni istanza del driver, può esserci al massimo una chiamata nell'applicazione.
Gli output del blocco funzione dell'istanza del driver possono essere letti indipendentemente da una chiamata.