Cp342-5 Con Fcm300

[gianlucagardelli]

Signori Buon Giorno.

Devo utilizzare questa CP, per aggiungere nuovi Slave DP su di una CPU 317 2 DP con le due rispettive reti "piene".

Ho già seguito tutta la procedura dal sito della Siemens, a partire dalla configurazione hardware fino all'utilizzo dei blocchi send-receive da introdurre nel software. Ho fatto una prova con un solo slave (Inverter Danfoss FCM300) sulla nuova rete profibus della CP.

La CP è in RUN, la vedo dalla configurazione hardware, ma lo slave non è riconosciuto.

Mi sono venuti i seguenti dubbi:

1. premesso che utilizzo il telegramma semplice di comunicazione (PPO3 o 2 non ricordo) che prevede 2 word d'ingresso per STW e MAV dell'inverter e due word d'uscita per CTRLW e MRV dell'inverter medesimo, ho creato due DB (send e receive) con una struttura ad interi; ciascuna delle DB, contiene 2 word: DBW0 e DBW1 nel formato INTERO. (L'indirizzo iniziale della periferia dell'inverter è 0 sia sugli ingressi che le uscite) Qui, sorge il primo dubbio: la struttura delle DB è corretta ? Dovevo fare una DB con 4 byte (formato byte) ? (O un array di 4 byte ?)... oppure bastava "battezzare" le variabili nel formato "Word" anzichè intero ?

2. Ho parametrizzato le FC1-2 inserendo il corretto indirizzo iniziale della CP in esadecimale... Inserendo i puntatori delle aree dati (senza offset): In send: "P#DB1.DBX0.0 BYTE 4" ed in receive: P#DB2.DBX0.0 BYTE 4. Supporrei quindi di leggere le due word dell'inverter dalle DBW0 e DBW2 della DB2 e di scrivere le due word dell'inverter sulle DBW0 e DBW2 della DB1.

3. Sui parametri di ritorno delle FC1 e 2, (richiamate da una FC che le include, a sua volta richiamata in OB1), non ho rispettato le indicazioni che richiedono l'utilizzo di merker o DBw_x_b ed ho appoggiato i medesimi valori di ritorno su delle variiabili TEMP (della FC che include le chiamate alle FC1 e 2). Ho sbagliato ? Puo' essere questa una ulteriore ragione per la quale non vedo lo slave ?.

Non saprei che altro controllare: il cavo profibus dalla CP all'inverter è OK, lo slave DP è logicamente in DPV0, l'inverter comunica se lo appoggio alla rete profibus della CPU 317...

Avete qualche idea in merito ?

Inoltre... Siccome devo mantenere un vecchio standard sulla diagnostica profibus degli slave: Posso evitare di usare la FC3 della Siemens e continuare ad utilizzare la funzione SFC51 (SZL_ID) anche per questa rete nuova ? (Logicamente inserendo i parametri corretti in ingresso alla SFC)...

Grazie Anticipatamente per un vostro eventuale e gradito riscontro.

Gian Luca.

[cagliostro]

Salve,

La CP è in RUN, la vedo dalla configurazione hardware, ma lo slave non è riconosciuto.

I led BUSF ed SF (se presente) sono spenti, accesi,lampeggianti ??

Se risulta acceso solo il led di RUN, la configurazione hardware in S7, setup del FCM300 lato inverter, collegamenti hardware ed eventuali resistenze di terminazione sul bus sembrerebbero indicare che tutta questa parte è corretta.

D'altro canto questo troverebbe conferma quando scrivi:

l'inverter comunica se lo appoggio alla rete profibus della CPU 317...

Questo mi farebbe escludere che ci siano impostazioni errate sulla comunicazione lato inverter, cavi e connettore/i mal realizzati o con difetti.

Tornando alle tu domande...

1)Il telegramma che hai impostato in S7 hardware è il PPO1 che prevede nell'area PCD o PZW (per Siemens) due word in scrittura e due in lettura.

