Pn Pn Coupler -area uscite condivise instabile

[Jacklame]

Salve a tutti, non ho molta esperienza nel campo della programmazioen PLC, mi sono imbattuto in un problema sullo scambio dei segnali con un Siemens PnPn Coupler. La configurazione del dispositivo sembra corretta, definite in modo corente le aree di transfer mapping , eseguita la configurazione hardware del pnp da entrambe le parti ( quadro 1, progetto 1 , Pn coupler fisicamente presente - Quadro 2 , progetto 2 , file gsd ) . La comnunicazione tra le due parti esiste i segnali vengono copiati rispettivamente dalle aree di scambio su due DB tramite la funzione BLKMOV , però facendo un trace delle aree di uscita del plc s7-1500 posto sul primo quadro dove è fisicamente installato il pn coupler ( precisamente Q20.0 [8 byte] ) ottengo un segnale di sturbato che aperiodicamente va a 0 per un tempo ciclo , tale segnale poi viene letto ancora peggio in ricezione nelle aree di ingresso dell'altro plc . Cosa potrebbe essere, affollamento della rete ? Vi ringrazio in anticipo se potete dispensarmi dei consigli utili. Grazie per l'attenzione !

[batta]

14 minuti fa, Jacklame ha scritto:

La configurazione del dispositivo sembra corretta

Sembra corretta, dici, ma, senza vederla, come possiamo affermare che lo sia?

In diagnostica ci sono errori? Non c'è nessun led rosso acceso?

 

15 minuti fa, Jacklame ha scritto:

Cosa potrebbe essere, affollamento della rete

No, assolutamente no.

 

[Jacklame]

Dopo aver letto diverse guide, tra cui quella originale siemens, e diversi video, ho proceduto a configurare il dispositivo da entrambe le parti, con le corrette aree di scambio, la diagnostica non dà nessun errore, lo scambio avviene, ma disturbato direttamente nell area di uscita, e ancora peggio in quella di ingresso dall'altro lato. Cambiando l aggiornamento del ciclo di trace, raddoppiandolo o decuplicandolo, questi disturbi aumentano in un dato intervallo temporale o diminuiscono. Questa prova e stata eseguita sia con cavo della porta accoppiata scollegato, che collegato. Potrebbe essere qualche problema di immagine di processo, ho provato sia con indirizzi bassi, che superiori a q8000. 0.grazie.

Precisazione. Lo stato logico dei segnali che vengono scambiati nell aria di uscita dichiarata nel transfer mapping, viene afflitto da disturbo solo se è positivo, in piu questo disturbo appare contemporanemante in tutta l'area dichiarata come OUT nel trasfer mapping. Come se qualcuno la buttasse a 0 in modo aperiodico e casuale. 

Modificato: 22 agosto 2020 da Jacklame

[batta]

Ma in base a cosa affermi che ci sono questi disturbi?
Cosa significa: "disturbato direttamente nell area di uscita, e ancora peggio in quella di ingresso dall'altro lato"?
E cosa significa: "Questa prova e stata eseguita sia con cavo della porta accoppiata scollegato, che collegato"?

Cosa rappresenta il trace dell'immagine?

[Jacklame]

Il segnale  in giallo che si vede appena nella parte inferiore della foto rappresenta una bit di un db 'scambio' (non ottimizzato) che viene scritto a 1 dal programma. Il segnale celeste che si vede piu sopra, disturbato, cioè va a 0, due volte per la durata di 1 tempo ciclo, è lo stesso bit, interrogato dal trace precisamente nell'area di uscite del plc (dichiarata out nel mapping del pn coupler), dopo aver trasferito la db 'scambio' con la funzione blkmove proprio in quell area. Quindi, almeno come penso, il programma scrive il bit a 1, lo trasferisce in quell aria, pero interrogato col trace ogni tanto va a 0.mi scuso se non riesco a essere piu chiaro. 

Per quanto riguarda la prova del cavo, mentre la porta X1 del pn coupler l ho lasciata collegata al plc, ll cavo sulla porta X2  che va dal pn allo switch dell altro quadro, ho provato a scollegarlo, ma il risultato è uguale a quello descritto nell immagine. 

Modificato: 22 agosto 2020 da Jacklame

[batta]

Se ho capito bene: hai un DB "scambio". Con BLKMOV trasferisci l'area del DB "scambio" nell'area delle uscite configurate sul PN/PN Coupler.
Poi leggi lo stato di queste uscite, e non corrisponde allo stato dei bit nel DB.
È così?

