Funzionamento FB15 PUT di Siemens Codice Errore

[anarchico]

Buongiorno,

su una linea di 8 banchi di lavorazione con una rete profinet organizzata con una CPU per ogni banco del tipo IM 151-8 CPU PN/DP,ve ne sono tre che comunicano in cascata tra di loro con le cpu per un handshake di informazioni per la produzione di pezzi in serie.

 

Ultimamente si è verificata una perdita di pezzi e quindi di informazioni da un banco ad un altro.Nella diagnostica di utilizzo dell'FB15 con il quale da dieci anni regolarmente un PLC passa le informazioni ad un altro tramite l'ID configurato,ho letto i due bit di uscita di error e status entrambi a 1 e dalla diagnostica siemens ho provato alcune manovre di ripristino suggerite,tipo cambio cavi,cambio cpu,ricarico db15 ecc ecc...ma il problema non si è risolto.Addirittura con il REQ a 1 il blocco non viene eseguito(come da file allegato).

 

Qualcuno ha mai trattato un problema simile?.La visualizzazionedel blocco non eseguito non mi preoccuperebbe,dato che lavora sul fronte di REQ e quindi capace non lo veda,ma i due bit di STATUS ed ERROR a 1?

 

Dalla diagnostica manuali siemens:

 

ERROR    STATUS (decimale)    Spiegazione
0    11    Avviso:·    Il nuovo job non è valido in quanto quello precedente non è ancora terminato.·    Il job viene già elaborato in una classe con priorità minore.
0    25    È stata avviata la comunicazione. Il job è in corso di esecuzione.
1    1    Problemi di comunicazione, ad es.·    descrizione del collegamento non caricata (locale o remoto)·    collegamento interrotto ( ad es. cavo, CPU spenta, CP in STOP)·    collegamento con il partner non ancora creato·    FB inon eseguibile su una  CPU S7-400·    inoltre per S7-300:-    numero massimo di ordini/istanze paralleli superato 

 

- Cosa intende per numero massimo di ordine/istanze paralleli superato?

- Dopo anni la cpu utilizzata potrebbe essere obsoleta o comunque con poca memoria?

- Cosa altro posso verificare?

 

Grazie mille

 

[84paolo]

hai per caso verificato, oltre a tutte le prove che hai già fatto che su ogni cpu, sulla diagnostica, risorse di collegamento ne hai qualcun libera o sono tutte utilizzate? se fossero tutte utilizzate e qualcun altro provasse a collegarsi non verrebbe accettato il collegamento.

poi dovresti spiegare meglio come é fatta l'architettura e la comunicazione

[anarchico]

abbastanza semplice......Su uno switch centrale è collegato ad un server di linea e da remoto si collega un server aziendale.

[anarchico]

abbastanza semplice......Su uno switch centrale è collegato ad un server di linea e da remoto si collega un server aziendale.

 

Tre banchi scambiano dati attraverso l'FB15 banco 6-7-8,...quindi lo scambio tra cpu non è tra tutti gli 8 banchi ma solo tra tre.

Io proprio il fatto che l'FB15 non venga eseguito non me lo spiego.

La logica prevede che un banco produca un pezzo e lo memorizzi in un buffer disponibile per il successivo al quale lo invia alzando un bit che si attende venga resettato dal banco successivo nel momento dell'acquisizione(proprio attraverso l'FB15),cosa che non avviene....o meglio avviene a volte si e a volte no con una frequenza altissima(ogni due tre pezzi).

 

 

[anarchico]

Altra cosa strana è che ora sto eseguendolo come prova con il PLCsim e comunque mi da il blocco FB15 già con error e status entrambi ad uno

[anarchico]

9 ore fa, 84paolo scrisse:

i qualcun libera o sono tutte utilizzate

64 totali 63  non utilizzate

Modificato: 17 novembre 2018 da anarchico

[84paolo]

ciao. non ho capito come fai ad avere 64 risorse di colleganento su cpu di alcuni hanni fa. di soliti le cpu hanno 8 o 16 risorse al massimo. hai verificato online?

[anarchico]

il 17/11/2018 at 13:46 , 84paolo scrisse:

i qualcun libera o sono tutte utilizzate

 

 

NO NON HO VERIFICATO.CREDO DOMANI.

 

A questo punto credo sia un problema di rete complessiva.

 

