Uso del calendario e dei temporizzatori

[Antonio]

Salve ho esigenza di attaccare una pompa di irrigazione tramite PLC Elsist. In pratica mi servirebbe un on-off con il giorno della settimana e l’orario per poter avviare la pompa più volte al giorno.

Allo stesso tempo avrei la necessità anche di avere un timer per lo spegnimento dopo un certo tempo di una luce. Non riesco a trovare nessuna delle due funzioni sopra elencate.

[Sergio Bertana]

Per quanto riguarda la seconda parte della domanda, lo spegnimento di una luce dopo un certo tempo devi utilizzare il blocco funzione eTON Timer On (Estratto manuale). Puoi dare una occhiata anche a questo topic.

In merito all’orologio programmatore non esiste una funzione apposita ma è facilmente implementabile, ecco un esempio in FBD di un blocco funzione che controlla i tempi di accensione e spegnimento di un dispositivo (Screenshot). Come vedi appoggiando sull’ingresso DateTime il valore della variabile di sistema SysDateTime che contiene la data e ora espresso in Epoch viene effettuato il controllo con i tempi di On e Off definiti e se il tempo è all’intereno dei valori specificati viene attivata l’uscita.

Puoi inserire tante chiamate a questa funzione tanti quanti sono i tuoi tempi da controllare, magari abilitandola in base al giorno della settimana per gestire inserzioni settimanali.

[Sergio Bertana]

Visto lo spirito propedeutico del forum, ho aggiunto anche la stessa funzione di controllo orario scritta in linguaggio ST, questo è il listato.

IF (MOD(DateTime, 86400) >= ((TO_UDINT(HourOn)*3600)+(TO_UDINT(MinuteOn)*60)+SecondOn)) THEN
  STTimeSwitch:=TRUE; (* Function result*)
END_IF;

IF (MOD(DateTime, 86400) >= ((TO_UDINT(HourOff)*3600)+(TO_UDINT(MinuteOff)*60)+SecondOff)) THEN
  STTimeSwitch:=FALSE; (* Function result*)
END_IF;

Come  si vede il codice è molto più compatto potendo scrivere le operazioni direttamente in linea. Ho realizzato un programma che si può testare anche con il simulatore su PC (Screenshot) che mette a confronto le due FB (Stampa programma, programma sorgente).

[Giuseppe]

Buonasera,  ho tentato di utilizzare la funzione per la programmazione oraria ma effettuando le prove con il simulatore di LogicLab (2.3) sembra non funzionare o comunque in modo anomalo.

Il dato in Etime viene inviato correttamente e tramite la finestra watch visualizzo l’orario per effetture le prove ed impostare gli orari per attivare e disattivare l’uscita (con BOOL enable abilitato) ma non si attiva come dovrebbe. Sicuramente mi sfugge qualcosa… potreste darmi una mano ?

[Sergio Bertana]

Nel simulatore il valore di SysDateTime è indeterminato all’avvio del programma per questo ho inserito nel mio esempio il ramo con la FB DateToEpoch. Impostando i valori sulle variabili in ingresso alla FB ed attivando in m odo impulsivo l’ingresso Di00CPU è possibile impostare l’orario che si desidera. L’orario attuale viene visualizzato mettendo in debug la FB EpochToDate.

Ma nell’esempio per verificare l’attenzione di chi lo utilizza ho inserito un errore…

In effetti nella fretta ho definito nelle variabili globali le due uscite Do00CPU e Do01CPU entrambe mappate sulla stessa uscita %QX255.0. Non mi sono accorto dell’errore perchè ho provato la FB scritta in ST che essendo eseguita dopo attivava l’uscita. Ho provveduto a correggere l’esempio, eseguendone il download ora è corretto.

[Giuseppe]

Chiarissima la gestione del SysDateTime, avevo riscontrato gli errori sull’assegnazione dei DO e sulla FB scritta in ST, se invece si prova la FB creata in FBD funziona inserendo gli orari fino alle 18.59.59 dalle ore 19 la FB non funziona più, infatti spacchettando la funzione dagli ultimi operatori ADD prima dell’ingresso in GE e LE il dato non esce più corretto. Può essere un errore del blocchetto ADD su LogicLab ?

Per quanto mi riguarda avevo bisogno di due ON-OFF separati nella giornata e del controllo del giorno della settimana, quindi ho riscritto (sembra funzioni) la FB in ST in questo modo:

IF NOT(Enable) THEN STTimeSwitch1:=FALSE; RETURN; END_IF;

(* Controllo giorno della settimana. *)