la struttura delle DB è corretta ? Dovevo fare una DB con 4 byte (formato byte) ? (O un array di 4 byte ?)... oppure bastava "battezzare" le variabili nel formato "Word" anzichè intero ?

A meno che, per qualche motivo "oscuro" l'FCM300 non si aspetti che le word siano elaborate in una particolare rappresentazione, quello che hai fatto è sensato.

Vai a leggere status word (STW) ed il valore attuale di frequenza in uscita (MAV) su due word , ed ad effettuare la scrittura della control word (CTW) e del SPoint di velocità (MRV) su altrettante word dichiarate su un DB diverso. Per cui su questo punto, il fatto che tu abbia usato due word anzichè impiegare una struttura in byte, array o altro, credo sia ininfluente.

2)Anche la parametrizzazione delle FC1-2 (DP_SEND CP300 e DP_RCV CP300) da come scrivi sembrano esser state richiamate ed impostate correttamente, almeno per l'area dati dichiarata P#DB1.DBX etc. etc.,.

Per quanto riguarda l'indirizzo assegnato in CPLADDR questo non lo so, ma sempre da quello che scrivi, hai letto quello assegnato da S7 hardware e poi convertito in hex. Quindi anche qui direi che sembra tutto OK.

3)Non dovrebbe essere un problema, ma per toglierti ogni dubbio puoi appoggiare i valori su delle aree di tipo non TEMP, una cosa peò sarebbe interessante saperla. Quando il problema si manifesta, sia in FC1 ed FC2 vengono restituiti dei corrispettivi codici di errore nei parametri STATUS e DPSTATUS??

Credo anche che dal lato dell'inverter DANFOSS dovresti avere sicuramente qualche codice di errore.

Hai eventualmente considerato giusto per prova, la possibilità di utilizzare anche i blocchi funzione compilati da DANFOSS per la comunicazione in S7 Profibus DP scaricabili dal loro sito??

Per concludere in relazione all'uso della SFC51 anzichè della FC3, non saprei. Credo dico credo, che ragionevolmente non dovrebbero esserci problemi, personalmente non ho mai provato ciò verso una CP342-5, ma penso si faccia prima a provare. A meno che tu non riceva indicazioni precise da altri utenti che si sono scontrati con quest'ultimo punto.

Modificato: 23 ottobre 2010 da cagliostro

[gianlucagardelli]

Buon Pomeriggio.

In primis "grazie mille per i suggerimenti".

Chiedo scusa... L'inverter in questione è un FC300 ... non un FCM300, ma la cosa dovrebbe essere alquanto irrilevante.

Rispondo punto x punto.

I led BUSF ed SF (se presente) sono spenti, accesi,lampeggianti ??

Il led SF (System fault se mi ricordo) è spento.

Il led BUSF1 è acceso in modalità di lampeggio.

Il led RUN (se mi ricordo: verde) è acceso in modalità fissa.

A meno che, per qualche motivo "oscuro" l'FCM300 non si aspetti che le word siano elaborate in una particolare rappresentazione, quello che hai fatto è sensato.

Vai a leggere status word (STW) ed il valore attuale di frequenza in uscita (MAV) su due word , ed ad effettuare la scrittura della control word (CTW) e del SPoint di velocità (MRV) su altrettante word dichiarate su un DB diverso. Per cui su questo punto, il fatto che tu abbia usato due word anzichè impiegare una struttura in byte, array o altro, credo sia ininfluente.

Ne prendo atto. Mi rimane comunque questo dubbio dal momento che in tutte le DB che ho analizzato come esempi, le variabili sono sempre dichiarate come byte, oppure array di Byte. (Nessun esempio con dichiarazione nel formato Word o intero). Ad ogni modo, Lunedì provero' a cambiare la struttura delle DB.

