TIA Portal e fronti di salita

[Lucky67]

Premetto che non ho molta simpatia per siemens e i suoi prodotti ma per campare, visto che un mio cliente si è intestardito con s7 1200 ho dovuto legare il cavallo dove vuole il padrone e lo sto usando. Devo ammettere che aldilà della pesantezza e di alcune incoerenze è un prodotto ormai quasi maturo e potente e onestamente lo trovo di agevole utilizzo. Unica cosa mi dite perchè,all'alba del 2021, per usare una variabile sul fronte di salita o di discesa devo usare oltre alla variabile stessa un'altra variabile? Gli altri editor riconoscono la funzione solo dal comando ( | FP| ad esempio) mentre siemens continua a farmi sbattere la testa di impestare il programma con variabili "inutili". Mi spiegate il senso della cosa?

[leleviola]

hai detto bene il prodotto è molto maturo ma in questo caso si perdono in un bicchier d'acqua sperando che prima o poi riescano a **e soluzione, ci sono delle scorciatoie per porvi rimedio tipo crearsi una DB apposita ma ricorrere a tutto ciò dopo tutti questi anni lasciatemelo dire è un po' ridicolo. Prodotti giapponesi di vari marchi sono venti anni che tale noiosa situazione manco l'ho mai dovuta affrontare

[batta]

Sinceramente, non vedo questo grosso fastidio nel dover utilizzare una variabile per il rilevamento del fronte.
Se sei all'interno di una FB, per esempio, puoi dichiarare nelle STAT un array di bool da usare per questo specifico scopo (io lo faccio sempre, anche se poi non mi servono fronti).

 

Personalmente sono altre le cose che definisco "difetti". Sempre per restare su Siemens, se vogliamo trovare difetti non perdiamoci in queste stupidate, ma parliamo dei difetti veri (che ce ne sono).
Nel confronto con i giapponesi poi, avranno anche il fronte senza variabile di appoggio, ma sono ancora legati (forse non tutti) ad un database unico per le variabili. Questo sì che si può definire un difetto, e bello grosso.

[leleviola]

46 minuti fa, batta ha scritto:

Sinceramente, non vedo questo grosso fastidio nel dover utilizzare una variabile per il rilevamento del fronte.
Se sei all'interno di una FB, per esempio, puoi dichiarare nelle STAT un array di bool da usare per questo specifico scopo (io lo faccio sempre, anche se poi non mi servono fronti).

ok che non è una gran rottura ma non credi che sia solo una inutile perdita di tempo? Invece che concentrarsi sulla logica devi concentrarti su menate a cui potrebbe pensare direttamente il sistema, non credi?

Modificato: 29 agosto 2021 da leleviola

[batta]

È come comperare un'automobile, e lamentarsi per il colore del pomello del cambio.
Non mi dire che dover usare una variabile per il fronte ti fa perdere tempo, o ti mette in crisi con la programmazione.
Ci sono cose ben più importanti di cui ti potresti lamentare.
 

[leleviola]

Eh si che mi fa perdere tempo e pure inutilmente 

[Livio Orsini]

22 ore fa, Lucky67 ha scritto:

Mi spiegate il senso della cosa?

 

Si chiama U.C.A.S. (Ufficio Complicazioni Affari Semplici).

E una cosa in cui i teutonici eccellono.

Avendo lavorato una decina d'anni in un'azienda che, oltre a produrre una propria linea di convertitori ed inverter, distribuiva in Italia PLC ed elettromeccanica di un'azienda tedesca, ho una discreta esperienza di questa mentalità.

Per la loro mentalità non è un giro a vuoto, come per noi italiani, ma è un'operazione necessaria secondo il loro senso della precisione.

[acquaman]

Il 28/8/2021 alle 19:26 , Lucky67 ha scritto:

Gli altri editor riconoscono la funzione solo dal comando

Quali, tolto i giapponesi?

Rockwell sicuramente chiede la variabile, gli altri non ricordo ma penso quasi tutti.

Come sempre il linguaggio che si conosce meno è quello più ostico, ma se il bit sul fronte è l'unico difetto che trovi allora il TIA è un ottimo prodotto.

[leleviola]

20 minuti fa, acquaman ha scritto:

Quali, tolto i giapponesi?

Beh allora forse sono abituato male io visto che i giapponesi li uso di frequente

[acquaman]

1 ora fa, leleviola ha scritto:

Beh allora forse sono abituato male

Non intendevo quello, intendevo dire che aparte loro, molti altri produttori oltre a siemens usano un bit di appoggio per il fronte, è un uso comune.

Comunque l'uso di un bit sul fronte non è un grosso problema, ma non averlo è comunque comodo.

[leleviola]

si non è un grosso problema è che capisco che io essendomi abituato a lavorare senza dover gestire i bit dei fronti mi sono abituato a lavorare "più liberamente"

[Lucky67]

3 ore fa, acquaman ha scritto:

Quali, tolto i giapponesi?

Rockwell sicuramente chiede la variabile, gli altri non ricordo ma penso quasi tutti.

Come sempre il linguaggio che si conosce meno è quello più ostico, ma se il bit sul fronte è l'unico difetto che trovi allora il TIA è un ottimo prodotto.

 

Non conosco Rockwell e quindi mi fido ma ti assicuro che editor molto meno pretenziosi e per di più italiani non cercano "la finezza" tedesca e addirittura un sistema che conosco ammette, se serve, variabili in OR dove il fronte reagisce anche se uno o più è già impegnato...

Io non uso Tia Portal in maniera pesante per cui di dfetti gravi non ne ho visti (i più esperti di me sicuramente ci vedranno più lungo) ma se permetti questo giochino è veramente anacronistico e davvero inutile...

[Lucky67]

21 ore fa, batta ha scritto:

ad un database unico per le variabili.

 

Mi pare che ormai gli editor che si appoggiano a sw IEC 61131 quantomeno permettono di suddividere le variabili in gruppi (poi che il database sia sempre lo stesso non lo so) e quindi credo che da quel punto di vista non sia un problema.

 

[leleviola]

1 ora fa, Lucky67 ha scritto:

 ma se permetti questo giochino è veramente anacronistico e davvero inutile...

descrizione perfetta, Tia portal ha tantissimi pregi di riunire in un'unica piattaforma tantissimo, comunque nessuno è perfetto speriamo che tolgano anche questa e che lo capiscano

[step-80]

Uso Mitsubishi da diversi anni ma in passato ho usato il Tia , anche parecchio.

E' vero, sui fronti va appoggiata una variabile quando su GxWorks 2 la cosa può essere evitata, ma onestamente non credo che il problema sia li, anzi. 

 

Trovo a dir poco scandalosa l'organizzazione delle variabili su Mitsubishi, come ho sostenuto spesso in altri post, anche se col GxWorks 3 è stata lievemente migliorata. Tutto verte in nome della filosofia 'ultra minimal' japan, ma francamente questa cosa a me ha rotto un po le scatole. Max 32 caratteri per una variabile, nei quali non può essere presente uno spazio. Questo obbliga ad inventarsi nomi di variabili che sembrano piuttosto dei mobili Ikea tipo Pls_Strt_da_Pann_Cmd_Prncp . Ecco questo io lo reputo un limite. Mi direte che non è cosi grave e in programmi relativamente semplici vi posso anche dare ragione. Ma in programma più complessi non esiste che io mi debba scervellare oltre che per realizzare il programma anche per inventarmi i nomi.  Nel caso di utilizzo Hmi, si hanno 2 strade. Utilizzare il sistema con le labels che prevede però un vergognoso rimando ad un database di Melsoft navigator, che è il 'contenitore' comune di tutte le suite Mitsubishi. Una porcata immane, visto che l'aggiornamento dei database avviene attraverso reflections manuali . Ho utilizzato una sola volta questo sistema (che sconsigliano pure i tecnici Mitsubishi) e mi è passata la voglia. La seconda opzione prevede l'utilizzo di labels alle quali però devi assegnare indirizzi fisici, in modo che siano poi univocamente puntati dal pannello. Esempio: Se hai 'Start_da_Hmi' gli assegni M0 o D0.0 , poi lato Hmi nelle proprietà del pulsante punterai all'indirizzo M0 o D0.0, perdendo però la leggibilità delle label A MENO CHE non ti crei un'altra lista di labels lato HMI alla quale assegnerai lo stesso indirizzo, tenendo presente che poi le due labels che avrai chiamato nello stesso modo non sono in alcun modo legate e quindi se la cambi da una parte dall'altra ti attacchi..rendendo molto semplice sbagliare. 

