[Sergio Bertana]

Il problema è che il lettore RFID da noi utilizzato gestisce due segnali logici in uscita (Clock e Data), questi due segnali sono campionati tramite gli ingressi digitali del modulo CPU. Il campionamento degli ingressi deve essere estremamente veloce (400 uS) e quindi occorre un hardware in grado di poter acquisire velocemente questi ingressi, i moduli di espansione I/O non hanno la possibilità campionare segnali logici a questa velocità.

[Sergio Bertana]

Aggiungo che in alternativa ai lettori RFID è possibile gestire dei lettori a contatto, esempio gli iButton della Maxim, il blocco funzione sOWRdIdentifier ritorna l’ID univoco letto dall’iButton come un array di 8 bytes (Vedi post). In questo caso esistono lettori molto semplici ed estremamente economici per la lettura dell’iButton (Vedi sito).
 
Questi dispositivi utilizzano un bus di connessione 1-Wire e possono essere connessi in una rete multidrop, più lettori connessi in parallelo tra di loro ad un unico adattatore 1-Wire/RS232. Puoi anche utilizzare più porte RS232 per connettere più adattatori.

[Sergio Bertana]

Come ampiamente spiegato in questo post, il blocco funzione HIDClkDtaReader permette di leggere TAG tramite il lettore RFID ProxPoint Plus. E’ sufficente connettere ai due ingressi del modulo CPU SlimLine i segnali Clock e Data del lettore per poter acquisire il codice delle TAG che vengono avvicinate al lettore RFID. Il blocco funzione ritorna un array di 8 bytes in cui viene ritornato il codice letto.

Quindi in pratica sono utilizzati i due ingressi digitali presenti sul modulo CPU SlimLine per gestire il lettore, un solo lettore si può connettere al modulo CPU. Se hai necessità di gestire più lettori RFID puoi reperire sul mercato lettori con interfaccia seriale e connetterli direttamente alla porta RS232 dello SlimLine, in questo caso puoi utilizzare le due porte RS232. Tramite LogicLab è possibile in linguaggio ST realizzare semplicemente una FB per la gestione del protocollo del lettore. Nel forum troverai parecchi esempi di programmi che gestiscono la comunicazione seriale (Vedi i post, post, post).

[Sergio Bertana]

Rispondo alla prima domanda, se ho ben capito vuoi realizzare una rete WiFi tra diverse Picostation, dove una Picostation opera da AP/Router e le altre da Station. Credo che tu voglia fare questo per poter utilizzare il server DHCP della Picostation AP/Router.

Quindi io riserverei sul server DHCP un pool di indirizzi per le Picostation utilizzate come Station in modo da poterle impostare tutte con IP statico (Preferisco avere le Station con IP statico in modo da conoscere il loro IP). In questa configurazione tutti le apparecchiature connesse sia alla rete LAN delle varie station che quelle connesse in WiFi con l’AP/Router saranno visibili tra di loro, certo se avranno l’IP coerente con la rete (Sia esso assegnato dal DHCP oppure definito staticamente).

Naturalmente utilizzando un AP/Router per raggiungere i dispositivi connessi in WiFi dal lato LAN dell’AP (Appartenendo a reti diverse) dovrai impostare regole di natting sul router.

[Sergio Bertana]

Il modo migliore per testare la connessione tra due dispositivi seriali RS232 e di interporre tra i due un cavo che permetta di “spiare” i dati in transito. In pratica occore costruire un cavo che interconnetta i due dispositivi ma che permetta nel contempo di poter ricevere su di una porta seriale i dati inviati da uno e d all’altro dispositivo.

Basterà connettere l’uscita del cavo spia su di una seriale di un PC dove con un semplice programma di emulazione terminale (Esempio Toolly) si potrà vedere i dati in transito.

Allego un articolo preso da Internet in cui si tratta l’argomento (Download), nell’articolo si riportano gli schemi realizzativi di due diversi cavi “sniffer”. Il primo a 3 connettori permette sul connettore spia di analizzare i dati in trasmissione di entrambi i dispositivi su di una sola porta seriale. Il secondo a 4 connettori, ha due connettori spia, uno per analizzare i dati trasmessi da un dispositivo ed uno per analizzare i dati trasmessi dall’altro dispositivo.

