[Sergio Bertana]

Per la lettura dei badge RFID come giustamente facevi notare abbiamo sviluppato un FB per gestire i  lettori della HID con interfaccia Clock e Data (Topic). Si è utilizzato questo tipo di interfaccia e non la Wiegand in quanto la gestione del protocollo è demandata interamente al software.

Il protocollo Wiegand ha un impulso di durata 50uS ed impulsi di durata così limitata possono essere gestiti solo da hardware. I moduli di espansione I/O implementano un logica programmabile PLD che può tranquillamente gestire il protocollo Wiegand, ogni modulo dispone di 4 ingressi optoisolati veloci a 5V, quindi è possibile per ogni modulo acquisire 2 lettori Wiegand.

Al momento attuale non abbiamo sviluppato una FB apposita per il Wiegand, ma contattando il ns ufficio commerciale è possibile richiedere una offerta per lo sviluppo sia del package hardware da installare sui moduli di I/O che della FB software di gestione. Non è comunque possibile gestire il protocollo Wiegand con gli ingressi digitali presenti sui moduli CPU.

[Sergio Bertana]

Non capisco esattamente cosa intendi quando dici che gli I/O non vengono sentiti dal programma ST. Gli I/O logici possono essere gestiti indifferentemente da tutti e 5 i linguaggi della IEC61131. Mi viene il dubbio che tu abbia scritto il programma ma poi non lo abbia inserito in nessuna task di esecuzione.

Anche se è più logico un circuito di Marcia/Arresto gestirlo in linguaggio LD ecco lo screenshot di un programma di esempio in linguaggio ST. Come vedi tutti gli I/O sono gestiti da ST, l’esecuzione del programma trattandosi di sequenze logiche l’ho inserita nella task Slow (Download programma).

Attenzione, il programma postato precedentemente che gestiva una comunicazione su stream andava necessariamente eseguito nella task Back. Le varie tasks possono contenere più programmi da eseguire e l’esecuzione all’interno della task è effettuata in base all’elenco dall’alto verso il basso (Topic). Altro topic che tratta l’argomento.

[Sergio Bertana]

Devi considerare il modo in cui sono eseguiti i programmi PLC, il programma viene ciclicamente eseguito nella task dove è inserito. Il programma del post precedente ad esempio è eseguito nella task di Back, essendo un programma molto semplice il tempo di esecuzione è estremamente veloce, come vedi nello screenshot, l’esecuzione del programma (Variabile SysTBackExTm) dura 15uS, il programma viene eseguito (Variabile SysTBackLpTm) ogni 372uS.

Quindi quando tu dici che condizioni l’esecuzione all’ingresso logico del modulo CPU, tieni presente se attivi l’ingresso per 1 secondo, la funzione SysVarfprintf verrà eseguita circa 2700 volte.

