Script - Esportare il valore dei TAG da TP-1500 Confort

[BAN003]

Buogiorno a tutti.

Problema : Ho un TP-1500 Confort con circa 500 tag analogici.

Dovrei trovare il modo di esportare i TAG e il loro valore su una memoria USB collegata all'HMI.

L'idea era di far leggere ad uno script l'elenco dei tag e poi scrivere il nome del tag e il valore su un altro file.

Ho provato con questo script :

Dim tagName, tagValue, tagFilenameI, tagFilenameO
	Dim strFilenameI, strFilenameO, strLine
	Dim fso, fsi, objFile, objFileO, objTag
	Dim valTag, x
	Dim fo, fi, fwModeAppend, fwModeInput, fwModeOutput
	Dim delimiter
	tagFilenameI = "\storage card USB\Tag.txt"
	tagFilenameO = "\storage card USB\Tag_Out.txt"
	
	fwModeInput=1
	fwModeOutput=2
	fwModeAppend=8
	delimiter = ";"
	
	
	valTag=0
'Specifies the file mode: Input (1), Output (2), Random (4) , Append (8), or Binary (32).

'apro un file in scrittura
	Set fo = CreateObject("FileCtl.File")
	fo.Open "\storage card USB\Tag_Out.txt", fwModeOutput


'apro un file in lettura	
	Set fi = CreateObject("FileCtl.File")
	fi.Open "\storage card USB\Tag.txt", fwModeInput

	
	Do
	x=0
'Leggo dal file di lettura il nome del tag e metto la riga letta in tagName
	tagName = fi.LineInputString

'leggo il valore del TAG e lo metto nella variabile tagValue	

tagValue=HmiRuntime.SmartTags(tagName)


' Scrivo la variabile strLine nel file di scrittura	
	strLine = tagName & delimiter & tagValue
	fo.LinePrint strLine
	
' Ciclo di ritardo inserito per rallentare l'esecuzione
	Do
		x=x+1
	Loop Until x<1000

' Sicurezza in caso di loop indesiderati
	valTag=valTag+1
	If valTag=2000 Then 
	Stop
	End If
	
	Loop Until fi.eof

'Chiudo il file in scrittura	
	fo.Close
'Chiudo il file in lettura	
	fi.Close

Il file tag.txt contiene questi tag per prova :

DB_DATE_TIME_Datario_PLC

DB_ANALOG_SCALE_LT_103
DB_ANALOG_SCALE_TT_102
DB_ANALOG_SCALE_AIT_101
DB_ANALOG_SCALE_AIT_102
DB_PLC_Output_K9_UV-57101
DB_ANALOG_SCALE_PIT_103
DB_ANALOG_SCALE_CIT_101
DB_ANALOG_SCALE_PIT_106
DB_ANALOG_SCALE_TT_103
FIT-104 Totalizer_Inlet_Flow
FIT-104 Totalizer_Volume

 

e il risultato è stato :

DB_DATE_TIME_Datario_PLC;4/5/2016 16:48:57

DB_ANALOG_SCALE_LT_103;0
DB_ANALOG_SCALE_TT_102;16.875
DB_ANALOG_SCALE_AIT_101;0
DB_ANALOG_SCALE_AIT_102;0
DB_PLC_Output_K9_UV-57101;False
DB_ANALOG_SCALE_PIT_103;0
DB_ANALOG_SCALE_CIT_101;0
DB_ANALOG_SCALE_PIT_106;0
DB_ANALOG_SCALE_TT_103;23.81944
FIT-104 Totalizer_Inlet_Flow;0
FIT-104 Totalizer_Volume;0

 