Tra l'altro provero' anche a realizzare dei puntatori diretti sulle aree della periferia ("P#E0.0 Byte" 4 e "P#A0.0 Byte 4", senza usare DB), anche se qualcuno ha già detto che la cosa non gli funzionava e si è visto costretto ad utilizzare delle variabili locali di appoggio).

Vi terrò informati ... sui relativi sviluppi.

2)Anche la parametrizzazione delle FC1-2 (DP_SEND CP300 e DP_RCV CP300) da come scrivi sembrano esser state richiamate ed impostate correttamente, almeno per l'area dati dichiarata P#DB1.DBX etc. etc.,.

Per quanto riguarda l'indirizzo assegnato in CPLADDR questo non lo so, ma sempre da quello che scrivi, hai letto quello assegnato da S7 hardware e poi convertito in hex. Quindi anche qui direi che sembra tutto OK.

Condivido quanto hai scritto... Qui dovremmo essere "OK"

3)Non dovrebbe essere un problema, ma per toglierti ogni dubbio puoi appoggiare i valori su delle aree di tipo non TEMP, una cosa peò sarebbe interessante saperla. Quando il problema si manifesta, sia in FC1 ed FC2 vengono restituiti dei corrispettivi codici di errore nei parametri STATUS e DPSTATUS??

Lunedì cambierò sicuramente queste variabili di appoggio (sostituendole con dei merker) e ti/vi terrò informati sugli sviluppi. (Tra l'altro, nella mia ingenua ignoranza sono già stato scottato dall'utilizzo di variabili "Temp", nella costruzione dei fronti... Mai fare questa cosa !) Per di più sappiamo che queste variabili devono sempre essere rigorosamente aggiornate ciclicamente... Nella fattispecie, non vorrei che nascessero delle complicazioni con l'utilizzo dei puntatori...

Rispetto ai Parametri dei codici di errore, pur non ricordandomi il valore Hex del "DPSTATUS", posso già dirti che la combinazione dei due parametri, mi dava l'errore di Area dati troppo corta (DB troppo corta o qualcosa del genere)... In tutti i modi, Lunedì saprò dire i valori precisi.

Credo anche che dal lato dell'inverter DANFOSS dovresti avere sicuramente qualche codice di errore.

Hai eventualmente considerato giusto per prova, la possibilità di utilizzare anche i blocchi funzione compilati da DANFOSS per la comunicazione in S7 Profibus DP scaricabili dal loro sito??

Molto interessante... Non ne ero al corrente... Se troverò il tempo proverò a documentarmi... Grazie mille della "dritta".

Per concludere in relazione all'uso della SFC51 anzichè della FC3, non saprei. Credo dico credo, che ragionevolmente non dovrebbero esserci problemi, personalmente non ho mai provato ciò verso una CP342-5, ma penso si faccia prima a provare. A meno che tu non riceva indicazioni precise da altri utenti che si sono scontrati con quest'ultimo punto.

D'accordissimo... Per di più la "vecchia" SFC51, prevede anche la dignostica di reti Profibus, "esterne" alla CPU (con debite parametrizzazioni)... Prima devo sistemare la comunicazione... Ti/Vi terrò informati.

Grazie di tutto...

Spero di poter anch'io contracccambiare al vs. aiuto... per ora posso solo tenervi informati sugli sviluppi della situazione.

Saluti a Tutti.

Gian Luca.

[cagliostro]

Il sito Danfoss mette a disposizione esempi e manuali ben fatti (a mio modesto parere).

Allego per tuo eventuale interesse, il link del manuale che contiene anche un semplice esempio di lettura e scrittura dell'area dati dichiarata nel PPO, con semplici istruzioni di MOVE.

http://mcliterature.danfoss.com/WebPublish...loadPub.do?no=0

Anche se non è di molto aiuto, il led BUSF1 lampeggainte ed il led RUN acceso, sta a significare che il processore CP è in funzione, ma con errori negli slave DP.