Se noti nel mio esempio la variabile SysClock1000 e di tipo -]P[- cioè fronte di salita, in pratica il ramo è attivo per un solo loop di programma quando la variabile passa dallo stato inattivo ad attivo.

[Sergio Bertana]

Il prodotto ATC-3200 è sicuramente più veloce in aria, ma, utilizzando frequenze molto più elevate (2.4GHz) la normativa impone un range di comunicazione molto ridotto (500 mt). A differenza della frequenza 868Mhz la frequenza molto più elevata subisce enormemente il disturbo degli ostacoli e soprattutto si consiglia di posizionare l’antenna in posizione più elevata rispetto al terreno.

[Sergio Bertana]

La soluzione Radiant 868 o il radiomodem DL868H sono sicuramente le scelte più indicate, i due prodotti sono identici e utilizzando frequenze abbastanza basse non hanno problemi ad essere ubicati con l’antenna in prossimità del terreno quindi sotto i 120 cm del limite inferiore delle vele. Ed anche con questo posizionamento “infelice” sono sicuramente in grado di coprire le esigenze di distanza richieste. Pali metallici, le vele stesse ed altri ostacoli non sono molto influenti su queste frequenze di trasmissione. Nel settore fotovoltaico vi sono problemi dovuti alle interferenze degli inverter, dalle esperienze dei nostri clienti ti indico che dovrai porre un pò di cura nella alimentazione degli apparati, magari inserendo dei filtri sulla linea di alimentazione. Come hai visto gli apparati hanno più canali (Alla massima potenza 500mW i canali disponibili sono 10, scendendo di potenza 25mW i canali disponibili diventano 32). Quindi puoi creare linee di comunicazione indipendenti (1 master e tanti slaves) una per ogni canale. Consiglio se i master sono uno vicino all’altro di lasciare un canale libero tra un master e l’altro per evitare interferenze. Le antenne sono omnidirezionali quindi puoi disporre il master e gli slaves come meglio credi. In ultimo ti ricordo che la normativa ERC prescrive un Duty-Cycle del 10%, quindi in pratica non puoi utilizzare in continuazione il canale radio, ma considerando che hai una comunicazione Modbus hai già intrinsecamente tempi di attesa tra le domande e tra domanda e risposta. Poi considerando che sei su un tuo fondo ed in aperta campagna non dovresti dare fastidio a nessuno. Considerazione sui ritardi di comunicazione, i radiomodem utilizzano una trasmissione a pacchetto dei dati, quindi tra la creazione del pacchetto, l’invio e lo spacchettamento intercorrono dei tempi che si sommano ai tempi di comunicazione. Solitamente il master non ha problemi a tollerare questi tempi di ritardo, ma occorre comunque verificare che funzionino.

[Sergio Bertana]

Premesso che per la gestione delle comunicazioni preferisco utilizzare il linguaggio ST, in quanto più adatto e più leggibile, ma nulla vieta di utilizzare anche altri linguaggi come FBD o LD. Nel manuale infatti solitamente si riportano esempi in linguaggio ladder.

Veniamo al tuo problema ho realizzato un semplice programma LD (Stampa e Download programma), sono partito dall’esempio del manuale riferito alla FB SysSktListen ed ho aggiunto la stampa del valore della variabile SysDateTime. Come vedi però l’esecuzione della funzione SysVarfprintf viene condizionata sul fronte di attivazione della variabile SysClock1000. In questo modo si ha l’invio della stringa sul socket ogni 2 secondi.

Se esegui in modo incondizionato la SysVarfPrintf viene continuamente inviato sul socket la stringa fino al raggiungimento del numero di caratteri pari alla dimensione del buffer di socket.

Per la domanda relativa ai segnali EN/ENO ti rimando a questo topic.

[Sergio Bertana]

Ho rispolverato un vecchio progetto di esempio con un lampeggiante (Topic) ed ho aggiunto una transizione divergente. In una azione ho inserito il controllo su l’ingresso logico Di00CPU che oltre ad essere copiato sull’uscita logica Do01CPU sul fronte di attivazione setta la variabile Nome POU_RESET_SFC.

E se attivi l’ingresso Di00CPU il flusso di esecuzione SFC si resetta come deve essere (Ecco lo screenshot). Allego il programma sorgente.

[Sergio Bertana]

In tutti i dispositivi SlimLine abbiamo adottato la filosofia del basso impatto ambientale e quindi abbiamo eliminato le batterie, la riserva di carica per il funzionamento del Real Time Clock è garantita da un Supercap che si ricarica a sistema acceso e garantisce una riserva di funzionamento di ca un mese.

Per aggiornare il valore dell’orologio dal terminale ti rimando a questo topic, dove l’argomento è trattato in modo esaustivo.

Ti ricordo inoltre che se lo SlimLine è connesso ad una rete dove è presente un server NTP puoi anche utilizzare l’FB SNTPRequest per l’aggiornamento automatico dell’ora dal server (Topic).

[Sergio Bertana]

Ho contattato al riguardo la Axel che mi ha dato alcuni suggerimenti, abilitando la flag Check functions and functions blocks external variables (Screenshot) si attivano anche le flag di controllo dello stato SFC (Vedi nota tecnica).

[Sergio Bertana]

Come espresso nel post precedente, l’STE invia i dati automaticamente al portale quindi può essere utilizzato in una qualsiasi rete che preveda la connessione Internet. Non importa di che tipo sia l’indirizzo IP assegnato dal gestore può anche essere una rete sotto NAT in quanto è l’STE che si connette al portale.

Naturalmente per la consultazione dei valori di temperatura bisogna sempre fare riferimento al portale, mentre l’email di segnalazione allarme di temperatura può essere inviata sia dall’STE stesso che dal portale.

Se si desidera una archiviazione personale dei dati occorre scaricare dal portale il file XML con lo storico delle letture.

[Sergio Bertana]

Si la soluzione può essere quella che tu hai riportato, magari acquisendo con gli ingressi dello SlimLine i 4 comandi in uscita dal sistema Coster e poi gestire con  le sue uscite i comandi attuali. Così puoi completamente gestire i comandi come credi.

Mi parlavi di tecontrollo, non mi dici se sul luogo c’è Internet, se hai disponibilità di indirizzo IP statico, o pubblico o se non vi è nessuna connessione Internet. Nel forum puoi trovare molti spunti sulle possibili configurazioni (Topic).

[Sergio Bertana]

Premesso che non sono un esperto di linguaggio SFC, concordo con te che lo scenario è quello descritto, e non esiste un modo per resettare il flusso di esecuzione di un programma SFC.

Tu puoi in una azione modificare via linguaggio ST variabili utilizzate nel programma SFC ma non è possibile in nessun modo gestire il flusso di esecuzione. Quindi quando lo step ad alto livello cessa di essere attivo gli step che gestiscono le azioni a basso livello rimangono congelati allo stato in cui sono.

[Sergio Bertana]

Il problema riguarda il modo in cui è gestita l’immagine di processo degli I/O, trovi ulteriori informazioni in questo topic. In pratica gli ingressi digitali sono acquisiti dal sistema operativo nella task Slow e sono trasferiti nelle variabili UDINT SysCPUDI e SysDIxx, poi sono trasferiti nella tabella di variabili BOOL %IXxx.

Quando un programma si riferisce ad una variabile %IXxx LogicLab controlla che task stà eseguendo il programma e se è la task Slow, si riferisce alla variabile reale, se è la task Back esegue una copia della variabile reale in una variabile di appoggio creando una ulteriore immagine di processo.

L’immagine di processo chiamiamola copia, viene fatta automaticamente solo sulle variabili %IXxx, quindi la soluzione al tuo problema è quella di eseguire il programma nella task Slow.

In riferimento alla acquisizione da Modbus, sia il comando 16#02 Read input status che 16#03 Read holding registers, hanno grosso modo la stessa lunghezza in bytes nel frame di risposta quindi a livello di frame sono paragonabili. Poi certo la prima ti ritorna un array di BOOL mentre la seconda ti ritorna una o più words che poi dovrai ancora scompattare per avere i valori in variabili BOOL.

[Sergio Bertana]

Il protocollo Modbus non specifica l’endiannes dei dati nel caso di lettura di variabili a 32 bits. Cito una risposta già presente in un altro post.

Attenzione! Nella lettura di variabili a 32 bits tramite modbus occorre prestare attenzione all’endianness dei dati, il protocollo modbus infatti non specifica in che ordine devono essere ritornate le due parti a 16 bits del dato a 32 bits. Quindi è possibile che in alcuni sistema venga ritornata la parte più significativa prima della parte meno significativa o viceversa.
 
SlimLine utilizza la rappresentazione in little-endian che inizia dal byte meno significativo per finire col più significativo, ora se il valore del registro da leggere è in formato intero a 32 bits basterà dopo la lettura del registro eseguire uno SWAP tra le due words lette. Dai una occhiata alla FB WordToDouble o al manule al capitolo Swap variabile DWORD.

[Sergio Bertana]

Ho girato la segnalazione alla Axel che sviluppa il tool LogicLab. Come workaround ti posso consigliare di impostare la lingua in Inglese e questo dovrebbe permettere di scrivere FALSE (Screenshot).

[Autore]

Post