Utilità Di Usare Un Fb Con Relativo Db istanza

[fiorezzz]

Salve a tutti

Sto leggendo codice scritto da altri ...in alcuni casi vengono usati FB con DB istanza ..le operazioni poi che si vanno a fare in questo FB non fanno altro che memorizzare informazioni all'interno del DB ..che poi vengono usate in altre parti di codice

..quale è l'utilità di usare FB con DB istanza ? ..io sono abituato a usare normali FC con relativo DB dove appoggiare risultati o altro

[mubeta]

S7 è molto flessibile e, pur di fare bene, in modo leggibile anche a terzi, si può far econ FC, quello che altri conno, come hai notato tu, con delle FB. Chi può sapere, da qui, perché o per quale ragione ti ritrovi un simile programma? Nessuno.

Quello che invece ti dovrebbe preoccupare è di fare bene il tuo lavoro, magari mantenendo continuità col programma precedente, perché poi tutte le "toppe" vengono all'occhio.

Comunque non c'è alcuna utilità o specialità offerta dalle FB.

[walterword]

la comodita delle fb e' che puoi richiamare al loro interno altre fb , tipi di dato , con i loro Db resi statici all'interno della db dell'fb principale .Alla fine l'fb principale la richiami e genera un solo db con annidati i db delle fb dichiarate al suo interno.

E' un approccio 'informatico' di step7 che pero rende difficile l'upload dei dati dal plc al pc se non sono state salvate e caricate le db in modo corretto .Talvolta si trovano spiacevoli sorprese , cioe dopo l'upload , che i nomi delle variabili dichiarate nei db annidati prendano il nome STAT e cosi sei finito .

Tra l'altro rendono il programma molto pesante , da codici letti da un precedente demente , le cpu giravano dai 50 a 80 mS .

Personalmente preferisco usare Fc con relativo db globale per le routine di macchine ed anche per le fc intese come funzioni parametrizzate .Se l'fc lo chiamo piu di una volta creo con copia & incolla dicversi db e poi con trova e sostituisci sistemo le variabili.

Uso anche fb ma solo per calcoli speciali o dedicati .

ciao

walter

[batta]

Comunque non c'è alcuna utilità o specialità offerta dalle FB.

Perché dici questo?

Anch'io faccio un uso molto limitato della FB (il rapporto tra FC e FB sarà dell'ordine di 200 a 1), ma ci sono casi in cui utilizzare una FB da richiamare più volte, cambiando solo il DB di istanza, risulta estremamente comodo ed efficace.

L'abuso di FB è sicuramente da evitare, ma un utilizzo ponderato direi che non è solo consentito, ma anche consigliato.

Soluzioni più articolate come quelle citate da Walter devono essere ben valutate, perché possono portare a complicazioni (come dice, appunto, Walter) che superano di gran lunga i vantaggi.

[mubeta]

Perché dici questo?

Rispondevo al contesto tel topic di questo thread.

Sappiamo bene cosa offrono le FB, sappiamo bene cosa sono le DB di istanza, e sappiamo anche bene fare delle FC con un puntatore di ingresso che da accesso ad una UDT, con stessa identica funzionalità della FB d'istanza; ma siccome non mi piace essere prolisso, siccome non mi piacciono posto troppo lunghi, ho semplicemente significato che, la FB, nel contesto della domanda, non offre nessun vantaggio rispetto alla FC; sopratutto in S7 dove il programmatore si può prendere quasi tute le licenze (intese come libertà), che desidera. (Saprà lui se vuole far eun programma veloce e snello, o macchinoso e rognoso, dove solo lui può metterci le mani perché magari l'input era stato: se non ci pagano è bene che solo noi siappiamo toccarlo...

Come facciamo noi, da un forum, a spiegare i perché delle scelte altrui? Io non me la sento di giudicare nessuno.

Ma vogliamo dirla tutta, visto che mi hai invitato a spiegare? A me le FB non piacciono!! Perché non mi piace avere tantissime piccole DB di istanza, quando sono io programmatore che devo decidere dove allocare la memoria; quindi preferisco come dicevo, le FC, dove tramite puntatore sono io che dico al sistema dove allocare i dati. Non mi piaccio tutte quelle DB che non so mai come commentare e mi viene un simbolico "sporco". Qualcuno può dire che potrei fare una unica grande FB con all'interno i richiami delle altre istanze, ma così si programma peggio, perché non c'è un ordine delle funzioni rispetto al contesto del programma. Insomma, di ragioni ce ne sono parecchie, e quindi, non mi piacciono. (E non commento altre marche, dove già il concetto di funzione richiamabile, modificabile on-line senza arrestare la CPU è ancora futuro).