Come potete vedere ci sono moltissimi tag il cui valore è 0, ma nella realtà nessuno di questi è 0. Inoltre, eseguendo piu volte lo script, ho notato che i tag con valore 0 non sono sempre gli stessi. ( da qui il ciclo per rallentare l'esecuzione).

 

Mi potete aiutare a capire dove ho sbagliato?

 

Grazie a tutti

[pigroplc]

verifica le condizioni di aggiornamento dei tag, devono essere tag ad aggiornamento continuo.

Tieni conto che durante l'esecuzione dello script NON aggiorna I tags, quindi ti consiglio di levare i loop di ritardo.

[BAN003]

Quindi mi stai dicendo che il valore è 0 perche non agiornato?

I Tag sono tuti ad aggiornamento 1S.

Se metto aggiornamento continuo, non rischio di aumentare il carico di comunicazione tra HMI e PLC?

Ma l'istruzione smarttags non prende i valori dalla cache? E come fa l'HMI a mantenere visualizzati i dati?

Inoltre, sempre sul manuale c'è scritto che smarttags può prendere anche i valori direttamente dal PLC ma in questo caso aumenta il traffico tra PLC e HMI naturalmente.

Mi sapete dire come fare? 500 tag li copia in circa un secondo. non vuol dire se rallenta tutto. Li devo copiare una volta al giorno.

[pigroplc]

Aggiornamento in continuo ad 1 secondo vuol dire che ogni secondo aggiorna il tag indipendentemente dalla pagina in cui si trova il runtime, quindi NON appensantisce la comunicazione.

io gestisco ricette da 2500 tag senza problemi con aggiornamento ad un secondo e non vedo alcun appesantimento della comunicazione più circa un migliaio di tag sempre ad aggiornamento da 1 secondo (quelli che posso li aggiorno sulla pagina video che mi interessa).
In sintesi non vedo quale problema tu possa riscontrare.

[BAN003]

Pigroplc, 

Adesso i tag si aggiornano ogni secondo e quando salvo il file, molti sono a 0.

Devo quindi cambiare l'aggiornamento dei tag da 1s a continuo?

 

[bigalex]

Ciao BAN003.

Perchè fai questo ?

 

Quote

' Ciclo di ritardo inserito per rallentare l'esecuzione
	Do
		x=x+1
	Loop Until x<1000

 

La esecuzione dello script per esempio la puoi condizionare ad una variabile il cui cambiamento avviene ogni secondo così eviti di inserire (come hai fatto) una modalità che blocca l'esecuzione di altri script fintanto che lo script in esecuzione non viene terminato.

Io ti consiglierei di appoggiare i tuoi valori analogici su un array di variabili interne e di lavorare poi con i valori di questo array.

 

bigalex

[BAN003]

Risolto il problema.

Io non capivo ilcontinuo ogni secondo visto che quando seleziovano il ciclo di acquisizione mi dava 1 secondo oppure continuo.

Nelle proprietà del TAG c'è modo di acquisizione da impostare in cyclic continuous e non Cyclic in operation. Poi il tempo rimane 1 secondo.

bigalex

Il ciclo era messo perchè credevo che leggesse troppo veloce il file e non riuscisse a leggere il valore del tag. Adesso è stato eliminato.

 

Grazie pigroplc

[pigroplc]

ban003,

non ho esperienza di pannelli modernissimi, quelli più datati non erano certo brillanti nello svolgere gli script.

Io per l'acquisizione di report di produzione io aggiorno tutti i dati quindi lancio lo strobe di acquisizione dello script un secondo dopo, quindi è garantito al limone che ho i dati aggiornati.

 

 

[BAN003]

pigroplc,

Ho provato ad impostare 320 tag in aggiornamento continuo ma purtoppo noto un rallentamento nel refresh delle pagine grafiche che contengono molti oggetti, quidi dovrò abbandonare il metodo.

Per aggiornare tutti i TAG presenti su più pagine come fai? Devo tirare giù qualche report, non di produzione, ma qualcosa di molto simile ma non posso rallentare l'HMI solo per operazioni che vengono svolte una volta al mese.

Il mio era un test, ma se dovessi lavorare con un numero di variabili reali avrei molti problemi perchè potri arrivare a circa 1000 Tag e se con 300 circa mi rallenta l'aggiornamento delle paine di 2 secondi circa, con 1000 non oso pensare.

[pigroplc]

ban003, mi sembra molto strano un ritardo simile, io odio I pannelli e cerco di starne alla larga. A parte I miei gusti personali, un consiglio, anzi hai il dovere di raggruppare in un array di dati congruenti tutti I tag solamente in visualizzazione. In questo modo "peschi" 1000 valori dichiarando solamente un tag quindi effettuando una sola operazione di lettura.
Quanto ai tag in lettura/scrittura puoi fare I controlli di range a livello di PLC in modo da riportare I valori entro valori congrui. Non amo la soluzione ma piuttosto che pagare fior di baiocchi di licenza con tag ampliati faccio anche questo.

 

[BAN003]

pigroplc, sarebbe bello ma per raggruppare tutti i tag in un array devo sviluppare un bel pò di sw sul plc.

Alcuni sono set di PID, altri sono impostazioni che fa l'operatore e sono tutti archiviati in DB differenti.

Il tutto risiede in 4-5 Db, max 10 per impianti complessi, ma alcuni DB arrivano a 2000 byte divisi in TAG da BOOL a Real (Impostazioni PID).

Teoricamente potrei usare 1 array per ogni DB, ma in pratica, non so come fare visto che i dati all'interno di un DB non sono tutti dello stesso tipo.

Se usi WinCC paghi i TAG, sui pannelli hai i limiti di tag massimi e alle volte fatico a starci dentro.

Puoi consigliarmi dove recuperare qualche informazione sugli array che provo a studiarmeli meglio?

I manuali non sono molto esaurienti in merito

[BAN003]

Se per Array, intendi i DB con strutture, quelli li uso. Infatti ho ad esmpio un DB contenente le impostazioni dei PID Diviso in varie strutture e sottostrutture.

[pigroplc]

per tag array intendo una successione di variabili omogenee e consequenziali.

Una struttura può avere variabili diverse come tipologia (bool, byte, word, dword) mentre un array sono tutte di un tipo solo, dword per esempio)

