TIA Portal e fronti di salita

[batta]

7 ore fa, Lucky67 ha scritto:

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

Vuoi sapere cos'è, secondo me, veramente anacronistico? Rimanere vincolati agli indirizzi assoluti, come fanno alcuni giapponesi.

TIA ha quello che, secondo me, è il miglior editor di testo strutturato, ti permette (non tutti lo fanno) di dichiarare array di dimensione ignota, soprattutto se gestite come "tipi di dati" tutte le modifiche alle variabili nel PLC te le ritrovi riportate in automatico anche nel HMI, e tu ti ostini sulla variabile di appoggio dei fronti?
TIA, ovviamente, non è esente da difetti, ma trovami dei difetti veri, non questo.
 

[batta]

3 ore 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.

Oggi non c'è più bisogno di prevedere in anticipo quante e quali variabili ti servono. Mi servono variabiliritentive? Al bisogno, le aggiungo in una struttura ritentiva. Mi servono variabili non ritentive? Al bisogno, le aggiungo in una struttura non titentiva.
Abbandonando gli indirizzi assoluti, non esiste più il problema di dover lasciare variabili di riserva in previsione delle modifiche.

[leleviola]

Verissimo quello che dici batta sulle qualità del sistema teutonico, per non fare troppa pubblicità, ma purtroppo proprio perchè ha tutte ste qualità che ci si debba ostinare a obbligare l'utente a gestire variabili che tranquillamente potrebbe gestire il sistema è in una qualche maniera comunque anacronistico, come il sistema gestisce in maniera autonoma i dati ritenitivi nell'organizzazione dei dati potrebbe tranquillamente gestire anche la questione che obbliga l'utente a gestire i fronti,  mettila come vuoi ma è più o meno così, poi ognuno come dicevo ha le sue fisime mentali

[Lucky67]

3 ore fa, batta ha scritto:

come fanno alcuni giapponesi.

 

