Accesso via TCP/UDP
Accesso via TCP
Come per una telefonata, in TCP occorre innanzitutto stabilire una connessione prima di poter scambiare informazioni.
Il client stabilisce la connessione che viene ricevuta dal server. Per applicazioni per Web-IO con socket binari, il web-IO può funzionare a seconda della configurazione come server o come client. Nella maggior parte dei casi l’applicazione assume il ruolo del client e il Web-IO è il server.
Il Web-IO come server
Come server il Web-IO ha aperto una porta TCP per l’accettazione del collegamento (se non configurata diversamente, porta 49153). Il client, quindi l’applicazione, stabilisce un collegamento con l’indirizzo IP del server con questa porta. A tal scopo anche il client apre una porta TCP (a cambiamento dinamico) sulla quale può ricevere dati inviati dal server, quindi dal Web-IO.
Non appena è presente una connessione, l’applicazione può inviare comandi al Web-IO (request), ai quali il Web-IO risponde e che vengono eseguiti (reply). Con l’opportuna configurazione il Web-IO può trasmettere lo stato degli input (event message) senza che l’applicazione faccia una richiesta.
La chiusura della connessione TCP viene effettuata in genere dall’applicazione. Il Web-IO chiude il collegamento solo in caso di errore.
Nella modalità socket binario TCP il web-IO può ricevere contemporaneamente sulla porta TCP aperta esattamente un collegamento. Il tentativo di connessione di un altro client è stato rifiutato (occupato come al telefono).
Il Web-IO come client
Come client il Web-IO stabilisce il collegamento. Il collegamento con un server preconfigurato viene stabilito in seguito a una variazione di segnale sugli input.
Non appena è presente il collegamento, viene trasmesso lo stato degli input. Finché è presente il collegamento, si possono scambiare dati come nel modo di funzionamento Web-IO come server.
La disattivazione del collegamento viene avviata attraverso un Inactivity Timeout, ovvero un limite di tempo. Se non si verifica alcuna variazione sugli input per il tempo impostato, il Web-IO chiude il collegamento.
Accesso via UDP
Diversamente da una chiamata telefonica, in UDP non c’è alcun collegamento. Come per la radiofonia le informazioni vengono semplicemente inviate, quindi in UDP non ci sono client e server. Al loro posto si parla di UDP-Peers, che inviano i loro datagrammi con gli stessi diritti.
L’applicazione invia dati al Web-IO (request), ai quali il Web-IO reagisce e se necessario invia una risposta (reply). Inoltre il Web-IO in caso di specifica configurazione invia un datagramma se cambia lo stato degli input.
Configurare Web-IO
Configurare Web-IO per accesso binario
Selezionare nel menù dell’interfaccia web Vie di comunicazione >> API socket e attivare Socket binari1. La successiva configurazione dipende da che tipo di accesso socket è necessario.
Web-IO come server binario Come tipo di socket selezionare BINARY1 server TCP.
La porta locale può essere adattata all’occorrenza alla propria applicazione.
Se il Web-IO in caso di modifica agli input deve inviare automaticamente lo stato all’applicazione, inserite i rispettivi segni di spunta in Input-Trigger.
Inoltre devono essere autorizzati gli output, che vengono attivati attraverso l’applicazione.
Web-IO come client binario Come tipo di socket selezionare Client TCP BINARY1.
Come Server IP viene inserito l’indirizzo IP dell’utente della rete, su cui è attiva l’applicazione server, con cui si deve collegare il Web-IO.
La Porta Server È la porta su cui l’applicazione server riceve il collegamento. Questa porta può essere all’occorrenza adattata.
La porta locale deve rimanere in genere su AUTO affinché venga assegnata in modo dinamico. Se l’infrastruttura lo richiede, è possibile anche inserire una porta specifica.
Gli input che devono stabilire una connessione al cambiamento di stato, devono essere attivati in Input-Trigger. Una volta realizzato il collegamento, gli stati vengono inviati automaticamente all’applicazione.
Attraverso il campo Intervallo è possibile definire se e in che ciclo si debba stabilire un collegamento
Da ultimo devono essere autorizzati output, che vengono attivati attraverso l’applicazione server.
Web-IO come peer UDP binario Come tipo di socket selezionare BINARY1 UDP-Peer.
Come Remote-Peer-IP si inserisce l’indirizzo IP dell’utente della rete, al quale il Web-IO deve inviare datagrammi.
Porta locale UDP e porta remota UDP possono essere adattate all’occorrenza alla propria applicazione.
Se il Web-IO in caso di modifica agli input deve inviare automaticamente lo stato all’applicazione, inserite i rispettivi segni di spunta in Input-Trigger.
Attraverso il campo Intervallo è possibile definire se e in che ciclo si debba stabilire un collegamento.
Gli output che devono essere attivati mediante l’applicazione, devono essere autorizzati.
Strutture binarie
Creazione e struttura delle strutture binarie
Indipendentemente dal fatto che si acceda via TCP o UDP, le strutture che vengono sostituite, sono le stesse.
Le strutture di dati sono singole variabili archiviate ininterrotte nella memoria come sequenza di byte. In questa sequenza vengono inviate anche attraverso la rete. Tutte le strutture binarie per il Web-IO sono costituite da quattro valori a 16 bit a cui possono seguire altri valori da 8, 16 o 32 bit a seconda del compito della struttura.
La struttura EA-Driver
Start_1 e Start_2 Entrambe queste variabili a 16 bit hanno sempre il valore 0 e come frequenza di avvio costituiscono sempre l’inizio di ogni struttura.
StructType Attraverso il tipo di struttura si codifica ciò che deve fare il Web-IO e a cosa si riferisce la sua risposta. Strutture di un determinato tipo hanno una struttura specifica per il tipo.
StructLength Indica la lunghezza totale di una struttura in byte.
Ciò che a prima vista sembra complicato ha un grande vantaggio: determinate strutture rimangono sempre allo stesso posto all’interno della struttura e si ritrovano subito. Viene meno quindi il parsing (analisi) di catene di segni su determinati contenuti.
Esempio: interrogazione di input e output
Con il seguente esempio desideriamo mostrare come interrogare lo stato degli input e output e si forma la rispettiva risposta dal Web-IO.
Il tipo di struttura RegisterRequest La struttura RegisterRequest corrisponde alla struttura di base EA-Driver. Come StructType viene inserito 0x21 hex (decimale 33) e StructLength viene impostato a 8 (byte).
Il tipo di struttura RegisterState Come risposta il Web-IO invia una struttura del tipo RegisterState.
Anche nella struttura RegisterState la prima parte corrisponde alla struttura di base EA-Driver. Come StructType viene inserito 0x31 hex (decimale 49) e StructLength viene impostato a 0x0E hex. (decimale 14 byte).
Tuttavia seguono tre altre variabili a 16 bit. La variabile DriverID non ha più nessun significato in realtà, ma per motivi di compatibilità con modelli Web-IO precedenti è ancora un componente della struttura con il valore 2.
Le variabili InputValue e OutputValue riflettono gli stati di attivazione degli input e output. Il valore inserito corrisponde al campione bit degli input e output. La codifica è semplice. Qui un esempio per i 12 input di un Web-IO #57730:
nello stato ON ci sono gli input 0,1,5,7,10,11. Gli altri input sono nello stato OFF.
Qui dunque 1100 1010 0011
. In scrittura esadecimale questo corrisponde a 0xCA3
oppure decimale a 3235.
Nell’esempio mostrato sopra il valore dell’ OutputValue è 1, è acceso dunque solo l’output 0, ovvero ON. Tutti gli altri output presentano lo stato OFF.
Una descrizione dettagliata per la comunicazione con strutture binarie è disponibile nella breve panoramica binaria o nel manuale di programmazione sul Web-IO.