Dunque, se è così, non c'entra assolutamente nulla l'accoppiatore, ma il problema viene prima. Se sono uscite, tu le scrivi verso l'accoppiatore, non leggi lo stato delle uscite dall'accoppiatore.
Anche nel trace, quindi, quello che vedi è quello che tu hai scritto.

Queste uscite saranno viste come ingressi dall'altro lato.

Il fatto poi che tu abbia staccato il cavo verso l'altro plc, influisce esclusivamente sullo stato degli ingressi che leggi dall'accoppiatore, non sulle uscite che tu vai a scrivere.
 

Se usi BLKMOV (che sarebbe da evitare, trattandosi di una vecchia istruzione, mantenuta solo per compatibilità, non per nulla messa nella cartella "Legacy"), dovresti prima di tutto verificare il valore di RET_VAL.
Se ti dà un codice di errore, significa che il trasferimento non è riuscito.
 

Comunque, non devi usare BLKMOV.

Crea un "Tipo di dati" che rispecchi l'area delle uscite dell'accoppiatore.
Usa questo tipo di dati per creare una struttura nel DB, e anche per creare una struttura nella tabella delle variabili. Nella tabella delle variabili assegni a questa struttura l'indirizzo della prima uscita (es: Q20.0).
A questo punto, per trasferire i dati dal DB alle uscite ti basta una seplice istruzione MOVE (non BLKMOV o altro, solo MOVE), e funziona anche con blocchi ottimizzati.
Se non vuoi seguire questa strada, non usare BLKMOVE, ma DPRD_DAT per leggere dalla periferia, e DPWR_DAT per scrivere.

 

Se posti anche qualche pezzo di codice e la configurazione hardware, forse si capisce di più.

 

Modificato: 22 agosto 2020 da batta

[Jacklame]

Esatto , il problema è proprio questo.

 

La funzione che ho usato è proprio BLK_MOV.

 

Lunedi sicuramente proverò a creare il tipo di dati e utilizzare il MOVE. Sono poco fiducioso peò, perche ho provato sia Il BLK_MOVE che il DPWR_DAT, entrambi avevano la variabile #RetVal a 0 ,ed il problema era identico .

 

 Sicuramente, lo penso anche io, il problema risiede a monte, la cosa che mi fa un po dubitare del Pn\Pn Coupler è che si presenta, questa anomalia del segnale che cade a 0 , allorquando definisco nel suo transfer-mapping, compilando e scaricando,  una qualsiasi area di uscite; ovvero se tolgo dal transfer-mapping l'area di 8 byte  (es. Q0-Q7)  e metto a 1 con il programma utente alcuni suoi bit, se faccio il trace sia del bit che della sua copia trasferita nell'area di uscita, non da nessun problema !

 

Posto delle foto del codice e della configurazione . In particolare non sono sicuro di due campi ' organization Block' e ' Proces Image' . Ma non sono troppo esperto di profinet putroppo.

 

Modificato: 22 agosto 2020 da Jacklame

[batta]

Sembrerebbe tutto corretto.
Comunque, la prova vera, sarebbe leggere lo stato degli ingressi dall'altro lato.
 

Hai provato ad eliminare il trasferimento dal DB alle uscite, e a comandare direttamente le uscite in una tabella delle variabili?
Nel trace, come hai impostato il campionamento?

[Jacklame]

Dall altro lato queste anomalie arrivano con frequenza maggiore di  5 o 6 volte piu. Si ho creato delle plc tags, le ho richiamate nel programma utente con assegnazioni, bobina di set, indirizzamento diretto della periferia :P, ) l'effetto non si discosta da quello della foto. 

Il campionamento del trace l ho fatto con Ob1 (20 ms di tempo ciclo), poi moltiplicato x3, x10, stesso risultato, ma molto differente in termini di incidenza del disturbo. Ho provato anche a eliminare il programma facendo ciclare l'Ob1 a 1 ms, e conseguente tempo di campionamento del trace, stessa storia ma con frequenza molto piu elevata. In ultimo ho provato diversi tentativi di chiamata interrupt schedulato, a millesecondi multipli del tempo ciclo, e piu aumentava il tempo di esecuzione dell interrupt maggiore era la frequenza del disturbo. Magari tentativi inutili, ma, per via della disperazione 😅

[batta]