[Sergio Bertana]

Per passare un array ad una funzione od ad un blocco funzione io solitamente utilizzo la tecnica del passaggio dell’indirizzo, in questo modo mi svincolo dalle dimensioni dell’array. Nel programma di esempio (Stampa, Codice sorgente) ho realizzato una semplice funzione che estrae il valore nella posizione indicata da un array di USINT.

Naturalmente devi controllare prima di passare il valore di Index alla funzione che esso sia nella dimensione dell’array altrimenti la funzione ti ritornerà un dato indeterminato preso nella memoria.

[Sergio Bertana]

L’idea più semplice che mi viene è di aggiungere un ramo nel programma con un altro blocco funzione TimeRange definendo come tempi valori piccoli (Esempio TimeMin 100mS  e TimeMax 100 mS), questo ti permetterà di conteggiare tutti i sacchi, sarà poi il programma da PC a gestire il conteggio corretto.

L’algoritmo potrebbe essere, viene incrementato il numero di sachi totali, se nell’arco di 5 Secondi non si ha incremento di nessuno degli altri contatori, sacco perso.

La stessa cosa è fattibile da programma PLC… provare per credere…

[Sergio Bertana]

Aggiungo al post precedente che le variabili in ingresso alle funzioni e/o blocchi funzione possono anche esere dichiarate contestualmente alla esecuzione, quindi posso anche dichiarare:

FBData(Address:=0, Channel:=0, Mode:=AD_VOLT_0_10_COMMON); (* Eseguo acquisizione analogica *)

E’ anche possibile dichiarare le variabili in modo misto:

FBData.Address:=0; (* Indirizzo modulo *)
FBData(Channel:=0, Mode:=AD_VOLT_0_10_COMMON); (* Eseguo acquisizione analogica *)

[Sergio Bertana]

La programmazione in structured text (ST) è molto simile alla tecnica di programmazione utilizzata nei linguaggio C, il linguaggio prevede le condizioni (IF) (CASE) i cicli (FOR) (WHILE) e tutte le operazioni matematiche. Quasi tutti i moduli di libreria sono realizzati in ST, per dare una idea immediata del loro uso sul manuale viene solitamente riportato un esempio in ladder (LD).

L’utilizzo di una funzione o blocco funzione nel linguaggio ST è molto semplice, prendiamo ad esempio il blocco funzione SysGetAnInp, come si vede dall’estratto del manuale, esendo un blocco funzione và istanziato nel programma (Và cioè dichiarata una variabile con un proprio nome di tipo SysGetAnInp). Nell’esempio la variabile ha nome FBData. Per quanto riguarda le funzioni a differenza delle FB non vanno istanziate, quindi si utilizzano nel programma con il loro nome di libreria.

Ora nel programma possiamo indirizzare tutte le variabili in ingresso/uscita della FB definendone il nome seguito dal punto e poi dal nome della variabile:

FBData.Address:=0; (* Indirizzo modulo *)
FBData.Channel:=0; (* Indirizzo canale *)
FBData.Mode:=AD_VOLT_0_10_COMMON; (* Modo di acquisizione *)

FBData(); (* Eseguo acquisizione analogica *)

IsDone:=FBData.Done; (* Flag di conversione Ok *)
IsFault:=FBData.Fault; (* Flag di conversione Ok *)
Value:=FBData.Value; (* Valore acquisito *)

[Sergio Bertana]

L’interfaccia comandi Telnet della CPU SlimLine prevede 3 livelli di autorizzazione che di default sono definiti:

Accesso amministratore: user: Admin, password: Admin
Accesso utente: user: User, password: User
Accesso ospite: user: Guest, password: Guest

Le credenziali sono case sensitive e quindi vanno digitate esattamente come riportate. Ecco lo screenshot della connessione Telnet ad una CPU SlimLine eseguita con Toolly. Digitando ? verrà riportato l’elenco dei comandi disponibili, vi rimando al manuale riferimento comandi Telnet CPU SlimLine per un elenco dettagliato.

