DA INPUT A DB, SENZA TAG

[Chiccoone]

Ciao a tutti,

sono un utente nuovo del forum e di TIA PORTAL.

Ho un IPC 1507S

 

Dunque:

devo leggere la status word del mio motore che ha indirizzo da 0-21

uso un UDT che gestisce e suddivide i dati in maniera propria.

Il mio scopo è quello di leggere i dati dal motore e trasferirli in una DB senza passare dai tag.

 

LA soluzione che ho trovato è usare i Tag, dove formatto i dati con UDT.

 

Poi facendo un move tra i dati nei tag e la DB ottengo il risultato.

 

Penso che sia un modo non elegante di leggere i dati. Avreste qualche altro consiglio pratico, semplice ed elegante?

 

Grazie per la gradita risposta.

 

[drn5]

Ciao, scusami ma parli di eleganza e poi fai una chiamata a un blocco dove in input usi degli output...

[batta]

Perché ti pare un modo poco elegante? I dati che scambi con il tuo motore, da 0 a 21, sono ingressi e uscite. Anche se non li dichiari nella tabella delle variabili, sono comunque I/O occupati.
Cosa trovi di poco elegante nel vederli mappati anche nella tabella delle variabili, accedere con un nome simbolico, trasferirli con un semplice MOVE, e trovarli facilmente nei riferimenti incrociati?
Anzi, questo modo di operare in molti casi ha soppiantato l'uso di DPRD_DAT e DPWR_DAT.

Inoltre, anziché appoggiarli in un DB, potresti passarli direttamente alla funzione che li usa.

[PlcPro]

Secondo la mia personalissima opinione (che apparirà forse brutale) gli accessi diretti alla memoria del PLC, quando si utilizzano variabili non di I/O dovrebbero essere completamente evitati. Perchè se devo dichiarare una variabile (p.es) reale devo definirne a tutti i costi l'area di memoria ? E stare attento a non sovrapporla ad altre ?

So che la cosa farà storcere il naso ai puristi (quelli che arrivano dalla scuola 300) ma siamo nel 2020 e queste cose non si fanno più.

Lo testimonia il fatto che l'assegnazione delle variabili (non I/O) nei vari sistemi High End come Rockwell, Omron, Schneider per citarne tre non è consentita. Siemens ha mantenuto questo triste retaggio del passato solo per un discorso di compatibilità.

 

Io farei così:

In pratica, ti dichiari l' UDT così come hai fatto (chiamiamola UDT_Motore)

Poi dichiari in un altro DB tante struct quante te ne servono. Se hai es. 4 motori avrai:

 

DB_MOTORS

MOT_1            UDT_Motore

MOT_2            UDT_Motore

MOT_3            UDT_Motore

MOT_4            UDT_Motore

--FINE DB

 

Poi da qualche parte (in SCL per esempio) ti assegni dato per dato quello che ti serve puntando DB_MOTORS.MOT_1.ActPos per esempio.

 

Eviterei contorsioni mentali di assegnazioni tra aree di memoria perchè non ne esci più, nel senso che fai tanto lavoro concettuale per ottenere niente di pratico (anche se alcuni colleghi manipolano gli accessi diretti alla memoria con tanto di AWL per far vedere che sono ancora bravi ;)

 

 

[batta]

1 ora fa, PlcPro ha scritto:

gli accessi diretti alla memoria del PLC, quando si utilizzano variabili non di I/O dovrebbero essere completamente evitati

Qualsiasi dispositivo, in Profibus o in Profinet, occupa aree di I/O.
Quando configuri un inverter in rete, assegni o non assegni gli indirizzi di I/O?
Perché consideri utile non dichiarare queste aree nella tabella delle variabili? Quale sarebbe il vantaggio?
Non è meglio averli sott'occhio anche nella tabella delle variabili?
Poi, fai tutto in simbolico, degli indirizzi non te ne frega nulla. E, se nella configurazione hadrware cambi gli indirizzi, il sistema rimappa in automatico (se lo desideri) tutte le variabili collegate. Al programma, non devi apportare nessuna modifica. Cosa che dovresti invece fare se utilizzassi, per esempio, le istruzioni DPRD_DAT e DPWR_DAT, o qualsiasi altra istruzione nella quale vada impostato l'indirizzo di partenza dell'area da leggere/scrivere.

 

2 ore fa, PlcPro ha scritto:

Poi da qualche parte (in SCL per esempio) ti assegni dato per dato quello che ti serve puntando DB_MOTORS.MOT_1.ActPos per esempio.

No, una volta definito l'UDT, e dichiarati gli I/O dell'inverter sempre sfruttando l'UDT, puoi accedere simbolicamente a tutti i dati, o copiarli, se preferisci, in un DB con un'unica istruzione (MOVE se lo fai in ladder, di assegnazione se lo fai in strutturato). Non c'è bisogno di farlo dato per dato.

È tutto molto lineare, non c'è nessuna contorsione mentale da fare.

 

[PlcPro]

Il 11/10/2020 alle 12:52 , batta ha scritto:

Qualsiasi dispositivo, in Profibus o in Profinet, occupa aree di I/O.

 

 

Questo mi è noto, ti ringrazio per la delucidazione.

 

Il 11/10/2020 alle 12:52 , batta ha scritto:

Quando configuri un inverter in rete, assegni o non assegni gli indirizzi di I/O?

 

 

Infatti, se rileggi quello che ho scritto, ho scritto "quando si utilizano variabili NON di I/O. Per I/O intendo ovviamente tutto ciò che sta sulla periferia del bus di comunicazione.

 

Il 11/10/2020 alle 12:52 , batta ha scritto:

Perché consideri utile non dichiarare queste aree nella tabella delle variabili? Quale sarebbe il vantaggio?
Non è meglio averli sott'occhio anche nella tabella delle variabili?
Poi, fai tutto in simbolico, degli indirizzi non te ne frega nulla. E, se nella configurazione hadrware cambi gli indirizzi, il sistema rimappa in automatico (se lo desideri) tutte le variabili collegate. .

 

 

Non mi sono spiegato bene forse. Intendo per tabella delle variabili (forse il nome non è quello esatto, ma dato che non la uso non conosco nemmeno bene il nome) la mappatura (stile periferia) con Merker, Timer, ecc... Es: %M0.1 (se si indica così) . Dove in pratica tu memorizzi le tue variabili nell'area di memoria (chiamiamola) assoluta. Io mi immagino un programma con ad esempio 200 variabili (tra Bool, Real, INT, Timer, ecc) e la fatica a doverle "mappare" nella memoria globale del PLC. Operazione inutile, dispendiosa, non ottimizzata (in quanto non avrai mai una mappatura contigua di tutta la memoria ma avrai buchi ovunque) ed antelucana.

Preferisco utilizzare dei bei DB dove dentro ci metto tutto quello che voglio e lasciar fare al sistema (che è più capace di noi) l'allocazione interna in memoria.

Infatti ti seguo quando dici "fai tutto in simbolico", penso sia quello che intendevo io.

 

 

Il 11/10/2020 alle 12:52 , batta ha scritto:

 

No, una volta definito l'UDT, e dichiarati gli I/O dell'inverter sempre sfruttando l'UDT, puoi accedere simbolicamente a tutti i dati, o copiarli, se preferisci, in un DB con un'unica istruzione (MOVE se lo fai in ladder, di assegnazione se lo fai in strutturato). Non c'è bisogno di farlo dato per dato.

È tutto molto lineare, non c'è nessuna contorsione mentale da fare.

 

 

NO cosa ?

E chi ti dice che nel mio DB io abbia bisogno per forza di tutti i dati che mi arrivano dalla periferia ?

Così come l'UDT non è detto che sia per forza identica alla struttura dati che arriva dalla periferia. Magari la mia UDT ha solo 5 informazioni essenziali e non tutte le altre delle quali non mi interessa niente.

 

Certo, se mi servissero tutte le informazioni allora certamente una bella move risolve i problemi ed è molto più rapida.

 

La contorsione mentale si riferiva all'accesso assoluto all'indirizzo di periferia e non al loro utilizzo "simbolico".

 

 

 

[batta]

3 ore fa, PlcPro ha scritto:

Questo mi è noto, ti ringrazio per la delucidazione.

Se è ironico, te lo potevi risparmiare.

 

3 ore fa, PlcPro ha scritto:

E chi ti dice che nel mio DB io abbia bisogno per forza di tutti i dati che mi arrivano dalla periferia ?

Così come l'UDT non è detto che sia per forza identica alla struttura dati che arriva dalla periferia. Magari la mia UDT ha solo 5 informazioni essenziali e non tutte le altre delle quali non mi interessa niente.