Non mi risulta che lo stato dell'arte sia dei giapponesi. Io ho parlato ad esempio di editor italiani (e mi pare che uno lo abbia usato anche tu se ricordo qualche tua domanda su dei dettagli di funzionamento) dove l'indirizzamento assoluto lo hai solo per assegnare gli ingressi e le uscite fisiche (come siemens d'altronde). Il resto lo fa in automatico a meno che tu non debba interfacciarti con un HMI (ma questo lo fai anche con siemens se non usi i loro pannelli). Hai mai provato a interfacciare un s7 1200 con weintek esportando variabili e DB nel formato non ottimizzato? Credimi è meglio l'indirizzamento assoluto.

[Lucky67]

3 ore fa, batta ha scritto:

e tu ti ostini sulla variabile di appoggio dei fronti

 

Non ho nessuna ostinazione: reputo tale sistema completamente inutile e vetusto...che poi per te non rappresenti un problema mi fa piacere ma se permetti, ciò che rappresenta una sciocchezza per te, per me può essere una bella scocciatura..tutto qui.

3 ore fa, batta ha scritto:

oprattutto se gestite come "tipi di dati" tutte le modifiche alle variabili nel PLC te le ritrovi riportate in automatico anche nel HMI

 

Certo..se usi tutto Siemens...peccato che la parte HMI siemens sia una ciofeca inguardabile dal punto di vista grafico e stilistico (oltre al costo che è il triplo della media) e quindi molti clienti pretendono il plc siemens perchè il mercato richiede quello ma vogliono pannelli di altre case perchè hanno una presentazione nettamente superiore!

[Lucky67]

16 minuti fa, Yiogo ha scritto:

i nikmane troppo lunghi sono un difetto perchè ti perdi quando guardi il programma

gestisci come vuoi il campo descrizione, peraltro anche in quello cerco di non esagerare

ma 32 caratteri come nonme di simbolo sono già una quantità allucinante

 

Concordo...per spiegare i passaggi esistono i commenti: i nomi delle variabili devono avere un senso ma se sono chilometrici la lettura diventa poco agevole..

[Livio Orsini]

12 ore fa, batta ha scritto:

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.

 

Su questo sono perfettamente d'accordo. Essendo abituato io alla programamzione di mini computer e microcontrollori, l'allocazione fisica dei dati, ma anche del codice, è normale lasciarla al compilaore; solo in alcuni casi particolari si specifica l'indirizzo fisico inizialedi un blocco dati o di un blocco di codice.

 

13 ore fa, batta ha scritto:

Questo sì che è un vero UCAS!

 

Gli UCAS, com e la stupidità, non sono appannaggio esclusivo di un popolo o di una cultura; però i teutonici, per loro mentalità, sono predisposti ad implementare UCAS in qualsiasi campo. E l'esatto duale della nostra mentalità che è anarcoidee portata ad evitare le regole.

[step-80]

Quote

non è un limite, è un pregio

 

i nikmane troppo lunghi sono un difetto perchè ti perdi quando guardi il programma

gestisci come vuoi il campo descrizione, peraltro anche in quello cerco di non esagerare

ma 32 caratteri come nonme di simbolo sono già una quantità allucinante

 

Questione di punti di vista. Personalmente non amo dare un nome ad una variabile che non la identifichi bene e subito. Puoi giocare con la descrizione, ma preferisco cambiare solo il nome della variabile(se devo) e vederla aggiornarsi ovunque piuttosto che andarne a modificare la descrizione ovunque usata. 

C'è poi un altro discorso. Usando DB con opportune strutture, magari le quali contengono altre strutture, non c'è bisogno di dare nomi lunghi.

 

Esempio: Asse1.Setup.Pallet1.TargetPosition1

 

In questo modo ci possono essere altre 200 variabili chiamate 'TargetPosition1' in giro per il programma , che saranno sempre e comunque identificabili dal DB o dalla struttura che le contiene. Mi sembra anche un modo molto ordinato per organizzare il lavoro. Ecco provate ad identificarla senza DB e senza strutture, vedrete che i 32 caratteri non sono poi molti, e parlo come uno che odia dare nomi lunghi, se potessi eviterei volentieri ma non ho molta scelta. 

 

Quote

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.

 

@batta hai centrato perfettamente il mio discorso, probabilmente perchè ci hai sbattuto la testa. Non è sempre detto che io possa sapere a priori la quantità di variabili , retain e non, che devo usare. Un caso classico credo che sia quello delle ricette. Il cliente oggi chiede acqua, farina e lievito, ma fra un anno potrebbe chiedermi di aggiungere il sale per esempio, e con il sistema che uso io non hai molta scelta. Personalmente faccio cosi: 

 

Ricetta_1

Acqua : Word ; D0

Farina : Word: D1

Lievito: Word: D2

FreeVar1: Word : D3

FreeVar2:Word: D4

..

..

FreeVar99: Word : D99

 

Ricetta_2

Acqua : Word ; D100

Farina : Word: D101

Lievito: Word: D102

FreeVar1: Word : D103

FreeVar2:Word: D104

..

..

FreeVar99: Word : D199

 

Quante 'FreeVar' lascio? Bella domanda! considerando che è sempre una soluzione che non mi piace, perchè se va bene ho un sacco di memoria retain sprecata, se va male mi trovo a dover trovare spazio da un altra parte oppure a rifare le strutture spostando tutti i dati con i casini che potete immaginare. E' logico pensare che si lasci sempre molto piu spazio del necessario per non incorrere in problemi ma non la reputo una gran trovata. Se poi nella struttura sono presenti (come spesso accade) dati di diverso tipo, la situazione non migliora affatto. Mi è capitato un annetto fa di rifare una macchinetta fatta col 1200 e non mi sembrava vero di poter inserire dati cosi ordinatamente, senza fatica e senza spaccarmi la testa. Da questo punto di vista, Siemens non si batte. Lasciamo stare la pesantezza, gli aggiornamenti e tutto il resto..parlando puramente di organizzazione del lavoro secondo me è avanti chilometri.

 

 

[batta]

11 ore fa, Yiogo ha scritto:

ma secondo me lo ST migliore in assoluto è CodeSys, peraltro considera che non è il programma che conosco di più ma è veramente buono

l'hai provato ?

L'ho provato poco e, per quel poco che l'ho provato, ritengo l'editor ST di Siemens parecchio più avanti.
Forse è solo questione di abitudine.

 

14 ore fa, leleviola ha scritto:

ma purtroppo proprio perchè ha tutte ste qualità che ci si debba ostinare a obbligare l'utente a gestire variabili che tranquillamente potrebbe gestire il sistema è in una qualche maniera comunque anacronistico

Io non dico che anche Siemens potrebbe lasciar fare al sistema, ma non mi crea nessuna difficoltà dover dichiarare la variabile di appoggio. Stiamo parlando della pagliuzza, non della trave.

 

11 ore fa, Lucky67 ha scritto:

peccato che la parte HMI siemens sia una ciofeca inguardabile dal punto di vista grafico e stilistico (oltre al costo che è il triplo della media)

D'accordo sul costo elevato (non il triplo, comunque), ma non sulla "ciofeca".
Sia chiaro, sono il primo a sostenere che i pannelli Weintek da te citati (e ce ne sono anche altri) abbiano un ottimo rapporto prezzo/qualità, ma cosa mi serve risparmiare mille euro sull'acquisto del pannello operatore se poi perdo una settimana in più per lo sviluppo del software? Sono scelte che, a mio avviso, hanno senso solo su produzioni di serie, o su macchine/impianti molto simili, dove ti ritrovi con buona parte del software invariato o quasi. Io, in oltre trent'anni di programmazione, non ho mai fatto due macchine o due impianti uguali.

 

2 ore fa, step-80 ha scritto:

hai centrato perfettamente il mio discorso, probabilmente perchè ci hai sbattuto la testa

Ciao, Matteo.
Credo che ogni programmatore abbia sbattuto la testa nel problema di quante e quali variabili di riserva dichiarare.
Abbandonare l'indirizzamento assoluto e poter aggiungere, togliere e modificare le variabili a piacere, quando serve, senza patemi, è una comodità impagabile.
Io vedo ancora miei colleghi che per alcune operazioni usano ancora indirizzamenti assoluti. Per me, gli unici indirizzi assoluti rimasti sono quelli degli I/O e dei bit di sistema.
Sposti variabili, aggiungi variabili, togli variabili, e tutto il resto del programma funziona senza dover modificare nulla (pannello operatore compreso, se è Siemens).
Se mi avessero parlato di una simile possibilità 20 anni fa, avrei chiesto su quale libro di fantascienza l'avevano letto.

 

[Lucky67]

42 minuti fa, batta ha scritto:

L'ho provato poco e, per quel poco che l'ho provato, ritengo l'editor ST di Siemens parecchio più avanti.

 

su questo concordo...secondo me è ancora più crucca dei crucchi siemens...:)