Ora è chiaro? La risposta mia era una "goccia", che trasportava un significato più profondo: FC vs FB: per conto mio vince FC per tutto a niente. (Poi, che ne faccio uso pure io, è un altra storia).

[Livio Orsini]

A me le FB non piacciono!! Perché non mi piace avere tantissime piccole DB di istanza, ...

Neanche a me piace questo modo di trattare i dati; quasi certamente l'antipatia deriva dal mio retroterra culturale. A me piace conoscere dove sono allocate le risorse. E' proprio il mdo di trattare i dati di Siemens che non mi piace.

I così detti FC assomigiano molto di più alle "function" di un linguaggio classico.

Poi ognuno ha le sue preferenze ed il suo modo di affrontare i problemi.

[suppaman]

Concordo in pieno anche io con gli ultimi post.

Una cosa da non sottovalutare secondo me è la leggibilità del codice. Ho visto diverse persone utilizzare i dati statici delle istanze come dati "globali" utilizzando tali variabili fuori dell'FB,sparse in varie parti del codice. In questo modo, secondo il mio punto di vista, la leggibilità del programma diminuisce di molto, in quanto è piu difficile localizzare le variabili (tramite il CrossReference e l'utilità "Punto di applicazione" non è immediato risalire a dove viene utilizzato il dato) e capire quindi la logica del programma.

Se volete usarle, almeno cercate di utilizzate i dati dell'istanza esclusivamente come dati interni al blocco.

Ovviamente poi, ognuno ha il suo stile e le sue preferenze come ha ben detto Livio.

Modificato: 5 settembre 2010 da suppaman

[Beatrice_Ru]

Bisogna ricordare che usando un FB istanziata con diverse DB.

Posso rendere più Modulare il Sistema.

In Applicazioni molto complesse, costituite da molte parti anche uguali, o leggermente uguali.

Posso creare alcune FB Modulari che si possono addattare a queste tipologie di Controllo.

Inoltre molte volte queste FB istanziate, posso far parte a loro volta di altre FB parametrizzate e istanziate.

Un esempio, se devo costruire un castello, ho bisogno di mattoni di diversa fattura (ma pur sempre mattoni), Travi, Finestre, Porte etc.

Poi se mi serve costruire una Facciata posso unire insieme, molti mattoni, alcune finestre,e se serve una porta.

Cosi potrò creare con alcune facciate e qualche trave una stanza, e cosi via.

In questo modo unendo insieme più Stanze e più Oggetti modulari il Castello.

Poi a mio parere, se in un impianto molto grande mi accorgo di una imperfezione o sbaglio su un

modulo, mi basta modificare solo quella FB, e non andare in moltissime altre parti del Programma.

Inoltre penso che sia più Scalabile verso altri tipi di Sistemi (S7-300,S7-400,Simotion, e altri PLC).

Quindi anche più flessibili.

Poi dipende se una persona crea programmi non molto complessi e con molte parti molto diverse tra

loro, forse non ha senzo usare questo metodo.

Comunque, potrebbe venire utile poter riutilizzare alcune parti di controllo o di regolazione in futuro

su altre tipologie di macchine, e quindi se abbiamo un "Modulo-FB-DB" pronto risparmiamo molto tempo, nella programmazione.

Inoltre se queste FB sono già state testate come funzionamento ed affidabilità ancora meglio.

[batta]

Sappiamo bene cosa offrono le FB, sappiamo bene cosa sono le DB di istanza, e sappiamo anche bene fare delle FC con un puntatore di ingresso che da accesso ad una UDT, con stessa identica funzionalità della FB d'istanza; ma siccome non mi piace essere prolisso, siccome non mi piacciono posto troppo lunghi, ho semplicemente significato che, la FB, nel contesto della domanda, non offre nessun vantaggio rispetto alla FC

Guarda che non avevo alcuna intenzione di entrare in polemica. Ognuno è libero di programmare come meglio crede.