24 minuti fa, Jacklame ha scritto:

indirizzamento diretto della periferia :P

Non dovrebbe cambiare nulla, ma perché la scrittura immediata con :P?
Scrivi semplicemente nell'immagine delle uscite, con una assegnazione "normale", senza il :P .

Comunque, questo mi fa pensare che ci sia altro nel programma che abbassa le uscite.
Elimina qualsiasi richiamo ai blocchi (FC e FB) e, in OB1, inserisci un segmento in SCL e scrivi:

miaUscita := TRUE;

Quell'uscita deve tassativamente rimanere alta. Se così non è, significa che c'è qualche istruzione nel programma che la abbassa.
E non importa se l'accoppiatore è configurato bene o meno, e non importa nemmeno se l'accoppiatore è collegato.
L'uscita deve rimanere alta.

 

[Jacklame]

Grazie mille, lunedi eseguiro tutte queste prove per cercare di capire meglio il problema, ovviamente aggiornerò il tread. 

[Jacklame]

Ciao, grazie per i preziosi consigli. 

Stamattina ho fatto diverse prove. Il risultato è che ci sono delle aeree(e non so bene il perchè) in cui aviene quella scrittura aperiodica a 0 della variabile di uscita, una volta che sono state definite nel transfer mapping, e altre aeree no.Ho provato Q20, Q2000, Q6000, Q8000. Finalmente da Q10000 in poi l uscita rimaneva stabile a 1.

Ho utilizzato la sintassi che mi hai consigliato, udt,move, e tag table; pero ho fatto una prova anche col BLK_MOVE (variant) e DPWR_DAT; Il primo è andato a buon fine, il secondo mi restituiva un errore che poi non ho approfondito. 

Mi rimane il dubbio, del perchè alcune aree vadano bene e altre no. Grazie ancora per le dritte! 

Modificato: 23 agosto 2020 da Jacklame

[batta]

2 ore fa, Jacklame ha scritto:

Mi rimane il dubbio, del perchè alcune aree vadano bene e altre no.

Questo non ha senso.

 

Hai fatto un programma dove c'è solo l'assegnazione di una sola uscita?

Lascia perdere anche il DB, tira via tutto, inserisci un solo segmento in SCL e scrivi:

miaUscita := TRUE;

 

Oppure, in ladder:

              miaUscita
-----------------( )

Nessuno ti può riportare a zero quell'uscita.

Se l'uscita va a zero, significa che, da qualche parte nel programma, qualcuno va a scrivere sull'uscita.

 

E usa il DB ottimizzato. In pratica, salvo casi particolari, il DB non ottimizzato ti serve solo se devi accedere al DB con HMI/SCADA di terze parti.

Lavorare su DB non ottimizzati richiede un tempo fino a 5-6 volte maggiore.

 

Se per te non è un problema, mandami un link da dove scaricare il progetto. Oramai sono proprio curioso di capire dov'è l'errore.

[ken]

anche io sono curioso, lo sto provando perchè devo scambiare alcuni bit di stato e sopratutto dei bit sicuri per la parte F. Ho due macchine che condividono un accessorio, comandi da tutte e due le macchine, gestione solo da una.

 

nei test con la parte F non ho mai notato una cosa del genere, sto provando la cosa prima dell'installazione. la sto provando in sede. le sicurezze non sono mai cadute. basterebbe quella scansione per farlo.

[Jacklame]

Salve, a causa di un intenso periodo di lavoro non ho avuto il tempo di aggiornare il tread. Dopo varie prove, non troppo coordinate a causa della fretta, mi pare di aver individuato 2 possibili cause. 

1) le aree definite Transfer_Area (ovvero il nome degli slot scambiati, erano differenti ovvero avevano un nome diverso con l'altra parte x2 del pnp  pero grandezza in termini di byte uguali. 

2)l'estensione dei byte scambiati erano non pari, tipo 1 byte o 3 byte. 

Se con queste impostazioni compilavo e scaricavo l'hardware, da quel momento in poi monitorando l uscita dal plc, essa soffriva di quel piccolo disturbo. 

Ad un certo punto ho fatto una sola prova, ho definito 4 byte nello slot, l ho chiamato Transfer_area da entrambe le parti, compilato scaricato, la stessa area di uscita del mio plc delle prove precedenti, magicamente stava stbilmente a 1. Ora va a meraviglia. 

Modificato: 27 agosto 2020 da Jacklame