Tornando al discorso indirizzi, se ti servono variabili ritentive puoi impostare un area Contigua dove metterle ma questo è un grosso limite quando utilizzi strutture. Perchè dentro la struttura puoi avere dati di diverso tipo, nell'ordine che più ti fa comodo per il programma, e se devi rendere retain 3 word sole in una struttura eterogenea questo è un bel problema. Non lo puoi fare, limitando fortemente la creatività e la libertà di programmazione..oltre a rendere difficili implementazioni e/o modifiche future. Per come la vedo io, la programmazione deve essere smart. Deve essere lei a venire incontro a me , deve risolvermi i problemi anzichè crearmeli. 

 

Da questo punto di vista, W Siemens e W Tia Portal. Con le DB organizzi i dati nella maniera che meglio credi, rendendo ritentivo solo ciò che ti serve anche in un secondo momento. L'Hmi(che è gestito nello stesso progetto, fxxgata) punta al simbolico e quindi te ne freghi degli indirizzi. Puoi organizzare l'albero a sx in cartelle, nascondendo ciò che crea confusione e creando contenitori organizzati per funzione o quello che vuoi. 

 

Dal MIO punto di vista,la questione della variabile sui fronti non è un grosso limite se gestita con testa. Come diceva @batta , basta un array di bool dichiarato nelle Stat , che puoi anche non usare poi. E' li, se serve è pronto e non crea problemi. Insomma io uso Mitsubishi ma cerco di essere onesto. Per certe cose Siemens è avanti anni luce. 

[leleviola]

19 minuti fa, step-80 ha scritto:

Per certe cose Siemens è avanti anni luce. 

infatti Siemens è avanti anni luce ma potrebbero pure risolvere questa piccolezza e sarebbero davvero il top per chi come me trova "noioso" dover demandare al programmatore l'onere di assegnare una variabile che non è altro che spesso una fonte di errore, l'uomo sbaglia, la macchina no 

[step-80]

@leleviola hai ragione perfettamente anche tu ma il succo del mio discorso è...se paragonati i 2 ambienti di lavoro è palese che l'ago della bilancia pende prepotentemente verso Tia. In senso relativo usare una variabile per il frontre è poca cosa..se si conosce bene come fare la cosa è ancora più banale. Se Inserendo un fronte si fa finta di rimanere 'sorpresi' di fronte alla richiesta di un bit di appoggio, ecco che si va frettolosamente a dichiararlo nella tabella delle variabili standard, magari come M100.0 (orrore), creando una lista di bit dal nome improbabile in ordine sparso, a seconda del bisogno. Se la cosa invece si sa prima, basta un semplice array di bool per risolvere la faccenda. 

Forse se Siemens non ha ancora risolto la questione è perchè ne ha altre di più urgenti alle quali dare priorità, o forse non ci da peso affato (ma ne dubito visto che i clienti si saranno già ampiamente lamentati di questa cosa). Un pò come il discorso dei timer che , se reinizializzati con ingresso alto, non contano più. 

 

Se potessi avere i vantaggi che ho con Mitsubishi , vantaggi che non sono per niente legati all'ambiente di sviluppo ma di altra natura quale economico,assistenza,legame con l'attuale venditore ecc ma potessi usare un ambiente più simile al Tia non ci penserei 2 volte, anche se i bit di appoggio da inserire fossero 5 e non solo 1. 

[leleviola]

3 minuti fa, step-80 ha scritto:

Se potessi avere i vantaggi che ho con Mitsubishi , vantaggi che non sono per niente legati all'ambiente di sviluppo ma di altra natura quale economico,assistenza,legame con l'attuale venditore ecc ma potessi usare un ambiente più simile al Tia non ci penserei 2 volte, anche se i bit di appoggio da inserire fossero 5 e non solo 1. 

verissimo anche codesto, ma tutto dalla vita non si può avere, condivido il tuo discorso

[step-80]

Mi permetto di andare leggermente OT, apro e chiudo una parentesi..

@leleviola nei prossimi mesi devo realizzare il programma di una nuova macchina, ci sto lavorando da quasi 1 anno, meccanicamente sono a buon punto, adesso sto aspettando gli elettronauti per l'impianto elettrico..mi piacerebbe aprire una discussione nella sezione Mits come avevo fatto a suo tempo per una macchina simile perchè ritengo sia interessante. Uso per la prima volta IQ-R, sono 33 assi di cui 30 in SSCNet e 3 in CC Link IE Field(mai usati) , sistema di visione Keyence, 2 robot su rack,circa 200 tra I/O digitali, una 30 ina su Ciabatte CC Link IE Field Basic.. insomma un bel progettino per la sezione che è sempre praticamente vuota. 

 