IF NOT((WeekDay) = (N_Day)) THEN STTimeSwitch1:=FALSE; RETURN; END_IF;

(* Gestione orari ON-OFF. *)

IF NOT(STTimeSwitch1) THEN
  ELSIF(MOD(DateTime, 86400) >= (TO_UDINT(HourOn1*3600)+((MinuteOn1*60)+SecondOn1))) AND
  (MOD(DateTime, 86400) <= (TO_UDINT(HourOff1*3600)+((MinuteOff1*60)+SecondOff1))) THEN
  STTimeSwitch1:=TRUE; (* Function result*)
 
  ELSIF(MOD(DateTime, 86400) >= (TO_UDINT(HourOn2*3600)+((MinuteOn2*60)+SecondOn2))) AND
  (MOD(DateTime, 86400) <= (TO_UDINT(HourOff2*3600)+((MinuteOff2*60)+SecondOff2))) THEN
 STTimeSwitch1:=TRUE; (* Function result*)
ELSE
 STTimeSwitch1:=FALSE; (* Function result*)
END_IF;

Per il controllo del giorno della settimana, esiste una varibile di sistema da inserire direttamente all’interno della funzione in modo da inserire solamente una costante all’interno del programma e non tirarsi fuori la variabile WeekDay inserendo anche il blocchetto SysETimeTODate.

PS Ho visto in un altro post la gestione degli orari dei vostri uffici con la pagina web, è mica possibile avere l’esempio della pagina HTML.

[Sergio Bertana]

Il problema nella somma in FBD deriva dal fatto che nella operazione di MUL moltiplichiamo due UINT e quando arrivi alle 19 il valore è 19*3600=68400 che non può essere contenuto in un UINT. Per risolverlo bisogna convertire tutti i numeri in UDINT, quindi occorre mettere uno statement TO_UDINT su ogni ingresso della MUL e della ADD. Oppure utilizzare tutte variabili UDINT nel calcolo ed automaticamente il compilatore considererà anche il risultato di tipo UDINT.

Per quanto riguarda la tua funzione in linea di massima è Ok, ma vorrei fare due considerazioni, non fare il confronto IF NOT(STTimeSwitch1) THEN perchè la variabile STTimeSwitch1 è il risultato della funzione e entrando in funzione il suo valore è indeterminato. Diverso discorso sarebbe se tu facessi un blocco funzione che essendo istanziato ha sempre valori definiti.

Seconda considerazione, non farei una funzione con due confronti, ma farei un programma che esegue la funzione da un singolo confronto per tutte le volte che serve. Così puoi avere tutte le temporizzazioni che vuoi.

Ti ho realizzato un progetto di esempio con le due temporizzazioni come tu desideri, ma puoi aumentare il numero delle temporizzazioni aggiungendo rami nel programma. Nell’esempio ho accorciato il nome alle variabili per dare maggiore leggibilità, ecco la stampa del programma ed il programma sorgente.

[Sergio Bertana]

La pagina HTM a cui ti riferisci è quella che noi utilizziamo al nostro interno per schedulare le accensioni della climatizzazione (Screenshot). Il sorgente pagina non è altro che una serie di tags di vualizzazione e tags di impostazione variabili allocate nella DB100 dello SlimLine (Download file HTM).

Ho suddiviso ogni zona in un form di impostazione, agendo sul pulsante Save i dati definiti sono inviati in POST allo SlimLine che automaticamente provvede a scriverli nelle variabili relative. Come vedi dal sorgente pagina ho utilizzato tutte variabili a partire  dall’indirizzo 2048 in avanti, queste variabili infatti sono RETAIN e quindi mantengono il valore anche allo spegnimento del sistema.

[Giuseppe]

Grazie mille per l’assistenza, è tutto chiaro, il programma soddisfa in pieno le mie necessità come anche la pagina web. Avrei solo un’ultima domanda, nella pagina web è chiarissimo anche l’indirizzamento delle variabili RETAIN ma usando degli ARRAY nelle USINT come vengono poi indirizzate sia lato CPU che pagina web ed eventualmente anche HMI (tipo Weintek).

Considerando 4 zone per 2 ON-OFF giornalieri sarebbero 12(dati on-off)x4(zone)x7(giorni settimana) tot. 336 dati, si potrebbero poi in questo caso tralasciare i 56 dati dei secondi e metterli in costante visto che si tratta di irrigazione e non necessiterebbe di start-stop brevi.  Mi scuso ancora se forse la domanda può essere banale.

[Sergio Bertana]