Io resto sempre dell'idea che delle FB si debba fare un uso ponderato (vietato abusarne, quindi), ma che in alcuni casi siano utili.

Come già detto, anch'io utilizzo poco le FB, ma non condivido l'opinione che siano da evitare come la peste, e che tutto quello che si può fare con le FB (e relativo DB di istanza) si possa fare con una FC.

O meglio, si può sicuramente fare, ma in modo, a volte, meno pulito.

Una cosa da non sottovalutare secondo me è la leggibilità del codice. Ho visto diverse persone utilizzare i dati statici delle istanze come dati "globali" utilizzando tali variabili fuori dell'FB,sparse in varie parti del codice. In questo modo, secondo il mio punto di vista, la leggibilità del programma diminuisce di molto, in quanto è piu difficile localizzare le variabili (tramite il CrossReference e l'utilità "Punto di applicazione" non è immediato risalire a dove viene utilizzato il dato) e capire quindi la logica del programma.

Questo riguarda il fatto che chi scrive il codice può programmare bene o male, ma non è un "problema" delle FB. Si possono fare programmi illeggibili anche utilizzando solo semplici FC.

In ogni caso, se si usano variabili del DB di istanza esternamente all'FB, queste vengono comunque trovate dalle funzioni di ricerca di Step7. Accorgersi poi che fanno parte di un DB di istanza e che potrebbero venir modificate anche dall'FB, ci vuole ben poco.

Neanche a me piace questo modo di trattare i dati; quasi certamente l'antipatia deriva dal mio retroterra culturale. A me piace conoscere dove sono allocate le risorse. E' proprio il mdo di trattare i dati di Siemens che non mi piace.

Il modo di trattare i dati di Siemens è sicuramente un po' più laborioso ma anche estremamente più flessibile del metodo tradizionale, con un certo numero di variabili paragonabili ad un unico grande blocco dati di Siemens. Con l'indirizzamento classico, se devo apportare modifiche e mi accorgo che non ho lasciato abbastanza variabili di riserva, non mi resta altra soluzione che creare tutto un altro gruppo di variabili con indirizzi magari lontani, anche se avrebbero attinenza con le variabili precedenti.

Con Siemens, spesso ti basta fare un altro DB e tutto rimane ordinato e pulito.

Una evoluzione da questo metodo c'è se si passa alla dichiarazione di variabili in modo completamente simbolico (tipo RS Logix 5000). In questo caso però viene a mancare proprio il "sapere dove sono allocate le risorse".

Bisogna ricordare che usando un FB istanziata con diverse DB.

Posso rendere più Modulare il Sistema.

Concordo perfettamente.

[Livio Orsini]

Una evoluzione da questo metodo c'è se si passa alla dichiarazione di variabili in modo completamente simbolico (tipo RS Logix 5000). In questo caso però viene a mancare proprio il "sapere dove sono allocate le risorse".

Premesso che non esiste il sistema perfetto, perchè ogni sistema ha pregi e difetti, tutto sommato preferisco questo modo di trattare i dati. Non è neanche del tutto vero che non si conosce dove sono allocate le risorse. E' possiible risalire, in caso di necessità, alla mappatura della memomoria dati, soprattutto si ha sempre la conoscenza della dimensione totale dell'area dati.

Da ultimo, ma fondamentale, mi chiedo: perchè, salvo qialche eccezione, nei PLC non è possibile trattare i dati come nei linguaggi ad alto livello?

E' così semplice e facile. Tutto risulta molto ben ordinato, comprensibile e riutilizzabile.

Se fai una funzione parametrica ogni volta che la richiami passi i dati. Minimizzi l'occupazione di memoria e masimizzi l'efficienza. Le variabili temporanee sono dichiarate localmente. Tutto è chiaro, comprensibile e facile da "debaggare"

Però, ripeto, ognuno ha i suoi gusti e le sue preferenze.

Quando usavo PLC S7 preferivo usare FC proprio perchè più simili al modo di lavorare con i linguaggi ad alto livello.

[mubeta]

Da ultimo, ma fondamentale, mi chiedo: perchè, salvo qialche eccezione, nei PLC non è possibile trattare i dati come nei linguaggi ad alto livello?