La comodità sta proprio nel fatto di creare un Tipo di Dati (UDT) corrispondente al telegramma che usi.
Così, nella tabella delle variabili, andrai a mappare, per ogni inverter (continuiamo l'esempio con l'inverter), un solo simbolo per gli ingressi (al quale assocerai l'UDT dei dati letti dal drive), e un solo simbolo per le uscite (al quale assocerai i dati inviati al drive). Poi, trasferire questi dati in un DB o non farlo, diventa solo una scelta, perché potresti accedere, in simbolico, ai soli dati che ti interessano senza copiarli in un DB. Se si desidera copiarli in un DB, perché dovrei andare a fare la selezione, per esempio, della velocità e della parola di stato quando, con una sola istruzione, posso trasferire tutti i dati del telegramma, e ritrovarmeli così nel DB, pronti all'uso se mi servono?

 

3 ore fa, PlcPro ha scritto:

La contorsione mentale si riferiva all'accesso assoluto all'indirizzo di periferia e non al loro utilizzo "simbolico".

Ma infatti, la comodità sta proprio nel fatto che, associando opportunamente un UDT, poi si fa tutto in simbolico. Degli indirizzi fisici, te ne puoi dimenticare.

 

Scusami, non è per polemica, ma o non ci capiamo, o ti sfugge qualcosa su come si possono utilizzare gli UDT.

 

[PlcPro]

12 ore fa, batta ha scritto:

Se è ironico, te lo potevi risparmiare.

 

Anche tu potevi risparmiarti l'ovvietà "Qualsiasi dispositivo, in Profibus o in Profinet, occupa aree di I/O."

 

12 ore fa, batta ha scritto:

La comodità sta proprio nel fatto di creare un Tipo di Dati (UDT) corrispondente al telegramma che usi.
Così, nella tabella delle variabili, andrai a mappare, per ogni inverter (continuiamo l'esempio con l'inverter), un solo simbolo per gli ingressi (al quale assocerai l'UDT dei dati letti dal drive), e un solo simbolo per le uscite (al quale assocerai i dati inviati al drive). Poi, trasferire questi dati in un DB o non farlo, diventa solo una scelta, perché potresti accedere, in simbolico, ai soli dati che ti interessano senza copiarli in un DB. Se si desidera copiarli in un DB, perché dovrei andare a fare la selezione, per esempio, della velocità e della parola di stato quando, con una sola istruzione, posso trasferire tutti i dati del telegramma, e ritrovarmeli così nel DB, pronti all'uso se mi servono?

 

Ma infatti, la comodità sta proprio nel fatto che, associando opportunamente un UDT, poi si fa tutto in simbolico. Degli indirizzi fisici, te ne puoi dimenticare.

 

 

D'accordissimo, ma questo ti obbliga a creare un UDT potenzialmente grosso dove devi mappare TUTTI i dati che ti arrivano dal dispositivo. Anche quelli che non ti serviranno mai a niente. E li devi mappare con la dimensione giusta, se no succede il macello più totale perchè la MOVE, per quanto "smart" sia, poi piglia tutto e spalma sull'UDT. Se sbagli anche una sola dimensione dentro il tuo UDT poi passi le ore a capire come mai certi dati ti arrivano completamente sbagliati. Oppure puoi sbagliare l'ordine degli elementi invertendone due e creando così il dramma.

Quindi perchè tirare dentro il mondo (e rischiare di sbagliare) quando ti servono alla fine "pochi" elementi che puoi gestire bene e singolarmente ?

 

13 ore fa, batta ha scritto:

Scusami, non è per polemica, ma o non ci capiamo, o ti sfugge qualcosa su come si possono utilizzare gli UDT.

 

Penso di aver capito cosa volevi dire e nelle righe qui sopra ti ho esposto quelle che sono (secondo me) le criticità di creare un mega UDT. Alla fine cambia poco, io avrei fatto come ti dicevo, poi uno è liberissimo di creare l'UDT e risolvere con una MOVE, così il tempo che guadagni con la move lo perdi a testare l'UDT e vedere che le aree di memoria combacino alla perfezione... Un minimo "incrocio" e, come dicevo, tantissimi auguri.

 

Tutto qui.

 

Ah. Non mi sfugge niente sugli UDT, solo che mi hanno sempre infastidito quelli che gli inglesi chiamano "big head" che si permettono di dire "si" o "no" sui pareri degli altri.

 

 

[batta]

52 minuti fa, PlcPro ha scritto:

Anche tu potevi risparmiarti l'ovvietà "Qualsiasi dispositivo, in Profibus o in Profinet, occupa aree di I/O."

Scusami, si, è un'ovvietà, ma, da quanto scrivevi, sembrava di no. Pare che tu consideri I/O solo gli ingressi e le uscite "normali", invece fa tutto parte degli I/O, anche la periferia. Un drive non è diverso da un nodo ET200SP con i suoi moduli di I/O. Non capisco perché tu voglia fare questa distinzione.

 

 

56 minuti fa, PlcPro ha scritto:

D'accordissimo, ma questo ti obbliga a creare un UDT potenzialmente grosso dove devi mappare TUTTI i dati che ti arrivano dal dispositivo. Anche quelli che non ti serviranno mai a niente. E li devi mappare con la dimensione giusta, se no succede il macello più totale perchè la MOVE, per quanto "smart" sia, poi piglia tutto e spalma sull'UDT. Se sbagli anche una sola dimensione dentro il tuo UDT poi passi le ore a capire come mai certi dati ti arrivano completamente sbagliati. Oppure puoi sbagliare l'ordine degli elementi invertendone due e creando così il dramma.

Quindi perchè tirare dentro il mondo (e rischiare di sbagliare) quando ti servono alla fine "pochi" elementi che puoi gestire bene e singolarmente ?

Di nuovo, mi viene da pensare che ti sfugga qualcosa sugli UDT.
Creo un UDT. Uso questo UDT per la dichiarazione nella tabella delle variabili. Uso lo stesso UDT per creare la struttura di dati nel DB. Sbagliare è impossibile. Anzi, se modifico l'UDT, automaticamente mi si modifica tutto. E l'eventuale MOVE o assegnazione tra due strutture non identiche non mi viene accettata dal compilatore, quindi nessuna perdita di ore per trovare dati che arrivano sbagliati.
In quanto alla quantità di dati, se hai inserito un drive con il suo telegramma, il plc scambia i dati col drive sia che tu utilizzi questi dati, sia che tu non li utilizzi.
Inoltre, se devo scambiare due word e configuro un telegramma da 12 word, l'errore è nella scelta del telegramma, e leggere solo due delle 12 word a disposizione non mi fa risparmiare nulla o quasi.

 

E vuoi mettere la comodità? Perdo tempo, una sola volta, per creare il mio UDT, e poi me lo ritrovo pronto all'uso. Sempre per l'esempio drive, un telegramma molto usato per i G120 è il telegramma 352. Ti crei un UDT con la struttura del telegramma 352, e non devi più perdere tempo a consultare la documentazione di come sono fatte la status word o la control word, perché ogni bit ha il suo nome. Potresti anche leggerli e scriverli direttamente, come un normale ingresso o una normale uscita. Puoi anche creare un UDT solo per la status word, da inglobare all'interno di un altro UDT contenete tutte le PZD, in modo da rendere più agevole la creazione di UDT per i diversi telegrammi. Una qualsiasi modifica viene automaticamente aggiornata in tutto il programma.

 

Altra cosa: quando passo strutture come parametri ad una funzione, le passo come IN/OUT. In questo modo non viene fatta la copia di tutta la struttura nei dati della funzione, ma viene generato un puntatore. A detta dei tecnici Siemens, con blocchi ottimizzati, questo metodo, oltre a far risparmiare byte, è anche il modo più veloce per accedere ai dati.

 

In quanto al "big head", non è questo il caso. Semplicemente, se trovo affermazioni che considero sbagliate, mi permetto di dissentire. Poi potrei sbagliare io, oppure potrebbe trattarsi solo di una incomprensione ma, per tornare agli inglesismi, trovo ipocrita lo "yes but..." dei giapponesi per dire no.
 

 

[Livio Orsini]

9 minuti fa, batta ha scritto:

trovo ipocrita lo "yes but..." dei giapponesi per dire no.

 

Se è per questoè molto usato anche dagli italiani; mai sentito, durante una riunione o assistendo ad un dibattito, iniziare una frase con: "Si, però ..." oppure "Si, ma ..."?

[batta]

1 ora fa, Livio Orsini ha scritto:

Se è per questoè molto usato anche dagli italiani;

Sì, verissimo, penso si usi in tutto il mondo.
Premetto poi che io, in Giappone, non ci sono mai stato, e la faccenda dello "yes but" mi è stata narrata da chi ci è stato.
Loro lo adottano come una forma di rispetto, per dire no, ma senza contraddire l'interlocutore.
Da noi, a mio avviso, è più per mancanza di coraggio, per non volersi esporre. Infatti il "sì però" viene usato con i superiori, non con i sottoposti.

Io non sono molto diplomatico, e la timidezza, con l'età, è sparita. Se per me è no, è no e basta. Non è maleducazione, è onestà.

[PlcPro]

3 ore fa, batta ha scritto:

Pare che tu consideri I/O solo gli ingressi e le uscite "normali", invece fa tutto parte degli I/O, anche la periferia. Un drive non è diverso da un nodo ET200SP con i suoi moduli di I/O. Non capisco perché tu voglia fare questa distinzione.

 

Non so da cosa traspaia il fatto che io consideri I/O solo gli ingressi e le uscite c.d. normali. Il mio era un discorso generale su ciò che è I/O (che quindi è mappato in periferia per forza) e ciò che non è I/O (Es: La variabile BOOL pippo). Non ho fatto NESSUNA distinzione tra I/O "classici " (ingressi e uscite fisiche) e I/O di "dati".

3 ore fa, batta ha scritto:

Di nuovo, mi viene da pensare che ti sfugga qualcosa sugli UDT.
Creo un UDT. Uso questo UDT per la dichiarazione nella tabella delle variabili. Uso lo stesso UDT per creare la struttura di dati nel DB. Sbagliare è impossibile. Anzi, se modifico l'UDT, automaticamente mi si modifica tutto. E l'eventuale MOVE o assegnazione tra due strutture non identiche non mi viene accettata dal compilatore, quindi nessuna perdita di ore per trovare dati che arrivano sbagliati.
In quanto alla quantità di dati, se hai inserito un drive con il suo telegramma, il plc scambia i dati col drive sia che tu utilizzi questi dati, sia che tu non li utilizzi.
Inoltre, se devo scambiare due word e configuro un telegramma da 12 word, l'errore è nella scelta del telegramma, e leggere solo due delle 12 word a disposizione non mi fa risparmiare nulla o quasi.

 

Batta, non mi sfugge niente delle UDT. Ti prego di rimanere sull'ambito tecnico.

 

Creo un UDT--> OK

Uso questo UDT per la dichiarazione nella tabella delle variabili --> OK

Uso lo stesso UDT per creare la struttura di dati nel DB -> OK, niente di speciale dato che nel DB avrai un "Tag" di tipo "UDT_Motore", quindi , ovvio nell'ovvio, se modifichi l'UDT allora ti si modifica anche il DB. E fin qui lo sanno anche i muri.

 

E l'eventuale MOVE o assegnazione tra due strutture non identiche non mi viene accettata dal compilatore, quindi nessuna perdita di ore per trovare dati che arrivano sbagliati.

 

L'errore che temo non è tanto l'identità delle strutture, ma l'ordine dei dati. Ed il compilatore non se ne accorgerà mai.  Mi spiego con un esempio:

 

Ti arrivano 8 Word dalla periferia:

 

Posizione Velocità Coppia(Attuale) GiriMotore StatoAllarmi StatoIngressi TemperaturaMotore DCBus

 

Nell'UDT hai mappato però :

 

Posizione Coppia(Attuale) Velocità GiriMotore StatoAllarmi StatoIngressi TemperaturaMotore DCBus

 

 

Sai la tua MOVE cosa fa ? Niente. Sono cavoli tuoi poi andare a cercare come mai quando fai dei calcoli sulla velocità attuale, non funziona niente.

 

3 ore fa, batta ha scritto:

Inoltre, se devo scambiare due word e configuro un telegramma da 12 word, l'errore è nella scelta del telegramma, e leggere solo due delle 12 word a disposizione non mi fa risparmiare nulla o quasi.

 

E vuoi mettere la comodità? Perdo tempo, una sola volta, per creare il mio UDT, e poi me lo ritrovo pronto all'uso. Sempre per l'esempio drive, un telegramma molto usato per i G120 è il telegramma 352. Ti crei un UDT con la struttura del telegramma 352, e non devi più perdere tempo a consultare la documentazione di come sono fatte la status word o la control word, perché ogni bit ha il suo nome. Potresti anche leggerli e scriverli direttamente, come un normale ingresso o una normale uscita.

Puoi anche creare un UDT solo per la status word, da inglobare all'interno di un altro UDT contenete tutte le PZD, in modo da rendere più agevole la creazione di UDT per i diversi telegrammi. Una qualsiasi modifica viene automaticamente aggiornata in tutto il programma.

 

Ripeto, rimango dell'idea che non vale la pena a sbattersi (e a segnare ore) per fare tutta la mega UDT quando in realtà so già che scambierò 3 dati in croce. Di sicuro il telegramma deve essere consono a quello che mi serve.

 

4 ore fa, batta ha scritto:

Altra cosa: quando passo strutture come parametri ad una funzione, le passo come IN/OUT. In questo modo non viene fatta la copia di tutta la struttura nei dati della funzione, ma viene generato un puntatore. A detta dei tecnici Siemens, con blocchi ottimizzati, questo metodo, oltre a far risparmiare byte, è anche il modo più veloce per accedere ai dati.

 

Premesso che, contrariamente a 30 anni fa, ormai il termine "risparmiare dati" è meno critico, nel senso che i PLC di adesso hanno risorse (rispetto ai nostri programmi) molto più potenti. Ma quindi, fammi capire, tu passi le UDT alle funzioni /FB come IN/OUT ? Anche se nella Function/FB non devi modificare quel Tag ?

Mi sembrano ottimizzazioni fini a se stesse (prova a non metterle come I/O e vedrai che il tempo ciclo del programma non cambia di un nanosecondo....) ma la cosa curiosa è : ottimizzeresti il risparmio di bytes (velocizzando l'accesso alla memoria) e poi dall'altra parte, ti metti a fare UDT giganti quando ne usi magari solo un quinto ? E magari hai 20 inverter, ognuno con la sua UDT ? Quanta memoria vai ad occupare in più ?

 

 

4 ore fa, batta ha scritto:

In quanto al "big head", non è questo il caso. Semplicemente, se trovo affermazioni che considero sbagliate, mi permetto di dissentire. Poi potrei sbagliare io, oppure potrebbe trattarsi solo di una incomprensione ma, per tornare agli inglesismi, trovo ipocrita lo "yes but..." dei giapponesi per dire no.

 

 

I casi sono due. O uno dissente perchè ha l'onniscienza totale sulla materia (e non penso sia il mio o il tuo caso). O perchè ha un'opinione diversa, con la possibilità di sbagliare o di dire giusto.

Lo "yes but" , come lo chiami tu, è una forma rispettosa di dialogo che significa anche "comprendo quello che dici ma esiste anche almeno un'altro modo per farlo".

Non mi sento di rispondere da maleducato con un "no" a quello che scrivono gli altri proprio perchè c'è sempre la possibilità di capire cose nuove e di migliorare.

Proprio perchè non esiste un'unica soluzione ideale, esiste la parola "but" e ci si può discutere sopra.

 

 

 

 

2 ore fa, batta ha scritto:

Da noi, a mio avviso, è più per mancanza di coraggio, per non volersi esporre. Infatti il "sì però" viene usato con i superiori, non con i sottoposti.

Io non sono molto diplomatico, e la timidezza, con l'età, è sparita. Se per me è no, è no e basta. Non è maleducazione, è onestà.

 

Si tratta di un modo di interfacciarsi piuttosto antipatico. Specialmente in un forum. Se uno dice una cosa, rispondere "no", presuppone il fatto di avere una conoscenza totale della materia, senza se e senza ma. Non mi pare che in questo forum arriviamo a tanto. Forse solo sul forum ufficiale di mamma Siemens trovi DAVVERO chi conosce al 100% la materia (ChristophD, Jacekd, pegaia, ecc), loro possono dirti "no", perchè conoscono come è fatto il tuo PLC in ogni sua singola pista di rame.

Se per te una cosa è no, sarebbe cortese scrivere "secondo me no" e non "no" secco e poi partire con l'esperienza di vita vissuta.

Dovresti anche aver capito che, in questo mestiere (come tanti), non si finisce mai di imparare e questo senza rinnegare la grande esperienza che uno può aver maturato in 20 anni di lavoro. Di conseguenza (e lo scopo del forum è anche questo) il condividere le proprie valutazioni sarebbe una cosa carina che va al di la del "no" oltre che utile a tutti.

 

 

 

 

 

 

 

 

 

[Livio Orsini]

50 minuti fa, PlcPro ha scritto:

Lo "yes but" , come lo chiami tu, è una forma rispettosa di dialogo che significa anche "comprendo quello che dici ma esiste anche almeno un'altro modo per farlo".

Non mi sento di rispondere da maleducato con un "no" a quello che scrivono gli altri proprio perchè c'è sempre la possibilità di capire cose nuove e di migliorare.

 

Per te è una forma di cortesia,per me è una forma di ipocrisia.

Se non hai lacertezza assoluta di quello che stai per affermare si usa la formula: "A mio parere..." o simili . L'uso di di locuzioni tipo "Si ma.." o "Si però" lo trovo ipocrita e mellifluo, anche se non usato nei confronti di superiori gerarchici.

 

In ordine alla disputa tecnica.

Io ho abbandonato da un paio di decenni il nondo PLC (con mia somma gioia e gaudio) però credo di avere una buona conoscenza della programmazione, sia per studi che per pratica.

A mio giudizio non c'è una netta prevalenza di una metodologia sull'altra. La differenza la fanno le  abitudini, la soria e le preferenze personali.

Credo che, se anche continuaste a discutere per mesi, le opinioni non cambierebbero.

Più logico accettare le differenze di vedute dell'altro e continuare ad operare secondo abitudine.

[batta]

Ultima risposta, poi chiudo, anche perché ha ragione Livio: io continuerò a lavorare a modo mio, tu continuerai a lavorare a modo tuo, ed è giusto così.

 

 

3 ore fa, PlcPro ha scritto:

Non so da cosa traspaia il fatto che io consideri I/O solo gli ingressi e le uscite c.d. normali. Il mio era un discorso generale su ciò che è I/O (che quindi è mappato in periferia per forza) e ciò che non è I/O (Es: La variabile BOOL pippo). Non ho fatto NESSUNA distinzione tra I/O "classici " (ingressi e uscite fisiche) e I/O di "dati".

Scusami, ma non ho ancora capito cosa per te sia nell'area I/O, e cosa no. Il 1500 non è come il 300.

 

3 ore fa, PlcPro ha scritto:

Posizione Velocità Coppia(Attuale) GiriMotore StatoAllarmi StatoIngressi TemperaturaMotore DCBus

Nell'UDT hai mappato però :

Posizione Coppia(Attuale) Velocità GiriMotore StatoAllarmi StatoIngressi TemperaturaMotore DCBus

Se sbaglio a creare l'UDT, allo stesso modo potrei sbagliare andando a leggere, per esempio, un dato dalla PZD2 anziché dalla PZD3.
Ma un UDT, una volta testato, so che è fatto nel modo giusto. Ci perdo tempo una volta sola.

 

3 ore fa, PlcPro ha scritto:

Ripeto, rimango dell'idea che non vale la pena a sbattersi (e a segnare ore) per fare tutta la mega UDT quando in realtà so già che scambierò 3 dati in croce. Di sicuro il telegramma deve essere consono a quello che mi serve.

Io ritengo opportuno creare UDT anche per tre dati in croce, perché semplificano la vita. Chi l'ha deciso che gli UDT debbano per forza essere mastodontici?
Se faccio gli UDT di ingresso e di uscita per un telegramma 352, questi UDT avranno, ovviamente, l'esatta dimensione del telegramma: 6 word.
Supponiamo poi che di queste 6 word te ne interessino solo due. Sei sicuro che andare a leggere separatamente le due word, con due istruzioni, sia meno oneroso che leggere tutte le 6 word con una sola istruzione?

 

3 ore fa, PlcPro ha scritto:

Premesso che, contrariamente a 30 anni fa, ormai il termine "risparmiare dati" è meno critico

Beh, qui, un po' ti contraddici. Stai facendo una questione sul leggere solo i dati che ti servono, e poi mi dici che risparmiare dati non è importante.

 

3 ore fa, PlcPro ha scritto:

Ma quindi, fammi capire, tu passi le UDT alle funzioni /FB come IN/OUT ? Anche se nella Function/FB non devi modificare quel Tag ?

Certo! Supponiamo di avere una struttura con 50 variabili (booleane, interi, real, quello che vuoi). Supponiamo di avere un FB che ha bisogno di accedere a 5 di queste variabili. Dovrei passare 5 parametri separati? Io passo l'intera struttura come IN/OUT. I dati ai quali non andrò ad accedere non appesantiscono nulla, perché viene creato solo un puntatore, e il sistema perderà tempo solo per accedere ai dati che all'interno della funzione andrò ad utilizzare. Inoltre, in questo modo, passo tutto con un solo parametro anziché cinque. Anche la lettura del programma ne guadagna.
Altro vantaggio poi, se in caso di modifiche, dovessi avere bisogno di accedere ad un altro dato: non ho alcun bisogno di modificare l'interfaccia delle variabili della funzione, perché ho già libero accesso ai dati dell'intera struttura.

 

 

3 ore fa, PlcPro ha scritto:

O uno dissente perchè ha l'onniscienza totale sulla materia (e non penso sia il mio o il tuo caso)

Non è questione di onniscienza, che di sicuro non ho (nemmeno tu, però). No significa semplicemente "non sono d'accordo". Poi, al no, seguono le motivazioni del perché non sono d'accordo.

 

In quanto allo "yes but", come già detto, per me non è una forma di educazione, ma solo ipocrisia: non sono d'accordo, ma non ho il coraggio di dirti che non sono d'accordo.
Quindi, scusami, non è per maleducazione, ma solo per onestà: ogni volta che tu affermerai che è meglio leggere solo quei due/tre dati che ti servono piuttosto che usare un UDT e leggere tutto in un colpo solo, io continuerò a risponderti: no, non sono per niente d'accordo. Non significa che "io so tutto", significa che non sono d'accordo.
Se, invece, scrivi una cosa sbagliata, non ti dico solo no, ti dico: "No, è sbagliato, per i seguenti motivi".
Spero ci siamo chiariti.

 

Io uso tantissimo gli UDT. I miei DB sono costituiti in grandissima parte da UDT. Per farti un esempio, nel programma sul quale sto lavorando al momento (abbastanza complesso), per ora sono arrivato a 71 UDT.
Esempio.

Gestione di un silo: ho un UDT per i comandi da pannello operatore, un UDT per i dati di setup, un UDT per gli allarmi.
Gestione di un serbatoio: ho un UDT per i comandi da pannello operatore, un UDT per i dati di setup, un UDT per gli allarmi.

Gestione di una soffiante: ho un UDT per i comandi da pannello operatore, un UDT per i dati di setup, un UDT per gli allarmi.
Mi ritrovo con una decina di sili. Nei DB uso gli UDT, e gli stessi UDT li uso nelle funzioni alle quali passo i comandi da HMI, i dati di setup e gli allarmi (tre righe, ed ho passato tutti i dati). Se devo modificare qualcosa, modifico l'UDT, e mi ritrovo tutto fatto per tutti e 10 i sili, sia nei DB, sia nelle funzioni.

 

Modificato: 13 ottobre 2020 da batta

[PlcPro]

16 ore fa, batta ha scritto:

Scusami, ma non ho ancora capito cosa per te sia nell'area I/O, e cosa no. Il 1500 non è come il 300.

 

Provo a scrivertelo ancora una volta poi amen.

L'area I/O di un PLC è l'area di memoria adibita allo scambio dati con la periferia. Periferia remota (Inverter, ET200) o integrata (Stile Sinamics Integrated) non cambia niente. Sempre periferia è.

 

Quello che penso sia (nel 2020) improprio è dichiarare le mie variabili del programma (quelle su cui faccio dei calcoli, anche intermedi) nella stessa area, come si faceva una volta e come si può ancora fare con TIA con i vari PLC. Penso sia molto meglio utilizzare un bel DB, con tanto di allocazione automatica, piuttosto che andare a dichiarare ogni singola variabile (e per tua comprensione non sto parlando della periferia) con tanto di indirizzo.

 

16 ore fa, batta ha scritto:

Beh, qui, un po' ti contraddici. Stai facendo una questione sul leggere solo i dati che ti servono, e poi mi dici che risparmiare dati non è importante.

 

Pneso tu non legga bene i miei post, di conseguenza salta fuori il minestrone di concetti.

Ho detto che risparmiare dati, oggi come oggi, non è più così importante come una volta. mi riferivo (ovviamente) al risparmio computazionale che il programmatore (onesto) ha.

Mi costa di più creare un UDT e testarla su ogni valore o mi costa di più prendere dalle word solo quello che mi serve e finita lì ? Al plc non frega nulla.

 

16 ore fa, batta ha scritto:

Certo! Supponiamo di avere una struttura con 50 variabili (booleane, interi, real, quello che vuoi). Supponiamo di avere un FB che ha bisogno di accedere a 5 di queste variabili. Dovrei passare 5 parametri separati? Io passo l'intera struttura come IN/OUT. I dati ai quali non andrò ad accedere non appesantiscono nulla, perché viene creato solo un puntatore, e il sistema perderà tempo solo per accedere ai dati che all'interno della funzione andrò ad utilizzare. Inoltre, in questo modo, passo tutto con un solo parametro anziché cinque. Anche la lettura del programma ne guadagna.

Altro vantaggio poi, se in caso di modifiche, dovessi avere bisogno di accedere ad un altro dato: non ho alcun bisogno di modificare l'interfaccia delle variabili della funzione, perché ho già libero accesso ai dati dell'intera struttura.

 

Di nuovo, non ho detto quello. Quello che hai qui scritto è correttissimo, ma mi riferivo al discorso IN/OUT dove ci sarebbe una presunta ottimizzazione in memoria a livello di velocità.

Hai mai notato una differenza sul dichiarare gli UDT in ingresso di un FB come IN/OUT o solo come IN (posto che tu non debba ovviamente modifcarle nell'FB) ?

Io penso di no. Potresti fare la prova pratica e vedrai che il contributo di questa "strategia" è nullo.

 

16 ore fa, batta ha scritto:

Non è questione di onniscienza, che di sicuro non ho (nemmeno tu, però). No significa semplicemente "non sono d'accordo". Poi, al no, seguono le motivazioni del perché non sono d'accordo.

 

In quanto allo "yes but", come già detto, per me non è una forma di educazione, ma solo ipocrisia: non sono d'accordo, ma non ho il coraggio di dirti che non sono d'accordo.
Quindi, scusami, non è per maleducazione, ma solo per onestà: ogni volta che tu affermerai che è meglio leggere solo quei due/tre dati che ti servono piuttosto che usare un UDT e leggere tutto in un colpo solo, io continuerò a risponderti: no, non sono per niente d'accordo. Non significa che "io so tutto", significa che non sono d'accordo.
Se, invece, scrivi una cosa sbagliata, non ti dico solo no, ti dico: "No, è sbagliato, per i seguenti motivi".
Spero ci siamo chiariti.

 

Sapevo che in italiano la parola "no" significasse negazione, da oggi aggiornerò il mio dizionario.

In un contesto interlocutorio se io affermo una cosa e tu mi risppondi con un no, significa che quello che dico è sbagliato (appunto abbiamo creato il termine no).

Se invece dici "secondo me no" è tutta un'altra cosa.

Si passa dall'educazione alla maleducazione.

Di conseguenza, "no" lo possono dire i super esperti della Siemens.

Il "secondo me no" lo dicono i comuni programmatori.

Dato che fatico ad accostarti al primo gruppo, mi aspetterei (in caso di dissenso) un approccio più simile alla seconda categoria.

 

16 ore fa, batta ha scritto:

Io uso tantissimo gli UDT. I miei DB sono costituiti in grandissima parte da UDT. Per farti un esempio, nel programma sul quale sto lavorando al momento (abbastanza complesso), per ora sono arrivato a 71 UDT.

Esempio.

Gestione di un silo: ho un UDT per i comandi da pannello operatore, un UDT per i dati di setup, un UDT per gli allarmi.
Gestione di un serbatoio: ho un UDT per i comandi da pannello operatore, un UDT per i dati di setup, un UDT per gli allarmi.

Gestione di una soffiante: ho un UDT per i comandi da pannello operatore, un UDT per i dati di setup, un UDT per gli allarmi.
Mi ritrovo con una decina di sili. Nei DB uso gli UDT, e gli stessi UDT li uso nelle funzioni alle quali passo i comandi da HMI, i dati di setup e gli allarmi (tre righe, ed ho passato tutti i dati). Se devo modificare qualcosa, modifico l'UDT, e mi ritrovo tutto fatto per tutti e 10 i sili, sia nei DB, sia nelle funzioni.

 

 

71 UDT ?

Stai rifacendo la centrale nucleare di Red Plains negli USA ?

A me hanno insegnato che delle tecniche di programmazione bisogna avere padronanza... Ma mai abusarne.

Ho capito che le ore le paga il cliente, ma caspita, 71 UDT è da record mondiale... Se lo scrivi a mamma Siemens ti fanno un'articolo per esaltare le performances della CPU...

 

 

[Livio Orsini]

35 minuti fa, PlcPro ha scritto:

Di conseguenza, "no" lo possono dire i super esperti della Siemens.

 

Io su questo dissento nel modo più assoluto

[batta]

2 ore fa, PlcPro ha scritto:

Dato che fatico ad accostarti al primo gruppo, mi aspetterei (in caso di dissenso) un approccio più simile alla seconda categoria.

In tutta onestà, ti devo dire che nemmeno io considero te appartenente al primo gruppo anche se, da come scrivi, sembri essere detentore della verità assoluta.
Poi, riguardo al significato della parola "no", forse dovresti andarti a rileggere il dizionario.

 

2 ore fa, PlcPro ha scritto:

71 UDT ?

Certo, e ne aggiungerò ancora! Gli UDT non sono una perdita di tempo, gli UDT fanno risparmiare tempo! Ed ho anche spiegato brevemente i principali vantaggi dell'uso degli UDT.
Non li vuoi usare? Liberissimo di continuare, alla vecchia maniera, a dichiarare manualmente, e ripetitivamente, strutture uguali. E ad andare a mofìdificarle, sempre manualmente, una per una, in  caso di bisogno.

 

2 ore fa, PlcPro ha scritto:

Quello che penso sia (nel 2020) improprio è dichiarare le mie variabili del programma (quelle su cui faccio dei calcoli, anche intermedi) nella stessa area

Guarda che non sei obbligato. Puoi sempre usare DPRD_DAT e DPWR_DAT (o altre funzioni simili). Avere queste aree mappate anche nella tabella delle bvariabili, per me è un vantaggio, una comodità, non una pecca.

 

2 ore fa, PlcPro ha scritto:

71 UDT è da record mondiale... Se lo scrivi a mamma Siemens ti fanno un'articolo per esaltare le performances della CPU

Hai mai aperto programmi delle librerie Siemens?
Posso sbagliare, ma rimango della mia idea: non hai chiaro quale sia l'uso degli UDT. Non ho scritto "no", questa è solo la mia opinione.

 

2 ore fa, PlcPro ha scritto:

Quello che penso sia (nel 2020) improprio è dichiarare le mie variabili del programma (quelle su cui faccio dei calcoli, anche intermedi) nella stessa area

Scusa, ma dovè che avrei anche solo suggerito di dichiarare variabili di lavoro nell'area I/O? E perché mi dici che con Siemens si deve ancora fare così?

 

 

Sì, lo so, avevo scritto che non avrei più risposto, ma non ho resistito.

Modificato: 14 ottobre 2020 da batta

[max.riservo]

Il 11/10/2020 alle 10:31 , PlcPro ha scritto:

Secondo la mia personalissima opinione (che apparirà forse brutale) gli accessi diretti alla memoria del PLC, quando si utilizzano variabili non di I/O dovrebbero essere completamente evitati. Perchè se devo dichiarare una variabile (p.es) reale devo definirne a tutti i costi l'area di memoria ? E stare attento a non sovrapporla ad altre ?

So che la cosa farà storcere il naso ai puristi (quelli che arrivano dalla scuola 300) ma siamo nel 2020 e queste cose non si fanno più.

Lo testimonia il fatto che l'assegnazione delle variabili (non I/O) nei vari sistemi High End come Rockwell, Omron, Schneider per citarne tre non è consentita. Siemens ha mantenuto questo triste retaggio del passato solo per un discorso di compatibilità.

Non uso Siemens ma Schneider, confesso che non ho capito cosa non sarebbe più consentito nei sistemi High End (quali sono per te?) Schneider.

Stai forse dicendo che non è più possibile allocare una variabile ovvero assegnarle un indirizzo specifico (del tipo %MW100) di memoria?

[leleviola]

Il 14/10/2020 alle 11:33 , PlcPro ha scritto:

71 UDT ?

Stai rifacendo la centrale nucleare di Red Plains negli USA ?

A me hanno insegnato che delle tecniche di programmazione bisogna avere padronanza... Ma mai abusarne.

Ho capito che le ore le paga il cliente, ma caspita, 71 UDT è da record mondiale... Se lo scrivi a mamma Siemens ti fanno un'articolo per esaltare le performances della CPU...

 

 

Si 71 UDT potrebbero essere tante ma standardizzare i dati è sempre utile e se poi si deve fare un sistema ripetitivo è il sistema per renderlo anche di più semplice lettura e più semplice debug, non vedo la complicazione anzi a me sembra un semplificazione. Ovviamente tale metodologia ne consente anche una più semplice duplicabilità

[Livio Orsini]

9 ore fa, leleviola ha scritto:

Si 71 UDT potrebbero essere tante ma standardizzare i dati è sempre utile

 

Se uno parte da zero, forse son tanti. Però, in genere, chi programma bene non parte mai da zero, con gli anni si crea una sorta di libreria personale che è facile adattare, ampliare, aggiungere per nuove applicazioni.

Modificato: 16 ottobre 2020 da Livio Orsini

[batta]

5 ore fa, Livio Orsini ha scritto:

Però, in genere, chi programma bene non parte mai da zero

Sì, ma non è solo questo.
Dichiarare le variabili direttamente in un DB o in UDT, richede esattamente lo stesso tempo.
Se la stessa struttura viene utilizzata anche solo due volte, richiamandola come UDT ho già risparmiato tempo.
Ma non solo, se devo modificare la struttura, se le ho dichiarate tutte manualmente, altrettanto manualmente le dovrò modificare, una per una.
Se ho usato un UDT, mi basta modifiacre l'UDT.

È come, in un programma in C, usare  #include, o riscrivere ogni volta sempre le stesse cose.

[Livio Orsini]

3 ore fa, batta ha scritto:

È come, in un programma in C, usare  #include, o riscrivere ogni volta sempre le stesse cose.

 

Certo.

Poi se si fa uso di variabili simboliche è buona pratica usare sempre il medesimo simbolo per indicare la medesima funzione, in questo modo oltre arisparmiare tempo si ha una migliore leggibilità anche a distanza di tempo.

 

3 ore fa, batta ha scritto:

Se ho usato un UDT, mi basta modifiacre l'UDT.

 

Certo. Così è anche meno facile fare errori.