43 minuti fa, batta ha scritto:

non il triplo, comunque

 

Compara un banale 7" o 10" siemens e weintek e vedrai che siamo quasi a quei livelli...

[step-80]

Quote

Compara un banale 7" o 10" siemens e weintek e vedrai che siamo quasi a quei livelli...

 

@Lucky67 non per difendere nessuno, ma io compro da diverso tempo ormai solo pannelli Mitsubishi serie GOT2000 (la più bellina) e non sono per nulla economici , anzi. Ho usato anche weintek ma poi, come diceva @batta , mi sono accorto che impiegavo più a scrivere l'applicativo che altro, e il tempo perso non colmava il risparmio dato che anch'io non faccio mai e poi mai 2 macchine uguali. Weintek non era per nulla male, ambiente di sviluppo gratuito e assistenza buona, ma far comunicare il dispositivo col plc non era sempre cosi immediato. Poi c'era sempre il solito problema(motivo per il quale ora uso tutto Mits) : in caso di malfunzionamenti e 2 apparati diversi, scattava in automatico lo scaricabarile. Con la stessa marca, ciò è impossibile ed almeno qui ho un pensiero in meno. 

Per la cronaca comunque, con le mie attuali scontistiche pago un 15" , 65000 colori ecc ecc circa 1800 euro. 

[Lucky67]

20 minuti fa, step-80 ha scritto:

Per la cronaca comunque, con le mie attuali scontistiche pago un 15" , 65000 colori ecc ecc circa 1800 euro. 

 

Appunto! Stessa dimensione Weintek ma con 16 milioni di colori costa poco più di 1000 euro. Tra parentesi non so quelli che usi tu, ma questo ha la possibilità di andare in pass through (per la telemanutenzione del plc ad esempio). oltre a 2 porte seriali (oltre alla ormai di serie ethernet) e il case in alluminio e non la solita plasticaccia.

Per quanto riguarda la programmazione a dire il vero non capisco le difficoltà aggiuntive che tu vedi. Tra parentesi, visto che tu hai parlato di ricette, ha già un editor integrato per le ricette con apposito wizard e in un battibaleno hai già configurato tutto. In più, per la maggior parte dei protocolli (mitsubishi inclusa) puoi importare direttamente le tag che hai sviluppato nell'editor plc e quindi ti risparmi anche l'indirizzamento delle variabili.

[batta]

26 minuti fa, Lucky67 ha scritto:

Per quanto riguarda la programmazione a dire il vero non capisco le difficoltà aggiuntive che tu vedi.

Io ho usato poco i Weintek ma, per quel poco che li ho usati, non posso che parlarne molto bene, soprattutto in rapporto al prezzo.
Però, sviluppare un applicativo con un Weintek o (per me) con un Siemens, richiede tempi ben diversi, non fosse altro che per la gestione delle variabili.
E il tempo che impiego in più, non mi viene compensato dal risparmio sull'acquisto dell'hardware. Come detto, tutto cambierebbe nel caso di progetti simili, dove il maggior tempo di sviluppo del primo progetto viene poi spalmato sui diversi lavori.