Mi permetto di dire la mia, cruda, così come la penso. Per lo stesso motivo per cui esiste il concetto di istanza. Perché per i più, grandi disegnatori di contatti, il concetto di "puntatore ad una struttura dati" è tanto comprensibile quanto il geroglifico, od altre lingua dell'asia per me.

Siccome non vivo sulla luna, e mi confronto quotidianamente col mondo dell'industria esterno, mi rendo conto che questi post, seppur degni ed assolutamente da proseguire, hanno un bacino di ascolto e consenso prossimo al nulla nell'automazione industriale.

Per dirla tutta, ieri non ho preso un lavoro, perché? Parole dal committente: <<avevamo un programmatore che aveva iniziato a fare cose "strane" sui programmi, che poi noi non riuscivamo a capire. Noi vogliamo solo usare i contatti e le bobine. So che invece lei ...>>

P.S.: non ho nulla contro nessuno. Scrivo post un poco crudi, ma non vuoloe mai esserci offesa. A Batta dico che lo condivido pienamente, (condivido anche Livio Orsini nei contenuti tecnici); il ripudio del concetto di istanza arriva dal passato: sopratutto da Omron, che per ogni istanza si prende ulteriore memoria passi. Perché??? Da Allen Bradley che è quasi peggio di Omron, dove fatta la FB, il collegamento di essa al programma è men che meno qualcosa di sensato. Forse erroneamente, (ma non c'entra nulla col topic del thread), ho calcato la mano nell'esaltare il mio dissenso: si è creato il concetto di istanza, per favorire l'uso delle funzioni richiamabili a tutti quelli che fanno fatica oggi a capire cosa è un puntatore. (Ed infatti continuano a fare funzioni con oggetti ad indirizzo assoluto all'interno, con fronti appoggiati su memoria locale, che, solo chissachì sà perché continuano ad avere lavoro; e, tenetevi, una volta un tale mi chiese: tu che usi gli scatolotti, sapresti ... Ecco, sostanzialmente, FB o FC, da questo punto di vista sono identiche, sono degli scatolotti).

Il programma deve sempre essere pulito e leggibile, certo; ma siamo da capo: cosa è buono e cosa è cattivo ?

Modificato: 6 settembre 2010 da mubeta

[Livio Orsini]

Mi permetto di dire la mia, cruda, così come la penso. Per lo stesso motivo per cui esiste il concetto di istanza. Perché per i più, grandi disegnatori di contatti, il concetto di "puntatore ad una struttura dati" è tanto comprensibile quanto il geroglifico, od altre lingua dell'asia per me.

Ci mancherebbe che tu non potessi esporre le tue idee, visto che lo fai in modo civile ed educato.

Che il PLC sia rivolto soprattutto a chi approccia il problema come contatti di relè è, purtroppo, una realtà incontestabile. Però visto che al "ladder diagram" si affiancano altri mdo di lavorare come, ad esempio, AWL ci si chiede perchè non si possa avere un linguaggio come "C".

C'è qualche casa (penso a B&R p.e.) che ha nei suoi strumenti anche "C".

Io ho già espresso, in altre discussioni, il mio punto di vista su questa scelta. L'adozione di un linguaggio standard ed universale porterebbe ad avere software che gira quasi in modo indipendente dall'hardware: questo, nella visone dei commerciali, sarebbe estremamente dannoso per la "fidelizzazione" del cliente. Inoltre permetterebbe una migliore comparazione delle prestazioni dei vari sistemi, altro punto negativo per i commerciali.

Però sino a quando non ci sarà una notevole pressione degli utilizzatori si continuerà con queste incongruenze da paleolitico dell'informatica.

L'esempio dell'ordine perso la dice lunga sulla mentalità ancora imperante nell'industria, specie in una certa industria italica.

Meglio avere un programma apparentemente facile, costruito con la mazza dello spaccapietre, piuttosto che un programma degno di questo nome, strutturato in modo decente, facile da manutenere ma apparentemente poco comprensibile. Dico apparentemente perchè chi sa veramente programamre trova di più facile comprensione un programma ben strutturato, anche se scritto non in modalità "contatti".

Però questo è OT e poi sto ripetendomi: Sarà la vecchiaia...

[batta]

Perché per i più, grandi disegnatori di contatti, il concetto di "puntatore ad una struttura dati" è tanto comprensibile quanto il geroglifico, od altre lingua dell'asia per me.