Se guardi comunque nel manuale dei CP, ed in particolare al capitolo 4, viene fatta anche una distinzione tra le differenze di un profibus integrato nella CPU ed uno che utilizza il CP con l'impiego delle FC1 e 2.

http://support.automation.siemens.com/IT/l...cedownload=true

Ripensando a quello che hai fatto, credo che l'errore si trovi nell'area indirizzata su DB1 e DB2, qui dovresti mettere l'area con gli indirizzi assegnati in automatico dalla configurazione di S7 ,es. P#E100.0 BYTE 4.

Se invece per esempio utilizzando la FC1 con area dati da scrivere in P#DB1.DBX0.0 BYTE4 vai a scrivere verso uno slave che difatto non ha un'area E/A con un simile indirizzo, ecco quindi il perchè di slave inesistente. Almeno questa dovrebbe essere la spiegazione più logica.

Modificato: 23 ottobre 2010 da cagliostro

[gianlucagardelli]

Buongiorno a tutti.

Sono un po' in ritardo, ma ora riesco concludere questa argomentazione con i debiti riscontri:

- La CP342-5 era difettosa, nel senso che gli slave Dp della sua rete non erano riconosciuti. Ho pertanto sostituito la CP con una medesima e tutto è andato a posto. (Non so quanto sia rilevante, ma la CP iniziale difettosa aveva il firmware 5.7... Quella in sostituzione il 5.6... Da notare inoltre che a livello di configurazione hardware, nell'inserimento di questa CP, si sceglie il componente il cui firmware è il 5.1, (non ce ne sono ulteriori)... Da qualche parte, sul sito della Siemens è scritto che la cosa è corretta, anche se a mio modesto parere, tutto ciò genera confusione).

- Rispetto alle aree dati da leggere e scrivere io ho utilizzato due blocchi dati: uno per la trasmissione ed uno per la ricezione (anche se potevo utilizzarne uno unico, con le debite attenzioni sull'indirizzamento dei puntatori per definire due aree diverse). In questo modo, rispetto all'indirizzamento degli slave DP, dobbiamo tenere presente che non c'è alcuna correlazione tra gli indirizzi E/A degli Slave (della CP342) e le immagini di processo della CPU (317 nel mio caso). Per rendere le cose semplici, il primo nodo slave Dp della CP342, ha indirizzo E/A = 0 (che non entra in conflitto con un'eventuale modulo E/A con indirizzo 0 dislocato sul rack del PLC)... Immagino (perchè non ho avuto tempo di provarlo), che il discorso sarebbe stato diverso se avessi utilizzato al fine della lettura e scrittura dati, direttamente le immagini di processo; in questo caso, immagino che avrei dovuto verificare le immagini di processo già impegnate dai moduli della CPU e definire di conseguenza l'indirizzamento E/A degli slave sulla CP342.

- Rispetto alla diagnostica della rete profibus sulla CP, posso dirvi che la SFC51 (lettura di una lista parziale) non funziona. La cosa è relativamente documentata sul sito della Siemens, dove si nega per la CP342, l'utilizzo della FB125 per fare la diagnostica di rete. Dal momento che tale FB utilizza la SFC51, "a ritroso", riesco a motivare questa incompatibilità. A tal proposito ho utilizzato la FC3 della Siemens (DP Diag) per fare la diagnostica con esito positivo.

- Rispetto al discorso relativo all'utilizzo di variabili "Temp", sui codici di errore restituiti dalle FC, alla fine ho utilizzato dei merker. L'ho fatto solo per mio scrupolo, ma credo che comunque avrei potuto lasciare le variabili "Temp". Purtroppo non ho avuto tempo di verificare questo dettaglio.

Questo è tutto ciò che posso dire, rispetto a questa argomentazione.

Grazie per gli aiuti.

Un saluto a tutti.

Gian Luca.