Interpretare una stringa come un tag

[MaxT1978]

Buongiorno a tutti,

a me servirebbe sapere se c'è un'istruzione o un modo per far interpretare una stringa come un tag e ricavare poi il valore di questo tag attraverso l'interrogazione di questa interpretazione. Mi  spiego con uno pseudo esempio in SCL  di quello che sto cercando:

string1 := ""DB1_ListOfValue".Value1"; 

value := getValueFromSymbol(string1);

Grazie in anticipo.

MaxT1978

 

[batta]

Intendi che hai un valore scritto in formato stringa (esempio: "1234" che non è un numero, ma un testo), e vuoi trasformarlo in valore?
Se è così, c'è l'istruzione STR_VAL già pronta.

[MaxT1978]

16 hours ago, batta said:

Intendi che hai un valore scritto in formato stringa (esempio: "1234" che non è un numero, ma un testo), e vuoi trasformarlo in valore?
Se è così, c'è l'istruzione STR_VAL già pronta.

Ciao Batta, 

grazie per la risposta. No, non intendo questo. Io intendo trovare un modo che mi permetta di, data una stringa, scritta "a mano", interpretarla come tag già presente nel PLC, sia esso un merker, un I/O, un DB.  

MAxT1978

 

[batta]

Continuo a non capire.

[drn5]

Lui vuole passare all'interno di una stringa il valore che è il nome del Tag per far si che venga estratto il contenuto di questo Tag. 

 

Un immaginario utilizzo potrebbe essere quello che in una comunicazione il sistema riceva la stringa "Tag_serbatoio_temperatura" e il codice dopo aver estratto questa stringa che altro non è che il nome del Tag_serbatoio_temperatura restituisca "35" perchè quella è la temperatura del serbatoio. Questo ovviamente semplificherebbe moltissimo lato macchina una comunicazione "flessibile".

 

Questo non credo proprio sia possibile perchè i nomi dei tag vengono usati solo dall'editor, una volta compilato il codice i tag vengono "mutati" in locazioni di memoria e "perdono" coscienza del loro nome . Detta molto male.....

 

Almeno questo è quello che credo @MaxT1978 intenda..

[fedebg]

faccio un esempio, per vedere se ho capito:

in WinCC ho l'istruzione SmartTags()

se esiste il tag: nomeVariabile, int, collegato al PLC, posso per esempio scriverci il valore 123 usando l'istruzione:

SmartTags("nomeVariabile") = 123

Partendo da un valore stringa, "nomeVariabile", accedo quindi ad un Tag PLC.   Tutto questo vale solo su WinCC. Purtroppo, a livello PLC, non credo esista l'equivalente di SmartTags("nomeVariabile") .   Esempio di applicazione PLC: su PLC leggo su TCP messaggi JSON; anche se disponessi di un parser SCL, avrei bisogno, una volta decodificata la stringa, di accedere al tag tramite il suo nome.   Ho fatto una ricerca, ma ancora non ho trovato niente che su PLC offra la funzionalità equivalente a SmartTags("nomeVariabile"). La soluzione interesserebbe anche a me, molto.   Se invece a MAxT1978 serviva altro, ingorate il mio commento.   Cio

 

[MaxT1978]

Intanto vi ringrazio per le risposte!

 

33 minutes ago, drn5 said:

Lui vuole passare all'interno di una stringa il valore che è il nome del Tag per far si che venga estratto il contenuto di questo Tag. 

 

Un immaginario utilizzo potrebbe essere quello che in una comunicazione il sistema riceva la stringa "Tag_serbatoio_temperatura" e il codice dopo aver estratto questa stringa che altro non è che il nome del Tag_serbatoio_temperatura restituisca "35" perchè quella è la temperatura del serbatoio. Questo ovviamente semplificherebbe moltissimo lato macchina una comunicazione "flessibile".

 

Questo non credo proprio sia possibile perchè i nomi dei tag vengono usati solo dall'editor, una volta compilato il codice i tag vengono "mutati" in locazioni di memoria e "perdono" coscienza del loro nome . Detta molto male.....

 