premetto che io non ho mai perso lavori perché scrivo in awl, ma mi è capitato più di una volta che mi venisse imposto di fare tutto in kop.

A parte il mal di pancia che mi coglie al solo pensiero, anche se non è vero che il cliente ha sempre ragione, ma dato che è lui che paga... quando capita, cerco di adeguarmi.

Poi, a fare proprio tutto in kop, non ci sono mai riuscito.

Detto questo, io trovo i puntatori Siemens molto flessibili. Si prestano a svariati usi e possono venire manipolati in modi diversi.

Come non eccedo mai nell'utilizzo di FB, cerco però di non eccedere nemmeno nell'uso dei puntatori, che risolvono molti problemi ma rendono generalmente il programma più difficile da debuggare, soprattutto perché risulta impossibile fare un cross reference completo.

[walterword]

secondo i libri sitrain , scuola siemens , gli fb sarebbero da utilizzare per le routine e le fc per le funzioni .

Qualcuno lo ha fatto e poi son saltati fuori i risultati con varie tristezze allegate .

La stessa cosa vale per codesys ed altri linguaggi con la differenza che in codesys , per esempio , ogni blocci di codice puo essere dichiarato come routine ed i suoi dati dichiarati nella finestra soprastante , un po come step 7 , ma con molte differenze di base e concetti piu informatici .

Intanto per dirne una , non esiste il concetto di variabile assoluta con indirizzo mnemonico in ram e simbolo.

In codesys quello che si dichiara e' statico o globale o locale o addirittura immagine di processo senza limiti.

Se creao un 'area dati , decine di db globali , in siemens e durante lo sviluppo oppre alla fine decido di togliere una word che non mi serve devo lasciare il "buco" altrimenti mi shifta tutto e sono cacato.Cosa che in codesys non esiste .

Codesys e' come un linguaggio informatico , tipo vb o vc# o altri , dove le variabili vengono allocate in ram e l'indirizzo non ha importanza almeno che non venga utilizzato come puntatore.

Step7 ha ancora concetti troppo obsoleti come i registri della cpu , la sintassi e gli indirizzi assoluti che sono delle definizioni dei veri indirizzi in ram .Quindo solo confusione .

Pero c'e' di bello che i db globali danno possibilità di creare strutture molto complesse come matrici 3d , strutture di esse, strutture di strutture , di array ect .Ma sempre attenzione a non togliere un bit , meglio espandere tutta la word e scriverci spare per evitare casini.

Io sono sincero , siemens ci lavoro e ci mangio da anni , le mie non sono lamentele ma valide considerazioni che vorrei migliorare ai fini della crescita tecnologia.

Di plc ne ho programmati diversi , ma i piu performanti e piacevoli in assoluto sono i sistemi beckhoff col porting su codesys .

Pc-plc embedded integrati con kernel speciale per il plc , programmabile in codesys (5-6 linguaggi) oppure c++ .

Progetto gestibile coi tools della casa o integrato in visual studio .net 2010 .Hmi sviluppabile in vb.net o c# .

Pensate che figata ......

Apro visual studio 2010 e come template ho il progetto di automazione .....

lo genero ed ho la mia bella vista three view con ......

....configurazione hw

.....sicurezze

.....ethercat

.....files del progetto plc con la possibilita di scrivere una routine o funzione in c++ ed usarla in ladder e viceversa .

.....opc per comunicare col thread hmi scritto in c# col resto dell'applicazione

.....tutto in un progetto

Questa e' l'automazione del presente , automazione industriale intesa come nicchia del grande oceano informatico .

Da qui , con VS2010 posso creare database e gestirli , web , servizi , wcf, forms , socket,mail , files ...senza comprare 12000 tools o licenze o altre puttanate che poi non gira piu un kkkk...oooo

[walterword]

...per i piu diffidenti ....se il pc si impalla , il plc continua a girare senza problemi .

E direte ....si ma senza pc che introduce o manipola i dati il plc non serve ....vero ..ma vale la stessa cosa per i plc con hmi o pannelli basati su CE .

I soliti incalliti diranno.....io nei miei pannelli uso linux !

Bravi , ma non cambia nulla , se windows e' ben compilato e ben usato funziona lo stesso e meglio di linux .