[pigroplc]

il 17/11/2018 at 09:42 , anarchico scrisse:

Nella diagnostica di utilizzo dell'FB15 con il quale da dieci anni regolarmente un PLC passa le informazioni ad un altro tramite l'ID configurato

Questo mi suggerisce di controllare i cablaggi, magari eliminando degli switch intermedi e collegando direttamente gli slave con un cavo esterno a tutto. Dalla diagnostica dei blocchi di comunicazione non riesci certo a diagnosticare il basso livello della comunicazione.

 

Se dal controllo precedente non ne esce nulla vuol dire che potrebbe essere qualcosa diagnosticabile scambiando le CPU. 

Modificato: 19 novembre 2018 da pigroplc

[anarchico]

il 19/11/2018 at 07:32 , pigroplc scrisse:

Questo mi suggerisce di controllare i cablaggi, magari eliminando degli switch intermedi e collegando direttamente gli slave con un cavo esterno a tutto. Dalla diagnostica dei blocchi di comunicazione non riesci certo a diagnosticare il basso livello della comunicazione.

 

Se dal controllo precedente non ne esce nulla vuol dire che potrebbe essere qualcosa diagnosticabile scambiando le CPU. 

 

 

Buongiorno,il problema è stato risolto proprio facendo un po' quello che mi suggerisci.Alla fine non venendone piu fuori ho collegato la comunicazione diretta tra i tre banchi 6-7-8 con cavi diretti in serie.Scollegandoli dal mega switch.Risultato:la comunicazione è ripresa,o meglio l'FB15 veniva di nuovo rieseguito ed error tornava a zero.

Chiaramente ora sto rifacendo fare tutta la rete con uno switch nuovo,perchè il problema sicuramente non è software.

Avevo proposto l'inserimento di uno scalance managed ancheper un giorno tenere conto del traffico su rete,con cavi e connettori profinet siemens.

Non hanno voluto sentire ragioni.

 

Pazienza.

 

Grazie mille a tutti per la disponibilità e l'attenzione pazienza mostrata.

 

[pigroplc]

2 ore fa, anarchico scrisse:

Buongiorno,il problema è stato risolto proprio facendo un po' quello che mi suggerisci

Allora serve a qualcosa avere i capelli bianchi..... 😁😁😁

[anarchico]

Aahahhahahahahahahahahahahah

 

Gia' averli i capelli.................poi bianchi......

 

 

[anarchico]

Buongiorno,

ripropongo questo topic perchè la situazione si sta ripresentando.Con una incidenza molto minore del caso iniziale di un anno fa,ma comunque presente.Si è ripresentata una leggera ma non ammissibile perdita di pezzi tra un banco ed un altro.Motivo per cui sono stato richiamato in ballo.L'assistenza siemens tra l'altro fa la gnorri su questi argomenti.

Di HW ricapitolando,è stato sostituito :

- lo switch centrale di accorpamento

- tutti i cavi della rete degli 8 banchi con connettori Siemens e cavi altresì