[Lucky67]

2 minuti fa, batta ha scritto:

Io ho usato poco i Weintek ma, per quel poco che li ho usati, non posso che parlarne molto bene, soprattutto in rapporto al prezzo.
Però, sviluppare un applicativo con un Weintek o (per me) con un Siemens, richiede tempi ben diversi, non fosse altro che per la gestione delle variabili.
E il tempo che impiego in più, non mi viene compensato dal risparmio sull'acquisto dell'hardware. Come detto, tutto cambierebbe nel caso di progetti simili, dove il maggior tempo di sviluppo del primo progetto viene poi spalmato sui diversi lavori.

 

Non voglio insistere perchè non rappresento weintek ma solo per onor di verità, se tu importi le tag da siemens a weintek lavori allo stesso modo. C'è solo un inconveniente: ogni volta devi importare le DB e le variabili dopo averle esportate da tia portal e devi cambiare il nome della DB (l'importazione riassegna le db tenendo conto dell'alfabeto) e questo purtroppo ogni volta che cambi anche una tag (nel senso che devi reimportare tutto il pacchetto delle DB). Però se non lavori a casaccio riesci a limitare le importazioni poichè sai già le variabili che dovrai visualizzare o manipolare.

[leleviola]

5 minuti fa, Lucky67 ha scritto:

 

Non voglio insistere perchè non rappresento weintek ma solo per onor di verità, se tu importi le tag da siemens a weintek lavori allo stesso modo. C'è solo un inconveniente: ogni volta devi importare le DB e le variabili dopo averle esportate da tia portal e devi cambiare il nome della DB (l'importazione riassegna le db tenendo conto dell'alfabeto) e questo purtroppo ogni volta che cambi anche una tag (nel senso che devi reimportare tutto il pacchetto delle DB). Però se non lavori a casaccio riesci a limitare le importazioni poichè sai già le variabili che dovrai visualizzare o manipolare.

Confermo per quel riguarda Weintek e ultimamente hanno fatto delle migliorie per l'importazione delle variabili, puoi direttamente importare le variabili in simbolico tramite la funzione Taginfo direttamente dal PLC in connessione oppure farlo dal file del progetto Siemens come uno vuole,

 

tornando al tema del post non la penso come dice batta, il fatto di generare ogni volta delle variabili "inutili" è solo fonte di errore e sono spesso gli errori più banali a creare i problemi più noiosi, questo è il mio pensiero

[batta]

6 minuti fa, leleviola ha scritto:

il fatto di generare ogni volta delle variabili "inutili" è solo fonte di errore

L'unico errore che potresti commettere, è di utilizzare la stessa variabile più di una volta. Basta che ti posizioni col cursore sulla variabile e, nella tabella delle informazioni, vedi subito quante volte viene usata.
Poi, visto che questa variabile la si usa solo per rilevare il fronte (ho visto anche chi la usa in lettura in altre parti del programma, ma non mi piace), non è nemmeno importante che abbia un nome descrittivo. Potresti crearti un array (nei merker, in un DB o dove meglio credi) dedicato al rilevamento dei fronti. Unica accortezza (come detto sopra), verificare di non usare la stessa variabile in più posti. Ma la stessa cosa vale per ogni variabile, mica solo per quelle dei fronti.

 

Poi, per come è gestita la memoria in Siemens, un fronte all'interno di una FC, che non ha una memoria statica, diventerebbe problematico nel caso di richiamo multiplo della stessa FC.
Personalmente ritengo che sapere esattamente dove viene memorizzato lo stato per il rilevamento del fronte non solo non sia un problema, ma potrebbe anche tornare utile.
Per esempio, posso decidere se questa variabile debba essere ritentiva oppure no, in modo da avere un diverso comportamento del fronte all'accensione del plc con condizione già vera.

 

Diciamo che non valuto certo la bontà di un plc da come vengono rilevati i fronti. Come già detto, ammesso che sia un difetto, si tratta di un difetto veramente minimo.

[leleviola]

5 ore fa, batta ha scritto:

L'unico errore che potresti commettere, è di utilizzare la stessa variabile più di una volta. Basta che ti posizioni col cursore sulla variabile e, nella tabella delle informazioni, vedi subito quante volte viene usata.

infatti è proprio per questo che non mi piace, perchè devo controllare io ciò che potrebbe fare il sistema, siccome spesso faccio uso di fronti e se la cosa si fa molto ripetitiva sarebbe per me, ripeto per me una palla inutile e fonte di facile errore di battitura perchè non c'è niente che te lo impedisce, devi controllare ogni volta.