Almeno questo è quello che credo @MaxT1978 intenda..

L'esempio calza, ma c'ha azzeccato più di tutti fedebg!

 

28 minutes ago, fedebg said:

faccio un esempio, per vedere se ho capito:

in WinCC ho l'istruzione SmartTags()

se esiste il tag: nomeVariabile, int, collegato al PLC, posso per esempio scriverci il valore 123 usando l'istruzione:

SmartTags("nomeVariabile") = 123

Partendo da un valore stringa, "nomeVariabile", accedo quindi ad un Tag PLC.   Tutto questo vale solo su WinCC. Purtroppo, a livello PLC, non credo esista l'equivalente di SmartTags("nomeVariabile") .   Esempio di applicazione PLC: su PLC leggo su TCP messaggi JSON; anche se disponessi di un parser SCL, avrei bisogno, una volta decodificata la stringa, di accedere al tag tramite il suo nome.   Ho fatto una ricerca, ma ancora non ho trovato niente che su PLC offra la funzionalità equivalente a SmartTags("nomeVariabile"). La soluzione interesserebbe anche a me, molto.   Se invece a MAxT1978 serviva altro, ingorate il mio commento.   Cio

 

Quello infatti che vorrei fare è un parser di espressione booleane. 

Ora, ho scritto anche sul forum Siemens per ampliare la ricerca a possibili soluzioni, ma nulla da fare. Allora c'ho pensato su ancora per qualche ora e alla fine sono arrivato ad una "meta-soluzione", perdonatemi il termine. Ma mi sono fermato in un punto ulteriore che vi spiego dopo o qui o in un altro topic, che non vorrei andare OT.

Mettiamo che debba fare il parsing di ("FCO_VLV1" AND "FCC_VLV2").

Il trucco che è trovato è il seguente: uso un FB e dichiaro n variant come ingresso. 

- verifico c'ho che viene passato e alimento il parser (che devo ancora fare...!)

- se una parentesi aperta è una nuova espressione, se chiusa, vuol dire che devo passare alla espressione successiva, se la stringa è un'operatore booleano faccio l'operazione corrispondente,ecc...

- ogni volta che trovo un variant diverso da null, lo converto comunque in una stringa che alimento progressivamente e che darò allo SCADA per la rappresentazione grafica.

- alla call dell'FB risulterà una cosa di questo tipo:

#l_open_bracket := '(';
#l_close_bracket := ')';