nella DB dichiari ARRAY [0 .. 100] OF DWORD e hai dalla DBW0 alla DBW99 comprese.

Quanto al lavoro sul PLC, .... ebbene sì, è una gran rottura di scatole, ma fattene una ragione se vuoi ottimizzare la comunicazione.

 

NB.

Questo consiglio è valido solamente se il sovraccarico della CPU del pannello dipende ESCLUSIVAMENTE dalla comunicazione. Se fai girare script su script scordati di avere un pannello brillante.

[BAN003]

Be, attualmente ho 1 script che visualizza il nome della pagina chiamato all'apetura della pagina, uno che visualliza l'operato loggato chiamato quando cambia la variabile del nome utente e questo che viene richiamato premendo un pulsante, quindi mai costantemente.

Comunque, avendo dati differenti potrei utilizzare le UDT per alleggerire lo scambio dati. Esempio se ho 6 motori e controllo lo stato (run / Stop) il termico e gli allarmi, posso crearmi un tipo di dati definito e metterci dentro tutti questi dati e richiamandoli poi 6 ole nel programma e nel HMI.

Calcola sempre che normalmente uso un TP 700. Questo TP1500 è una eccezione

[pigroplc]

Io ti consiglio di fare questa prova per capire da che parte sta il problema:

1) crei un progetto jolly copiato da quello esistente e gli rimuovi tutti gli script

2) trasferisci il programma e vedi se il pannello reagisce meglio

 

A questo punto se il problema sono gli script faresti meglio a vedere le condizioni di esecuzione, mentre se si tratta di qualcos'altro bisogna capire cosa da fastidio ...... Io queste CPU non le conosco, ma se Simotion non ha le risorse sufficienti per la comunicazione ne soffre il PC rallentando fino a 30-40 secondi la lettura dei dati.

A tal proposito io suggerisco di eliminare tutto il codice sul PLC tranne I blocchi dati.