Si pero linux supporta python interprete ...anche i miei programmi su .net tra poco avranno modo di essere estesi e girare su hosting python , file .exe generato una volta sola e tanti bei script - programmi scritti in python , che vengono compilati una volta sola e come assembly utilizzati dalla piattaforma .net .

Quello che puo fare un processore di un pc , che normalmente ha un idle del 95 % , e' indescrivibile rispetto ad un misero processore di plc .

Pensate che nei plc siemens fino a poco fa giravano delle cpu ad 8 bit infineon senza dma e periferiche hw per i calcoli float o quant altro .

E cosa li fanno pagare .

Il costo di una cpu s7-400 e' di svariate migliaia di euro e se volete la flash da 512 k raddoppia il prezzo .

Fate 4 conti ...

[Calogero]

Fra i vari vantaggi del C rispetto al Ladder io ci vedo anche gli strumenti tipici del linguaggio, come i cicli: come si fa in Ladder a fare un ciclo FOR??

Ho inziato da poco con i PLC: guardando i sorgenti a lavoro mi rendo conto che in ladder sarebbe impossibile realizzare l'automazione delle macchine, si sarebbe dovuto ricorrere per forza ad una scheda a microcontrollore.

Quindi come mai sono solo poche le case che permettono la programmazione in C. E quali sono queste case (oltre a B&R)?

Lo Structured Text è paragonabile come potenza al C?

Modificato: 23 settembre 2010 da Calogero

[lucios]

guardando i sorgenti a lavoro mi rendo conto che in ladder sarebbe impossibile realizzare l'automazione delle macchine, si sarebbe dovuto ricorrere per forza ad una scheda a microcontrollore

Ne sei sicuro? Probabilmente le faresti in modo diverso e magari più brutto.... (leggi "meno elegante")

Attenzione, a me non piace particolarmente il ladder e preferisco il C, ma ti assicuro che in ladder tutti i costruttori di plc si sono affannati ad implementare marchingegni vari per ovviare alle mancanze....

Ciao

[batta]

Fra i vari vantaggi del C rispetto al Ladder io ci vedo anche gli strumenti tipici del linguaggio, come i cicli: come si fa in Ladder a fare un ciclo FOR??

A parte che è assolutamente falso che con i linguaggi classici del plc non si possano fare cicli FOR, WHILE e simili, quello che spesso sfugge a chi viene da programmazione diversa da quella usata per l'automazione, è che con FOR e WHILE si deve andare molto cauti.

In altri settori si può usare un ciclo WHILE proprio per tenere fermo il programma in un punto fino al verificarsi di un evento.

Un simile approccio in automazione porterebbe a catastrofi garantite.

[Calogero]

ti assicuro che in ladder tutti i costruttori di plc si sono affannati ad implementare marchingegni vari per ovviare alle mancanze...

Beh, ma non possono inventarsi proprio tutto e poi al programmatore tocca andare sempre alla ricerca del blocco funzione adatto. Con un linguaggio testuale, si ha in mano uno strumento universale che permette di fare qualsiasi cosa. Perchè dipendere dal costruttore che magari il blochetto lo implementa in C?

Perchè affidarsi ad un linguaggio che (Checchè se ne dica nella IEC1131-3) di standard e multipiattaforma ha solo quei pochi contatti?

In altri settori si può usare un ciclo WHILE proprio per tenere fermo il programma in un punto fino al verificarsi di un evento.

Un simile approccio in automazione porterebbe a catastrofi garantite.

Verissimo. Il durante il training il primo compito che mi è stato affidato è quello di trovare un baco: alla fine era dovuto ad un for che in certe occasioni diventava lunghissimo, sforando il tempo massimo del task in cui girava. Però l'abilità/cautela del programmatore penso sia una cosa che esula dal nostro discorso.

In ogni caso sono comunque scettico, vedremo nel seguito se riusciro a fare qualche paragone reale e documentato. Chissa ad esempio come il Ladder riesce a gestire la memoria o a manipolare delle stringhe. Oppure, come si fa ad implementare un filtro digitale o un osservatore?

Da poco inoltre, al mondo dei PLC si è affacciata la Mathworks (Matlab/Simulink) con l'approccio model base (utilizzatissimo nel medicale e nell'automotive) che fa fronte alla necessità d'implementazione di algoritmi complessi di controllo. Questi tool generano codice C o Structured Text.

Modificato: 23 settembre 2010 da Calogero