- una delle due cpu tra i due banchi che perdono dati(l'altra verrà fatta a breve ma temo non basti.Trattasi ripeto di una IM 151-8 CPU PN/DP)

- Sono stati messi anche degli switches di sostegno ad interno quadro per non sovraccaricare la CPU(switch che perogni banco raccolgono le varie utenze profinet pannello assi lettori ecc ecc)

 

Tutto cambiato ma l'errore comunque di bassa frequenza(non accettabile)comunque presente.Non saprei piu che cosa fare nella realtà e nemmeno se vale la pena aprireun ticket con siemens.Un dubbio mi è venuto proprio oggi pomeriggio.E ve lo propongo.

Potrebbe essere dovuto ad un sottodimensionamento della MMC o a problemi nascosti della stessa?

Vi spiego: secondo lo stabilimento il problema è iniziato quando abbiamo inserito sul primo banco che trasmette sul secondo un ulteriore controllo analogico (valvola proporzionale) che ad ogni ciclo salva 48 valori reali frutto di alcuni controlli.Cioè per loro si è talmente sovraccaricato il sistemache nel trasferimento si blocca.Per me è assurdo ma oramai devo credere a tutto.

Secondo la vostra esperienza come vi comportereste?

 

Domanda aggiuntiva:

SE volessi cambiare la MMC con una nuova o piu grande oltre al PG(che non ho nè hanno)come faccio a trasferirgli l'attuale MMC funzionante?Dovrei fareil giro assurdo:

- MMC Attuale Salva RAM in ROM

-Copia dall'online di tutti i blocchi comprese DB aggiornate e coerenti

-Riversare sulla CPU in cui ho inserito la nuova scheda il programma così salvato che automaticamente viene ricopiato sull'MMC.

Giusto?

 

E tra l'altro,

se dovessi mettere una MMC piu capiente,cambia qualcosa rispetto a questa procedura?

 

Grazie mille in anticipo.

 

[TravelMen]

Ciao

Quote

se dovessi mettere una MMC piu capiente

Potrebbe non cambiare nulla, perché la memoria dei DB risiede nella CPU, come scritto nel PDF

Quote

Grandezza della memoria ritentiva per blocchi dati ritentivi

64 kbyte

 

Questo te lo dico perché un cliente mi ha chiesto da raddoppiare dei DB di configurazione e per farlo ho duvuto cambiare CPU, mantendo la stessa MMC da 1M

Fai un controllo della memoria usata della CPU.

 

Saluti

[pigroplc]

15 ore fa, anarchico scrisse:

secondo lo stabilimento il problema è iniziato quando abbiamo inserito sul primo banco che trasmette sul secondo un ulteriore controllo analogico (valvola proporzionale) che ad ogni ciclo salva 48 valori reali frutto di alcuni controlli.

Inutile andare tanto lontano, come prima cosa io proverei a ritornare alla soluzione precedente a questa modifica, giusto per avere la certezza della causa che genera l'anomalia, 

quindi controllerei pure il tempo ciclo delle CPU, mica che girano troppo lente, poi cercherei di capire se si genera un errore di comunicazione mettendo un nuovo contatore di anomalie sulla stazione che spedisce.

[anarchico]

23 ore fa, pigroplc scrisse:

Inutile andare tanto lontano, come prima cosa io proverei a ritornare alla soluzione precedente a questa modifica, giusto per avere la certezza della causa che genera l'anomalia, 

quindi controllerei pure il tempo ciclo delle CPU, mica che girano troppo lente, poi cercherei di capire se si genera un errore di comunicazione mettendo un nuovo contatore di anomalie sulla stazione che spedisce.

Grazie mille a tutti innanzitutto.Gentilissimi.

Al momento mi manca di sostituire la CPU del primo banco che trasmette i dati,per completare l'opera di sostituzione completa HW. Si,sulla MMc avevo dei dubbi,non ricordando nello specifico il manuale.Da quanto mi scrivi credo sia un passo comunque da fare.

Quindi dalla tua esperienza mi dici che qualche probabilità concreta che sia stata la modifica della valvola proporzionale,esiste.

Si credo che tornare indietro e riprovare sia la soluzione piu' congrua.Fermo restando che essendo in produzione e con un discorso di tracciabilità e qualità aperto,è davvero un problema.

Il contatore va messo sui fronti dell'error dell'FB15 giusto?

Per assurdo supponiamo che il contatore conti un numero di errori del 10% delle trasmissioni, oppure supponendo di aver verificato che eliminando la modifica le cose tornano alla normalità,a quale soluzione potrei pensare?

Come accaduto nel caso di TravelMen,dovrei provare a mettere due CPU piu grandi?Se si,quali?

Difficilmente mi daranno il tempo per tornare indietro,la vedo come una cosa impossibile.

 

Grazie mille.

 

 

 

[pigroplc]

46 minuti fa, anarchico scrisse:

Fermo restando che essendo in produzione e con un discorso di tracciabilità e qualità aperto,è davvero un problema.

Mi rendo conto che la produzione abbia la precedenza, ma se vogliono risolvere il problema sarà meglio affontare una seria procedura di ricerca guasti. Ai clienti faccio sempre la metafora: se fori la macchina e non cambi la ruota e continui a girare prima o poi rompi il cerchione e il semiasse... vedi tu quando ti vuoi fermare!

Se prima andava e dopo la modifica c'è il problema nella mia ignoranza io una domanda me la faccio.

50 minuti fa, anarchico scrisse:

Il contatore va messo sui fronti dell'error dell'FB15 giusto?

giusto

 

54 minuti fa, anarchico scrisse:

Difficilmente mi daranno il tempo per tornare indietro,la vedo come una cosa impossibile.

Almeno cerca di affrontare la cosa irrobustendo il codice, ovvero in caso di errori di comunicazione rallenta qualcosa o accertati che le informazioni siano acquisite prima di passare alla fase successiva.

 

[anarchico]

1 ora fa, pigroplc scrisse:

Mi rendo conto che la produzione abbia la precedenza, ma se vogliono risolvere il problema sarà meglio affontare una seria procedura di ricerca guasti. Ai clienti faccio sempre la metafora: se fori la macchina e non cambi la ruota e continui a girare prima o poi rompi il cerchione e il semiasse... vedi tu quando ti vuoi fermare!

Se prima andava e dopo la modifica c'è il problema nella mia ignoranza io una domanda me la faccio.

giusto

 

Almeno cerca di affrontare la cosa irrobustendo il codice, ovvero in caso di errori di comunicazione rallenta qualcosa o accertati che le informazioni siano acquisite prima di passare alla fase successiva.

 

 

Ci sto provando a fargli capire che devo provare a tornare indietro.

In caso di errore e mancata acquisizione  posso mettergli un allarme.Ma non risolvo il problema.

Non so quale strada sia meno invasiva tra il sostituire le due CPU o tornare indietro.

Grazie.

[pigroplc]

24 minuti fa, anarchico scrisse:

Non so quale strada sia meno invasiva tra il sostituire le due CPU o tornare indietro.

se fossi un venditore della Siemens non avrei dubbi su cosa consigliarti..... ah ah ah ah ah ah ah 

[anarchico]

 

Ahahahahahahahah tanto non le pago io.

 

Tornando seri,quindi tra le righe mi stai dicendo che ampliare le due CPU(non avendo problemi di badget) è una piu che discreta soluzione.

[anarchico]

.Tipo passare a CPU 315-2 PN/DP,con 384 KB  memoria di lavoro a fronte dell'attuale 192KB?

 

E provare ad esempio a cambiare solo quella di invio per risparmiare e non quella di ricezione?(Inizialmente)

Modificato: 25 settembre 2019 da anarchico

[TravelMen]

Ciao

Quote

CPU 315-2 PN/DP

 

Si è la CPU che ho usato anch'io per l'upgrade dal cliente, in oltre ho sostituito il PLC 151 con una ET200, lascindo così invariata la configurazione hardware.

Questo tipo di modifica ti permette di prepare il tutto senza fermare l'impianto e poi in mezz'ora rimetti in marcia.

 

Quote

E provare ad esempio a cambiare solo quella di invio per risparmiare e non quella di ricezione?(Inizialmente)

 

Se è quello con il carico maggiore si.

 

Saluti

 

P.S. Fai attenzione al tempo ciclo, perchè con la nuova CPU io ho avuto un abbassamento tel tempo ciclo attorno all' 80%

[anarchico]

 

 

Questa la situazione attuale.Il 77% non mi senta pesantissimo.

6 ore fa, TravelMen scrisse:

Ciao

 

Si è la CPU che ho usato anch'io per l'upgrade dal cliente, in oltre ho sostituito il PLC 151 con una ET200, lascindo così invariata la configurazione hardware.

Questo tipo di modifica ti permette di prepare il tutto senza fermare l'impianto e poi in mezz'ora rimetti in marcia.

 

 

Se è quello con il carico maggiore si.

 

Saluti

 

P.S. Fai attenzione al tempo ciclo, perchè con la nuova CPU io ho avuto un abbassamento tel tempo ciclo attorno all' 80%

 

Con una memoria di lavoro disponibile praticamente doppia forse è dovuta alla ricerca della locazione di volta in volta piu grande

 

Come hai fatto a lasciare intatta la configurazione HW con una 315 rispetto ad una 151??

 

Grazie mille .

[TravelMen]

Ciao

 

intatta la parte hardware dalla CPU 151 in poi, perchè al posto della IM151 hoi messo una ET200S IM151-3PN

 

La parte in rosso è la sostituzione, da li in poi è tutta la macchina com'è stata progettata con la 151-8.

 

Saluti

 

 

 

Modificato: 26 settembre 2019 da TravelMen

[anarchico]

 

 

 

Ah ok ok......