#l_op_AND := 'AND';
"FB2_Test_DB"(v_arg1:=#l_open_bracket,
              v_arg2:= "FCO_VLV1",

              v_arg3:= #l_op_AND,
              v_arg4:="FCC_VLV2",
              v_arg5:=#l_close_bracket);

Dove mi sono fermato ora è come iterare su variabili di tipo variant. Non so se è possibile discuterne in questo topic o in un altro ad hoc, ma in ogni caso il problema è se è possibile farlo sugli ingressi stessi dell'interfaccia di ingresso o se invece, appoggiandomi alle static dell'FB riesco comunque a far l'iterazione sulle variant copiate dagli ingressi.

Disponibile ad altri suggerimenti o prove da fare.

MaxT1978

 

[drn5]

Ok al parser, ma questo non risolve la tua richiesta iniziale. Con il parser poi dovrai farti per esempio un SPL con N condizioni 'precablate'. Questo darà una una risposta che seppur ampia sarà comunque rigida. Se vorrai acquisire il contenuto di un nuovo tag dovrai inserirlo a manina nel ciclo di verifica.

[MaxT1978]

1 hour ago, drn5 said:

Ok al parser, ma questo non risolve la tua richiesta iniziale. Con il parser poi dovrai farti per esempio un SPL con N condizioni 'precablate'. Questo darà una una risposta che seppur ampia sarà comunque rigida. Se vorrai acquisire il contenuto di un nuovo tag dovrai inserirlo a manina nel ciclo di verifica.

cos'è un SPL? 

E' chiaro che in questo modo la lunghezza dell'espressione è limitata al numero di ingressi variant dell'FB, ma in quel caso tengo conto del caso peggiore abbondando un po' per eccesso. Non capisco perchè dici che lo dovrei inseire a manina; se riuscissi a farlo con un ciclo for o while non ci sarebbe bisogno. 

 

[drn5]

Il punto sta per esempio nel "FCO_VLV1"...  quando lo passi in v_arg2, dall'altra parte dentro il tuo FB, devi fare un confronto tra il contenuto di v_arg2 e una stringa. Questo confronto dovrà essere ripetuto tante volte tante quante sono le variabili che vuoi riconoscere: "FCO_VLV1", "FCO_VLV2", "FCO_VLV3" e cosi via. Quindi questi confronti "cablati" funzioneranno per le varie variabili che specifichi. Il giorno in cui ti interesserà riconoscere "FCO_VLV567" dovrai inserire "a manina" un nuovo confronto per questa stringa.

 

Questo perchè per citarmi:

6 ore fa, drn5 ha scritto:

Questo non credo proprio sia possibile perchè i nomi dei tag vengono usati solo dall'editor, una volta compilato il codice i tag vengono "mutati" in locazioni di memoria e "perdono" coscienza del loro nome . Detta molto male.....

 

SPL (nel vecchio AWL)  era solo per fare un esempio, che però nel caso specifico non potrebbe essere usato perchè lavorava solo con variabili numeriche e non stringa.

 

[MaxT1978]

17 minutes ago, drn5 said:

Il punto sta per esempio nel "FCO_VLV1"...  quando lo passi in v_arg2, dall'altra parte dentro il tuo FB, devi fare un confronto tra il contenuto di v_arg2 e una stringa. Questo confronto dovrà essere ripetuto tante volte tante quante sono le variabili che vuoi riconoscere: "FCO_VLV1", "FCO_VLV2", "FCO_VLV3" e cosi via. Quindi questi confronti "cablati" funzioneranno per le varie variabili che specifichi. Il giorno in cui ti interesserà riconoscere "FCO_VLV567" dovrai inserire "a manina" un nuovo confronto per questa stringa.

 

Questo perchè per citarmi:

 

SPL (nel vecchio AWL)  era solo per fare un esempio, che però nel caso specifico non potrebbe essere usato perchè lavorava solo con variabili numeriche e non stringa.

 

Intanto ti ringrazio per le risposte che mi stai dando, ma come mi sembra di capire dalla varia documentazione e forum in giro, mi sembra chiaro che un for o un while coi variant non si possa fare. Quindi anche a me veniva in mente di procedere, per la parte di riconoscimento dei variant, variabile per variabile senza loop. 

Quindi nella prima parte dell'FB dovrò fare tanti case quanti sono le variant di ingresso. Mi rendo conto che ci sono dei limiti in questo approccio, ma non avendo a disposizione altro tipo di istruzioni e gestione della memoria, francamente, per lo scopo che abbiamo non trovo, al momento altre soluzioni. Se ti/vi viene in mente, son ben accette.

Grazie mille ancora.

MaxT1978

 

P.S. SPL intendi dire il vecchio LOOP di AWL, giusto?

[batta]

15 ore fa, MaxT1978 ha scritto:

P.S. SPL intendi dire il vecchio LOOP di AWL, giusto?

In AWL, SPL assomiglia un po' ad un CASE, non ad un loop.

[ifachsoftware]

Il contrario lo puoi fare con GetSymbolName , ossia dato il nome di un Tag , potresti ottenerne la stringa Descrittiva.

 

Purtroppo da Stringa a Tag non lo ho trovato ; sarebbe molto interessante.

 

 

[MaxT1978]

Buongiorno a tutti,

piccolo aggiornamento: confermo che ho usato il metodo sopra descritto per passare i singoli elementi dell'espressione booleana ad una funzione. All'interno di quest'ultima richiamo un FC che all'interno risolve il parsing in modo ricorsivo ovvero costruendo un albero binario. Devo ancora analizzare i limiti fino a quanti livelli di stack posso spingermi e mettere le relative eccezioni per evitare lo stack overflow. Come scritto in un altro post confermo anche che è imbarazzante il debug in SCL con il TIA non potendo usare "step over, step into,..." e questo ha reso enormemente più difficile e lento l'ottenimento del risultato.

Grazie ancora per il supporto.

 

[batta]

Premetto che, sinceramente, non ho ancora capito l'utilità di quello che stai facendo. A livello di programma, non ho mai sentito questa necessità. Se è per comunicazioni di vario tipo, ci sono altri sistemi già fatti, testati e performanti (OPC-UA, Snap7, solo per citarne un paio).
 

Per quanto riguarda l'editor, quello del TIA per il testo strutturato è il miglior editor sul quale ho avuto occasione di mettere le mani.
Stiamo sempre parlando di PLC, non mi puoi fare il confronto con Visual Studio e tools di sviluppo orientati esclusivamente alla programmazione.

[MaxT1978]

On 2/26/2022 at 11:26 AM, batta said:

Premetto che, sinceramente, non ho ancora capito l'utilità di quello che stai facendo. A livello di programma, non ho mai sentito questa necessità. Se è per comunicazioni di vario tipo, ci sono altri sistemi già fatti, testati e performanti (OPC-UA, Snap7, solo per citarne un paio).

Cerco di spiegartelo con un disegno. Devi immaginare ci sia una sala di controllo e per esempio su una pagina dello SCADA devono visualizzare il motivo per il quale non si apre una valvola o non parte una pompa.  In fase di progetto o di aggiornamento, finora, ci si mette d'accordo via mail su quali sono le condizioni di abilitazione all'apertura o della partenza della pompa e i relativi indirizzi assoluti nel PLC. Esempio per una valvola, la VLV1 (solo a titolo di esempio senza per forza un riscontro reale): DB2.DBX3.4 è finecorsa chiuso FCC_VLV1, DB2.DBX3.5 è pressione ok PRESS_OK, DB5.DBX3.1 è valvola principale aperta (giusto per fare un esempio) FCO_MAINVLV e DB15.DBX32.1 è controllo da locale LOC_REM. 

Prova a immaginare che questo sia solo un semplicissimo esempio e che in realtà le espressioni abbiano 15-20-25 condizioni. Il problema sta anche e soprattutto  nel momento in cui si deve cambiare una condizione, oppure che non c'è più quell'altra condizione, ecc. Richiede di passare la modifica, a mano, nel senso con la medesima procedura, via mail con gli indirizzi assoluti;  magari ce ne sono altre 20 da fare più o meno semplici. 

Con questo sistema si cambia una volta sola, nel PLC, passando gli elementi dell'espressione alla funzione come  è spiegato in uno dei post precedenti: viene cambiata allo stesso tempo sia la stringa da passare allo SCADA per il parsing e la visualizzazione grafica sia il risultato dell'espressione nel PLC che blocca di fatto l'apertura della valvola o la ripartenza della pompa.

Spero ora sia  un po' più chiaro

Quanto all'ambiente di sviluppo:

On 2/26/2022 at 11:26 AM, batta said:

Per quanto riguarda l'editor, quello del TIA per il testo strutturato è il miglior editor sul quale ho avuto occasione di mettere le mani.
Stiamo sempre parlando di PLC, non mi puoi fare il confronto con Visual Studio e tools di sviluppo orientati esclusivamente alla programmazione

francamente lo  trovo davvero zoppo, incompleto: mancano appunto gli step into, over, all che sono assolutamente necessari in fase di debug/simulazione con breakpoint, per non parlare del fatto che i valori delle variabili temporanee e statiche non si possono visualizzare. Imbarazzante. E lo confronto con gli ambienti che lavorano su Codesys (Schneider, ABB, Beckhoff,...), ma anche Automation Studio di B&R che è proprietario, per esempio. Le differenze secondo me sono abissali per la velocità e il modo di programmazione. La scelta di Twincat 3, sempre per fare un esempio, è stata di appoggiarsi su Visual Studio, devi prenderci un po' la mano, ma poi ottieni molte soddisfazioni. Secondo me chi ha progettato TIA ha fatto un salto grosso indietro e sembra  senza guardarsi attorno. Cosa che al tempo dell'uscita di Step 7, invece è stata una quasi rivoluzione nell'automazione, un prodotto all'avanguardia. E la pecca, il TIA non ce l'ha solo in SCL, ma anche in AWL. Lui non nasce con AWL gliel'hanno appiccicato per evitare una "sommossa popolare", ma non hanno messo, penso per la diversa gestione della memoria interna, le informazioni dello status register, del registro degli indirizzi A1 e A2. Quindi con un gravissimo handicap nel caso di uso di puntatori che con AWL erano e sono all'ordine del giorno.

TIA Portal secondo me quindi è nato male e rimane zoppo, incompleto sotto molti punti di vista importantissimi.

 

Max1978

[drn5]

19 minuti fa, MaxT1978 ha scritto:

relativi indirizzi assoluti

Sulla storia degli indirizzi assoluti, pur venendo dalla programmazione in assembler in cpm su su fino a oggi, quando usi i pannelli Siemens i db?.DBX?.? te li puoi finalmente dimenticare. E poi non sarai lì tutti i santi giorni a modificare la logica del programma. Mi auguro.

24 minuti fa, MaxT1978 ha scritto:

AWL

Sulla storia del awl, sostituito dal stl, è vero che non ha le stesse potenzialità del vecchio step7, ma anche qui ritorniamo al punto sopra....

Sul debug in scl ti do ragione, si può fare di meglio...magari nel tia20....

[batta]

12 ore fa, MaxT1978 ha scritto:

con breakpoint, per non parlare del fatto che i valori delle variabili temporanee e statiche non si possono visualizzare

Stai dicendo delle cose assolutamente non vere. Ho l'impressione che tu non lo conosca bene, il TIA.
Proprio nel confronto con altri ambienti basati su Codesys che ho avuto occasione di provare, trovo il TIA più avanti e più user friendly.

 

Per quanto riguarda invece la spiegazione del perché fare tutto questo lavoro, non so se definirlo più utile o se estremamente pericoloso.
Opinione personale, ovviamente.

Modificato: 1 marzo 2022 da batta

[MaxT1978]

12 hours ago, drn5 said:

Sulla storia degli indirizzi assoluti, pur venendo dalla programmazione in assembler in cpm su su fino a oggi, quando usi i pannelli Siemens i db?.DBX?.? te li puoi finalmente dimenticare. E poi non sarai lì tutti i santi giorni a modificare la logica del programma. Mi auguro.

Per il controllo locale usiamo pannelli Siemens, ma da remoto è uno SCADA che non implementa driver Siemens e la comunicazione avviene in TCP/IP perciò è necessario passare attraverso indirizzamento assoluto.

 

12 hours ago, drn5 said:

sostituito dal stl

senza poter usare i puntatori è più che zoppo...secondo me quelli che hanno pensato il TIA non si sono minimamente guardati attorno e purtroppo non hanno tenuto il buono del S7...

12 hours ago, drn5 said:

tia20

 

Mi ricordo che era intorno al 2010 che uscì la versione 10.5, questa è la prima che ricordo e che si poteva andare nelle varie filiali Siemens a vedere le potenzialità. Per essere un ambiente di progettazione e programmazione che puntava nell'SCL nel principale linguaggio, mi pare che se nella vs attuale non hanno inserito queste funzionalità, ho paura che nemmeno nella 200 che uscirà nel 2029 😉 ci saranno! 

 

Max1978

[MaxT1978]

25 minutes ago, batta said:

Stai dicendo delle cose assolutamente non vere. Ho l'impressione che tu non lo conosca bene, il TIA.

perchè dici che non sono vere? Le ho testate e mi risulta così. In caso di breakpoint, per lo meno, non vedi queste variabili cambiare. E in diversi forum del support si lamentano di questa assurda mancanza. Solo le statiche le vedi, ma guardandole nel DB di istanza che è scomodissimo. Con  Codesys, già dalla vs 2 questa era acqua fresca. Non capisco come fai a dire che è più avanti e user friendly, ma de gustibus....

 

39 minutes ago, batta said:

Per quanto riguarda invece la spiegazione del perché fare tutto questo lavoro, non so se definirlo più utile o se estremamente pericoloso.
Opinione personale, ovviamente

l'importante è che almeno sia riuscito a spiegarti il motivo.

 

Max1978

[STEU]

1 ora fa, MaxT1978 ha scritto:

Per il controllo locale usiamo pannelli Siemens, ma da remoto è uno SCADA che non implementa driver Siemens e la comunicazione avviene in TCP/IP perciò è necessario passare attraverso indirizzamento assoluto.

 Prova ad abilitare nelle proproprietà della CPU il server web, e poi ti si apre un mondo che probabilmente farà sembrare obsoleto il tuo scada

[batta]

3 ore fa, MaxT1978 ha scritto:

senza poter usare i puntatori è più che zoppo

Tutti (o quasi) si stanno orientando verso l'abbandono degli indirizzi assoluti e dei puntatori, e tu ti lamenti perché non ci sono più i puntatori. Che poi, non è nemmeno vero.

[batta]

3 ore fa, MaxT1978 ha scritto:

perchè dici che non sono vere?

 

 

 

#cnt è una variabile Stat.
#i e #tmpInt sono variabili temporanee.

 

Che poi, utilizzare i break point può essere estremamente pericoloso. Si può fare solo in simulazione, o con macchina/impianto fermo.
Personalmente, pur sapendo che esistono e come si usano, non li utilizzo mai.
Se devo capire cosa succede in qualche punto critico del programma, preferisco crearmi qualche variabile di debug a cui appoggiare i risultati che devo controllare.

 

 

Modificato: 1 marzo 2022 da batta

[MaxT1978]

On 3/1/2022 at 10:49 AM, STEU said:

Prova ad abilitare nelle proproprietà della CPU il server web, e poi ti si apre un mondo che probabilmente farà sembrare obsoleto il tuo scada

Mi pare quanto meno pretestuoso proporre un simil cambiamento senza conoscere struttura aziendale, dimensioni di impianto, ecc. 

 

21 hours ago, batta said:

Tutti (o quasi) si stanno orientando verso l'abbandono degli indirizzi assoluti e dei puntatori, e tu ti lamenti perché non ci sono più i puntatori. Che poi, non è nemmeno vero.

bisogna vedere tra questi tutti se metti soprattutto chi usa Siemens/TIA perchè con istruzioni come PEEK, POKE e Serialize ti rendono la vita abbastanza complicata rispetto a quanto fa la concorrenza. Giusto per fare un esempio di grave lacuna, manca l'istruzione Sizeof che agevola notevolmente l'approccio coi puntatori.  I puntatori bisogna usarli quando servono, non abusarne,poi, de gustibus.

21 hours ago, batta said:

Che poi, utilizzare i break point può essere estremamente pericoloso. Si può fare solo in simulazione, o con macchina/impianto fermo.
Personalmente, pur sapendo che esistono e come si usano, non li utilizzo mai.

capisco allora che non trovi imbarazzante SCL: non usi praticamente il debug. Io lo uso parecchio, ma è ovvio e infatti lo dici anche tu, che si deve usare in simulazione o con impianto fermo, sotto poi comunque determinate condizioni. Se ho un impianto in funzione o metto delle trappole, come fai tu, se ci sono delle cose semplici da verificare oppure di solito ho una copia dell'impianto per lo sviluppo, che faccio girare con il simulatore per poter usare quindi il debug di cui sopra...
Quanto alle statiche e alle temp, ammetto che mi sono preso un abbaglio perchè il refresh era talmente lento per 4-5 variabili (2-3 minuti e tenendo conto che non ho un PC "leggero") che non mi rinfrescava le variabili. Ciò comunque non fa che confermare che il TIA ha dei problemi di fondo che lo rendono oltre a quanto detto, anche molto lento. E non solo rispetto ad ambienti basati su Codesys.
Max1978

 

[batta]

1 ora fa, MaxT1978 ha scritto:

capisco allora che non trovi imbarazzante SCL: non usi praticamente il debug. Io lo uso parecchio, ma è ovvio e infatti lo dici anche tu, che si deve usare in simulazione o con impianto fermo, sotto poi comunque determinate condizioni. Se ho un impianto in funzione o metto delle trappole, come fai tu, se ci sono delle cose semplici da verificare oppure di solito ho una copia dell'impianto per lo sviluppo, che faccio girare con il simulatore per poter usare quindi il debug di cui sopra...
Quanto alle statiche e alle temp, ammetto che mi sono preso un abbaglio perchè il refresh era talmente lento per 4-5 variabili (2-3 minuti e tenendo conto che non ho un PC "leggero") che non mi rinfrescava le variabili. Ciò comunque non fa che confermare che il TIA ha dei problemi di fondo che lo rendono oltre a quanto detto, anche molto lento. E non solo rispetto ad ambienti basati su Codesys.

Scusami, ma non ci siamo proprio.
Come fai a sostenere che non uso il debug? Forse non mi lamento del debug del SCL del TIA solo perché lo conosco, e lo so usare.
Poi, raramente mi capita di dover analizzare con break points cosa succede, semplicemente perché lo so già cosa succede. Per qualche controllo particolare all'interno di un ciclo FOR quasi sempre è più che sufficiente aggiungere qualche variabile per il debug. Se non uso quasi mai i break points, molto semplicemente è perché non ne sento il bisogno.
E,per tua informazione, faccio anche largo uso del simulatore.
Poi, dai, per favore, tutto puoi dire, ma non che per il refresh di 4-5 variabili servono 2-3 minuti. Il refresh è semplicemente immediato! Ad occhio, non ci stai dietro alle variazioni.
Quindi, forse, non è tanto il TIA che ha problemi di fondo, ma sei tu che hai problemi di fondo con il TIA.
Ho capito che il TIA non ti piace ma, se lo devi criticare, fallo per i suoi reali problemi (mai detto che non ne abbia), non per quelli che ti inventi tu.

 

1 ora fa, MaxT1978 ha scritto:

bisogna vedere tra questi tutti se metti soprattutto chi usa Siemens/TIA perchè con istruzioni come PEEK, POKE e Serialize ti rendono la vita abbastanza complicata rispetto a quanto fa la concorrenza

Sviluppo anche programmi dove lo SCADA accede con indirizzi assoluti. Basta organizzare i dati per lo SCADA con un certo criterio, ed usare come "non ottimizzati" solo i blocchi dati ai quali ha accesso lo SCADA.
 

Poi, non so perché tu sostenga che non si possono usare i puntatori.
Piuttosto, io sostengo che i puntatori si debbano abbandonare.
Con i 300/400, con i puntatori ci giocavo in tutti i modi. Oggi, con 1200/1500, non so nemmeno più perché si dovrebbero usare i puntatori. Non è che non si possano usare, sono io che mi rifiuto di usarli. Ma scusa, c'è la possibilità di programmare totalmente in simbolico, spostando dati come e quando ti pare che tanto l'indirizzo non ti interessa, e tu vuoi rimanere legato alla "vecchia" programmazione con indirizzi assoluti e puntatori, dove se ti cambia un indirizzo non funziona più nulla? Dove non puoi fare un cross reference delle variabili perché sono indicizzate? Dai, non scherziamo!