Il più semplice è creare un array 336 variabili USINT che allocherai nella DB100.2048, ogni elemento dell’array corrisponde ad un campo da impostare a gruppi di 6 avremo (HOn, MOn, SOn, HOff, MOff, SOff). Per accedere da pagina web basterà definirne l’indirizzo 2048, 2049, 2050, … è così via.

Ma questo non si sposa bene con il pannello operatore, perchè operando in Modbus si opera su variabili a 16 bits, quindi se vuoi avere una assegnazione che vada bene anche per il pannello userei un array di UINT. Certo si sprecano 336 bytes ma tanto ve ne sono 2048 disponibili.

Se vuoi cimentarti in qualcosa di esteticamente più finito allora devi definire una struttura dati, esempio una struttura che contiene i 6 dati di una programmazione (HOn, MOn, SOn, HOff, MOff, SOff) e poi fai un array di strutture dati. Ancora meglio crei un’altra struttura dati con la programmazione giornaliera e poi un array di queste strutture. Ho cercato di farti un semplice esempio che come vedi dalla stampa gestisce due zone con due orari per zona per tutti i giorni della settimana. L’uso delle strutture semplifica enormemente l’accesso alle variabili di orario, basterà aggiungere altre 2 zone ed il programma è completo (Download programma).

[Giuseppe]

FANTASTICO!! Alla fine così programmato è davvero sublime…..eee mi manca ancora molta strada ma cmq ho compreso tutto il realizzato fino ad ora, penso che il primo Netsyst con Weintek associato siano prossimi all’acquisto.

Così facendo comunque i bytes utilizzati in totale sulla CPU saranno 672 (da 2048 a 2720) e sull’HMI saranno in sequenza da 3×40000, 3×40001, 3×40002…e così via, per quanto riguarda la parte web invece saranno assegnati in sequenza 2048, 2050, 2052…e cosi via. Corretto ? Grazie e buon lavoro.

[Sergio Bertana]

Si l’uso delle strutture dati permette di aggregare sutto un unico tipo di dati, dati di tipo eterogeneo, permettendo un ordine ed una semplificazione nella stesura del programma ed una mnemonicità di accesso ai dati. La visualizzazione automatica dei membri della struttura durante la scrittura del programma “IntelliSense” gestita da LogicLab ne rende ancora più agevole l’uso.

Corretto il conteggio del numero di bytes utilizzati, e corretto l’indirizzo definito nella pagina HTM, attenzione invece per quanto riguarda l’indirizzamento da parte del terminale HMI. L’indirizzo 3×40000 corrisponde alla UINT allocata a DB100.0, Quando si accede a registri a 16 bits occorre dividere per 2 l’indirizzo quindi DB100.0->3×40000, DB100.2->3×40001, …, DB100.2048->3×41024.

Ti segnalo questi topics che possono essere utili (1), (2), (3), inoltre visto che ti piace utilizzare le corrette tecniche di programmazione, su HMI ti consiglio di utilizzare le Tags, questo permette una facile modifica degli indirizzi nel programma HMI in caso di variazione allocazione variabili nel PLC (Topic).

[Anonimo]

BuonGiorno a tutti, ho letto con interesse tutto l’articolo e chiedevo se era possibile avere un esempio di configurazione del terminale in particolare come impostare Weekday, HOn, HOff, MOn, MOff, SOn e SOff per ogni zona.

[Sergio Bertana]

Lo scopo del forum non è di fornire il pesce già cotto e condito, ma di fornire una buona canna da pesca ed insegnare a pescare… Non è escluso che tempo permettendo, riesca ad ampliare il topic con un esempio di utilizzo del terminale operatore per l’impostazione dei valori di orario.

Nel frattempo ti consiglio di dare una occhiata a questo topic dove si parla dell’uso delle ricette da terminale operatore. Il programma riportato illustra come impostare i tempi di lampeggio in due lampeggianti, credo che sia una buona traccia su come utilizzare la gestione ricette (Sul nuovo EasyBuilder Pro) o l’utilizzo dei registri indice sul precedente EasyBuilder 8000 per realizzare quello che tu necessiti.

[Fabio Tonini]

Buongiorno, mi unisco alla discussione per una modifica che devo eseguire. Su un sistema SlimLine compact e Touchscreen 4,3″ visualizzo la data e l’ora del PLC. Dopo qualche tempo (mese) che il sistema è spento però il PLC non ha più la data e l’ora corretti. Come posso fare a settare tramite touchscreen la data e l’ora corretti ?

[Autore]

Post