
Benvenuto Visitatore ( Log In | Registrati )
![]() ![]() |
21/07/2004, 13:18
Messaggio
#1
|
|
|
Nuovo utente ![]() Gruppo: Utenti PLCforum Messaggi: 2 Iscritto il: 21/07/04 Utente Nr.: 13059 |
qualcuno è in grado di spiegarmi qual'è la differenza tra back up caldo e freddo per un PLC? Non sono un programmatore, ma ho dovuto acquistare unPLC Rockwell SLC500 per un impianto in cui lavoro, dopo alcuni mesi di funzionamento sono nati alcuni problemi nella gestione delle schede analogiche. La risposta che mi è stata data è che il PLC gestisce la ridondanza delle CPU via sw (ovvero back up freddo) anzichè hw (back up caldo) e ciò crea un conflitto con i tempi di aggiornamento sulla lettura di valori. Premesso che vista la mia cultura in materia posso creder e a qualunque cosa, è possibile che un back up freddo posa creare tali anomalie? Grazie in anticipo. |
|
|
|
21/07/2004, 14:12
Messaggio
#2
|
|
![]() Utente con >1600 post Gruppo: Forum Card Member Messaggi: 1972 Iscritto il: 28/08/02 Da: Gorizia Utente Nr.: 9 |
ciao
le schede analogiche e le schede speciali in genere lavorano con una loro cpu e quando il micro centrale chiede il dato non fa nullaltro che darglielo!! attraverso il bus condiviso con le altre schede. io non ho avuto mai un problema con le analogiche della seria slc500 che sono delle ottime cpu . si puo' immaginare che a tuttoggi una azienda come rockwell non vada a mettere in commercio sistemi cosi' zoppicanti. e considerando che la serie slc500 non e' nuovissima si puo' immaginare che sia ultracollaudato (ne sono certo) per quantoriguarda il backup ....non capisco a cosa tu ti riferisca.! ma ricorda che la velocita' con la quale si possano leggere le analogiche e' modesta ma contrattempi con le cpu non ci possono essere. ciao dario Messaggio modificato da Dario Valeri il 21/07/2004, 14:18 |
|
|
|
22/07/2004, 18:56
Messaggio
#3
|
|
![]() Utente con >150 post ![]() ![]() ![]() ![]() Gruppo: Utenti PLCforum + Messaggi: 318 Iscritto il: 27/06/04 Da: Loano (SV) Utente Nr.: 12295 |
Normalmente si intende per backup caldo (oppure hot standby) un sistema hardware per cui un PLC è dotato di due CPU che eseguono lo stesso codice in modo sincrono, cioè simultaneamente. Solo una delle due CPU destina il proprio output d'elaborazione alle periferiche di I/O attraverso il bus comune. In caso d'avaria della CPU normalmente in servizio, la CPU di riserva subentra nella gestione del sistema senza perdere neanche un'istruzione del codice in esecuzione prima del guasto. In altre parole se la prima CPU si blocca dopo aver eseguito lo step 500 del program counter, la seconda prende il controllo dallo step 501 in avanti, senza alterare il contenuto dell'area di memoria.
Questa è la teoria, in realtà credo ci siano diversi sistemi di gestire l'hot standby da un punto di vista hardware: ho usato sistemi di questo tipo alcune volte ma non ho mai approfondito più di tanto. Per me è sufficiente che se una CPU schiatta, l'altra riprenda il controllo come se nulla fosse successo! Nel caso del backup freddo (oppure cold standby), la prima CPU si "pianta" e la seconda riprende dall'inizio del programma. In questo caso potrebbero essere necessarie alcune cautele in funzione del tipo di macchina o impianto gestiti. Tornando al tuo problema, mi sembra di capire che il tuo SLC500 sia dotato di due CPU. Credo che effettivamente la serie SLC500 non gestisca l'hot standby. Si poteva fare sicuramente su PLC5, forse su ControlLogix. A prescindere da questo, non comprendo esattamente quale sia il problema sulle analogiche. Forse perdi una lettura dei valori di conversione in concomitanza dello scambio fra le due CPU? Ciao. |
|
|
|
23/07/2004, 12:32
Messaggio
#4
|
|
|
Nuovo utente ![]() Gruppo: Utenti PLCforum Messaggi: 2 Iscritto il: 21/07/04 Utente Nr.: 13059 |
in partenza il PLC,dotato di 2 CPU, comunicava con un PC di supervisione attraverso una porta seriale. Chiaramente questo tipo di comunicazione, molto lenta, non permetteva al PC di effettuare una scansione dei segnali soddisfacente, per cui si è optato per una comunicazione tramite porta ethernet. Da allora, in modo del tutto occasionale (1giorno, 1 settimana, ecc.), accade che le letture provenienti dalle schede analogiche abbiano dei picchi, in realtà inesistenti, che superano le soglie di allarme impostate e generano delle fermate di sicurezza dell'apparecchiatura controllata. Analizzando i trend storici si vede che tali picchi durano qualche secondo (circa l'intero tempo di scansione dei segnali analogici). Attivando una singola CPU, anzichè 2, il problema non sussiste. Come ho già detto questo argomento non è il mio pane, sto riportando le informazioni che mi sono state comunicate e spero di non aver preso qualche abbaglio.... L'unica cosa certa è che il PLC non funziona come dovrebbe!!! Grazie ancora a tutti per l'interessamento. |
|
|
|
25/07/2004, 11:40
Messaggio
#5
|
|
![]() Utente con >150 post ![]() ![]() ![]() ![]() Gruppo: Utenti PLCforum + Messaggi: 318 Iscritto il: 27/06/04 Da: Loano (SV) Utente Nr.: 12295 |
Se sei certo che il problema non si presenti utilizzando un'unica CPU, direi che sei di fronte ad un bel problema. Se alla Rockwell non sono in grado d'aiutarti, opterei per il taglio della testa del toro.
Se il tuo processo lo permette (ovvero se la macchina controllata non è interessata da malfunzionamenti), filtrerei a livello software il risultato della conversione delle tue analogiche ed i relativi bit di underflow, overflow, broken-wire e via discorrendo. Campionerei un certo numero di misure escludendo quelle al di fuori dei limiti a condizione che la permanenza al di fuori dei limiti non sia superiore ad un certo tempo (diciamo qualche secondo). Dopo darei in pasto al sistema la media delle misure entro i limiti, oppure la misura più alta, oppure la più bassa, oppure l'ultima effettuata. oppure la prima effettuata... insomma, scegli tu. Se il dato permane al di fuori dei limiti per un tempo superiore a qualche secondo (oppure se il numero di campionamenti presumibilmente errati è superiori a quelli presumibilmente corretti) abiliterei i relativi flag d'errore e arresterei la macchina. E' una cosa che faccio normalmente nei processi lenti. Un underflow o un overflow (under range od over range, chiamalo come vuoi) che non permanga per almeno 5 secondi non viene considerato errore. E' anche un modo per levarsi dalle ba##e gli spikes e i disturbi captati dallo strumento o dalla sua linea di segnale quando l'impianto non è cablato in maniera ottimale. E' evidente che se si tratta di datori di posizione o comunque strumenti la cui misura deve essere comunicata con rapidità il mio discorso non vale. Quindi la A/B sostiene che c'è un problema di sincronismo nell'interrogazione delle analogiche da parte di un sistema a doppia CPU. Strano, pur conoscendola poco (avrò sviluppato al massimo cinque o sei sistemi su quell'hardware) ho sempre considerato lo SLC500 una macchina molto affidabile. Ciao. |
|
|
|
29/07/2004, 14:47
Messaggio
#6
|
|
|
Nuovo utente ![]() Gruppo: Utenti PLCforum Messaggi: 12 Iscritto il: 27/07/04 Utente Nr.: 13257 |
Ciao Fabri968, se posso intromettermi , bisognerebbe conoscere l'hardware che hai usato ( immagino cpu 505 ethernet) , e quale architettura di bus usi ( dh+ , rio , .....) , perche' se non sbaglio , il backup slc500 non supporta il backup della ethernet , quindi non vorrei , che il supervisore peschi i dati dall'ip..... che in quel momento non e' il primario.......
ciao ADAMS |
|
|
|
![]() ![]() |
|
Versione Lo-Fi | Oggi è il: 9/02/2010 - 09:27 |