[Sergio Bertana]

Il tipo di comunicazione è automatico dipende da come si connette, quindi puoi utilizzarne uno in RS232 e l’altro in RS422/485 (Naturalmente se lo connetti in RS422/485 la RS232 deve esere scollegata).

Per eseguire dei tests di funzinamento, ti consiglio di connettere i due apparati in RS232 a due PC posti ad una decina di metri uno dall’altro e con il programma Toolly, inviare i dati su di un apparato e verificarne la ricezione dall’altro. Se funzione in RS232 potrai poi passare ad effettuare prove in RS485.

[Sergio Bertana]

La richiesta di conferma operazione sui tasti permette di attivare una finestra in pop-up quando si opera sul tasto (Screenshot), in questo modo si previene dalla pressione involontaria del tasto. L’operatore dovrà premere il tasto OK sul pop-up di conferma per attivare la funzione connessa al tasto.

A diffderenza di altri pop-up che visualizzano pagine predefinite e modificabili da EasyBuilder, il pop-up di conferma appartiene ai messaggi di sistema, questi messaggi hanno dimensione e forma predefinite mentre per quanto riguarda i messaggi che compaiono è possibile modificarli dal menù Oggetti -> Messaggi di sistema (Screenshot).

[Sergio Bertana]

La ditta Axel sviluppa il programma LogicLab che poi viene utilizzato dai produttori di apparati per la programmazione. Il software scaricabile dalla Axel permette la sola simulazione su PC ma non la programmazione dei prodotti.

LogicLab viene poi da noi ripreso con l’aggiunta dei drivers di comunicazione e con le informazioni per la programmazione dei nostri dispositivi oltre all’aggiunta nel pacchetto di installazione delle librerie e dei programmi di esempio. Quindi per programmare i nostri prodotti occorre necessariamente scaricare il software dal nostro sito.

In merito alle versioni noi operiamo una ricodifica per tenere conto delle variazioni inserite, ma se noti nella pagina di download o se visualizzi l’about del software, trovi anche l’indicazione della versione di riferimento così come rilasciata da Axel. La versione attuale è la 1.8.0.0 basata sulla versione 2.18.0.3 della Axel (Screenshot).

Operiamo un upgrade della versione nel caso ci siano variazioni sulle nostre librerie software o nel caso Axel abbia implementato bug fixes o migliorie di particolare importanza. A titolo informativo siamo già in fase avanzata di test di una nuova versione di LogicLab basato sulla versione 3.2.0.18 di Axel, appena saranno conclusi i test la versione sarà disponibile per il download.

[Sergio Bertana]

La procedura è corretta e sinceramente non capisco perchè debba darti quel tipo di errore in quanto l’upload esegue il trasferimento del programma dal terminale al PC e a quanto ne sò non dovrebbe fare ulteriori controlli (Ma probabilmente scopro ora che opera qualche controllo sul file).

Mi dici che hai il file XOB, non mi dici se hai provato a decompilarlo. Ti consiglio di provare a decompilarlo da Easy Builder (Screenshot), può essere che si riesca comunque a generare il file MTP di progetto e poi al limite hai qualche problema di font mancante che puoi cercare di risolvere nel progetto (Vedi post).

[Sergio Bertana]

Premised that is simpliest to use the FTP connection to operate over the files, anyway your idea could be a good solution if you need only to write the file, copying it from a PC. A CSV file can be edited by a standard text editor and this allow to add the “^” character at the begin and “$” character at the end of CSV data. Then some simple terminal emulation programs (Ie Toolly), allow to send the file over the serial line. About your questions.

SlimLine has a 256 bytes buffer the serial line incoming characters (One buffer for each serial port). So the received characters are automatically stored on it and preserved through the running loop. The program has to check if some characters are arrived and transfer them from the incoming buffer to the file. The buffer capability is enough to give time at the program to transfer the characters without the risk of loosing some of them.

There’s no locking mechanism on the file, when the program rewrites the file with the new data incoming from the serial line, all the others operations on the same file must be stopped.

I’ve developed a simple program that meet your needs (Program print, Source code).

[Autore]

Post