Sto studiando il sistema ed estrapolando i flussi di lavoro, ma al solo pensiero di dover usare Melsoft Navigator mi viene da spararmi in bocca. Questo per riallacciarmi al discorso fronti..magari fossero quelli i problemi! Devo inventarmi le capriole per fare quello che col Tia farei in un secondo. Anche solo il fatto di avere tutti gli ambienti separati( Plc, Robot, Hmi, Motion ) ..rende le cose davvero pesanti. 

[leleviola]

@step-80 che bei lavori che fai, complimenti,

ma sai i problemi dei fronti io li trovo solo fonte di possibile errore, sarò fatto male ma la penso così, a ognuno le proprie fisime mentali,

sul fatto di dividere gli ambienti è utile anche per non mescolare troppo le cose, io non la trovo poi un problema, vero è che rintracciare una variabile unicamente all'interno di un sistema come fa Siemens è ovviamente una gran cosa ma è anche vero che come fa Mitsubishi separare gli ambienti di sviluppo del plc di logica da quello robot è comunque una gran cosa anche se fra di loro devono comunicare, comunque mi sa che andiamo un po' OT, meglio che rientriamo nei ranghi altrimenti Livio ci bacchetta...

[step-80]

@leleviola io invece la vedo diversamente. Quando hai 2 robot che compiono anche solo una 20ina di movimenti, e di ogni movimento vuoi crearti le variabili per poter correggere quelle posizioni in X,Y,Z,A,B,C , ecco che saltano fuori un bel pò di dati. Dover creare le stesse variabili in 2 o più ambienti diversi io lo reputo ostico, in quanto potrei crearle in un ambiente comune dove se modifico il nome di un oggetto non devo per forza ricordarmi dei posti in cui l'ho usato per andare a modificarlo ovunque. Ripeto: l'ho sempre fatto e ahimè lo farò anche questa volta ma non ne sono per niente entusiasta. Poi chi lo usa davvero sa benissimo di cosa sto parlando. Il discorso delle ritentive credo sia un dramma per chiunque usi questi plc .. in poche parole devo prevedere a monte quante retain mi serviranno, questo porta inevitabilmente a sovrastimare il tutto per mantenere un buon margine di sicurezza. Ma non puoi nemmeno sovradimensionare troppo perchè la retain non è infinita ..

Col Gx2 c'era anche il limite di non poter annidare strutture e questo per me era un altro grande problema. 

[leleviola]

è verissimo quello che dici e secondo lo stile di TIA quello che dici sarebbe possibile ma con quello che usi con qualche difficoltà, i giap sono forse più precisi e concisi alla base delle cose e magari si perdono in altro, in TIA sono molto vicini alla perfezione

[Livio Orsini]

 

step-80

Non per polemica o per difendere Melsoft, di cui poco m'importa (come poco m'importa di TIA), visto che oramai non uso più PLC, ma solo per amor di discussione.

 

 

31 minuti fa, step-80 ha scritto:

Il discorso delle ritentive credo sia un dramma per chiunque usi questi plc ..

 

Scusami ma io non vedo tutta questa difficoltà, forse perchè sono abituato a lavorare in un certo modo.

Prima di stendere il programma ho il mio elenco di variabili globali e di variabili "ritentive", quindi si sa lo spazio di memoria che andranno ad occupare.

 

31 minuti fa, step-80 ha scritto:

Dover creare le stesse variabili in 2 o più ambienti diversi io lo reputo ostico,

 

Questo problema non lo capisco. Al limite nomini XY_1 nell'ambiente 1, XY_2 nell'ambiente 2, etc. Se devi variare XY_3 nell'ambiente 3, vai anche a variare Xy_1 e XY_2.

 

50 minuti fa, leleviola ha scritto:

altrimenti Livio ci bacchetta...

 

No, non è poi così OT; tuttal più separo i messaggi ed apro una nuova discussione.😉

Modificato: 30 agosto 2021 da Livio Orsini

[step-80]

Buonasera Livio, grazie per la risposta

 

55 minuti fa, Livio Orsini ha scritto:

Prima di stendere il programma ho il mio elenco di variabili globali e di variabili "ritentive", quindi si sa lo spazio di memoria che andranno ad occupare.

 

Forse mi sono espresso male, la mia critica non era tanto riferita al fatto che non posso sapere a priori quanta memoria ritentiva andrò ad usare, quanto al fatto che l'area di memoria dichiarata come ritentiva deve essere per forza contigua. Ipotizziamo di avere una struttura dati per la funzione 'Pompaggio'. Dentro avrò varie variabili utili al funzionamento della detta funzione che possono essere binari, byte, word, dword ecc. Ipotizziamo di dover creare all'interno della struttura altre strutture tipo 'setup' , 'automatico' ecc ecc. ecco, già questo non si può fare perchè non è permesso l'annidamento. Qualora fosse possibile, dovrei per forza assegnare un indirizzo fisico a tutte le variabili per poter accedere ad esse da Hmi e qui ho 2 strade: assegnare le variabili UNA AD UNA, in modo da poter decidere quali ad area Retain e quali no, oppure sfruttare una delle poche comodità della piattaforma che è quella del completamento automatico.  Questo porta però ad avere poi tutte le variabili con lo stesso indirizzo pardon della stessa classe. Si può aggirare il problema certo, ma non è il massimo quando si hanno molti dati e molte strutture. Mi spiego meglio:

 

Struttura Pippo: 

Dato X : Bool; 

Dato Y: Bool;

Dato Z: Word 

Dato J: DWord

 

Digito 'D0.0' nel campo di 'Dato X' ed automaticamente mi vengono compilate le altre nel seguente modo:

 

Dato X : Bool D0.0

Dato Y: Bool D0.1

Dato Z: Word D1

Dato J: DWord D2

 

Supponiamo di aver dichiarato come ritentiva l'area che va da D0 a D1000. Mi trovo che anche i primi 2 bit lo saranno, magari non volevo. So che sembrano baggianate ma vi assicuro che usando pesantemente il programma poi si sentono...noi programmatori poi siamo pigri si sa, molto..😁

 

Quote

Questo problema non lo capisco. Al limite nomini XY_1 nell'ambiente 1, XY_2 nell'ambiente 2, etc. Se devi variare XY_3 nell'ambiente 3, vai anche a variare Xy_1 e XY_2.

 

E' esattamente quello che faccio ora. Però capite che non è il massimo, e l'errore è dietro l'angolo. Sono inezie mi rendo conto, ma siamo quasi nel 2022, fra poco andremo a fare le ferie su Marte. Mi sembra impossibile dover lavorare ancora in questo modo..

[batta]

1 ora fa, Livio Orsini ha scritto:

Prima di stendere il programma ho il mio elenco di variabili globali e di variabili "ritentive", quindi si sa lo spazio di memoria che andranno ad occupare.

Spostiamo l'esempio da ritentive/non ritentive semplicemente a come gestire il database delle variabili.
Omron, tanto per citare un plc jap, se non sbaglio, anche nell'ultima versione di sistema di sviluppo, è sempre legato alla DM, con tanto di indirizzi fisici.
Ora faccio un esempio classico, ma che mi è capitato davvero, di un pallettizzatore (con Omron).
Chi sviluppò il software (non io, ma non sarebbe cambiato nulla), dimensionò le variabili per i tipi di pallettizzazione secondo un criterio che, a quel tempo, sembrava estremamente abbondante. Col tempo, gli indirizzi delle DM previsti in origine si esaurirono. Ed ecco che iniziarono i salti mortali, aggiungendo altre variabili in indirizzi liberi dove si poteva.
Con una gestione dei dati tipo Siemens (ma non solo Siemens, semplicemente una gestione dati non legata ad indirizzi fisici) sarebbe bastato modificare la dimensione di un array.
Ecco, questo, come difetto e come perdita di tempo, rispetto alla variabile di appoggio per rilevare un fronte, mi pare che sia 10 mila volte più grave.
Questo sì che è un vero UCAS!

 

1 ora fa, Livio Orsini ha scritto:

Questo problema non lo capisco. Al limite nomini XY_1 nell'ambiente 1, XY_2 nell'ambiente 2, etc. Se devi variare XY_3 nell'ambiente 3, vai anche a variare Xy_1 e XY_2.

Devi comunque fare la stessa operazione più volte, e ti porta via tempo. E aumenta anche la possibilità di introdurre errori, molto più di una variabile per il fronte.