[Sergio Bertana]

Nella versione attuale del firmware del pannello non è possibile gestire il server VNC da programma. Però il fornitore mi ha comunicato che sono in via di rilascio di una nuova versione del firmware che prevede la gestione di 3 bit funzioni speciali.

1) Riporta lo stato della connessione di client VNC. Attivo se client connesso al pannello.
2) Se attivo inibisce logout automatico, attualmente se il client non fà operazioni viene disconnesso.
3) Abilitazione/Disabilitazione server VNC

Quindi il 3° bit fà esattemente quello di cui tu necessiti. Sarà possibile eseguire l’upgrade di tutti i pannelli con questo firmware il programma EasyBuilder. Appena sarà rilasciato il nuovo firmware lo renderemo disponibile sul sito.

[Sergio Bertana]

Da come mi spieghi sembra tutto corretto, sei sicuro di eseguire il blocco funzione ? Cioè oltre a definirlo devi anche eseguirlo mettendo una chiamata al blocco funzione. Ti allego stampa e programma sorgente con un esempio di utilizzo.

[Sergio Bertana]

Intanto vedo che hai eseguito la chiamata del FB SysSktListen che non è necessario per la la trasmissione di dati in UDP, poi non hai inserito la chiamata al FB SysIPReach che controlla la presenza dell’IP a cui vuoi inviare i dati in UDP, per il resto è tutto corretto.

Ho modificato il tuo programma correggendolo nei punti indicati e funziona perfettamente, ecco la stampa ed il programma sorgente.

Per testare la ricezione del pacchetto UDP da un PC puoi utilizzare la nosta utility Toolly, devi attivare dal menù Utilities -> Terminal e poi scegliere il tab UDP Client server abilitando il server sulla porta 120 visto che nel tuo esempio utilizzi quella.

[Sergio Bertana]

Per modificare i parametri di comunicazione della porta seriale è necessario eseguirne l’apertura con la Sysfopen poi è possibile con la SysSetSerialMode modificarne i parametri di comunicazione senza doverla chiudere e riaprire. Ogni volta che apri la porta con la Sysfopen la porta viene settata con i parametri di default 115200, e, 8, 1.

SlimLine è un PLC quindi non è possibile arrestare il programma, l’esecuzione ciclica del programma deve sempre continuare. Per eseguire attese puoi creare un programma a stati (Usa lo statement CASE) e puoi controllare il passaggio del tempo di sistema in uS tornato dalla funzione SysGetSysTime.

Ti allego la stampa ed il codice sorgente di un programma che esegue la ricerca della impostazione di un modem. Il programma invia su seriale la stringa “AT<CR>” e controlla la ricezione della stringa di risposta da parte del modem “OK<CR>”, credo sia molto simile a quello che devi fare tu.

[Sergio Bertana]

Utilizzando il blocco funzione ModbusAscii di cui allego estratto manuale, è possibile inserire nel programma un gestore di protocollo modbus personalizzato. In pratica il blocco funzione permette di definire su che area di memoria opera il comando modbus, definendone la posizione di allocazione e la dimensione in bytes.

E’ anche possibile definire oltre all’indirizzo di nodo anche l’offset di indirizzamento modbus, questo permette di personalizzare anche la gestione del protocollo. Il blocco funzione può essere connesso a qualsiasi stream di I/O, quindi sia una porta seriale che un socket TCP/IP.

Siccome il FB gestisce sia i comandi modbus di lettura che di scrittura, se si desidera che alcune variabili dell’area accessibile siano in sola lettura, occorrerà provvedere da programma utente a copiare su queste variabili il valore reale trasferendolo dalle variabili realmente utilizzate nel programma.

Ho realizzato un semplice progetto in cui è attivato il protocollo modbus over IP sulla porta 2000, l’indirizzo di nodo è 1 ed è possibile accedere ad un array di dati di 32 registri WORD. Stampa programma e download programma sorgente.

[Sergio Bertana]

Il protocollo modbus si presta perfettamente ad essere veicolato tramite radiomodems, abbiamo moltissime applicazioni realizzate dai nostri clienti. In pratica il radiomodem connesso al sistema master trasmette il pacchetto dati e tutti i radiomodems connessi ai sistemi slaves lo ricevono. Solo il sistema slave indirizzato risponderà al pacchetto, e la risposta tramite il radiomodem verrà trasmessa e ricevuta da tutti gli altri radiomodems compreso quello master. Da quanto detto si evince che una rete di radiomodems si comporta esattamente come una rete a filo in RS485. In merito al radiomodem da scegliere, ecco che entrano in gioco le distanze da coprire a la dimensione del pacchetto dati. Il radiomodem ATC-3200 opera a 2.4 Ghz e questa frequenza richiede la vista ottica tra i diversi appararati, la distanza massima indicata dal costruttore è di 500 mt. Ha un buffer dati di 60 bytes e questo nel caso di pacchetti modbus di grosse dimensioni (Il modbus può avere pacchetti massimi di 250 bytes) è un problema. Il suo vantaggio è quello di avere una elevata velocità di comunicazione radio 250 Kbps e questo riduce i tempi di comunicazione. In alternativa abbiamo i radiomodems della serie D5, qui puoi scegliere tra diverse frequenze, questi apparecchi con le opportune antenne permettono di raggiungere anche i 15 Km di distanza, inoltre possono operare all’interno di edifici. Il loro buffer dati (448 bytes) è sufficientemente capiente per tutti i frames dati modbus. Operando su frequenze radio più basse hanno una velocità di comunicazione ridotta (Massimo 9600 baud). Naturalmente se la comunicazione seriale dell’apparato è maggiore il modem provvede a bufferizzare i dati e poi a trasmetterli. Per quanto riguarda prezzi ed ulteriori informazioni, consiglio di registrarsi al sito, così potrai visualizzare il listino prezzi ed effettuare il download di tutta la documentazione.

[Sergio Bertana]

L’ATC-3200 è un radiomodem ZigBee-seriale, nell’utilizzo più semplice permette, utilizzando due apparecchi e configurandone uno come master e l’altro come slave di realizzare una connessione seriale wireless. Se il protocollo seriale lo consente (Protocollo a pacchetti ad indizizzamento esempio Modbus) è anche possibile realizzare reti con un master è più slaves.Il convertitore può operare con baud rates 1200, 2400, 9600, 14400, 19200, 38400, 57600, 115200. 8 data bits. Parità pari, dispari o nessuna.L’ATC-2000WF è un convertitore Wi-Fi seriale, in pratica permette di connettersi ad una rete Wi-Fi e tramite una connessione TCP/IP è possibile inviare e ricevere dati dalla sua porta seriale. Tramite un software di virtualizzazione porta seriale installato sul PC è possibile utilizzarlo come una normale porta seriale (Vedi post). In questo caso quindi puoi usare un solo apparato e rendi accessibile la porta seriale da qualunque PC connesso in rete Wi-Fi (Naturalmente un solo PC alla volta può connettersi al convertitore).Il convertitore può operare con baud rates 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600. 8 data bits. Nessuna parità.

[Sergio Bertana]

Il problema che poni è facilmente realizzabile, ma non utilizzerei il linguaggio Ladder per la soluzione. La normativa IEC 61131 non a caso mette a disposizione 5 linguaggi per la realizzazione del proprio progetto. Per ogni problema infatti c’è un linguaggio più indicato per trovarne la soluzione.

Il tuo è un problema di calcolo, quindi ecco che è consigliabile utilizzare il linguaggio ST (Structured text) per la soluzione. Ti ho preparato un esempio che tramite una semplice FB in ST gestisce la media. Il blocco funzione di media potrà poi essere tranquillamente utilizzato in un tuo programma ladder.

Questo programma funziona sul simulatore PC, quindi lo si può provare semplicemente senza disporre di nessun hardware particolare. Stampa programma e download programma sorgente.

[Sergio Bertana]

Il programma che hai preso come esempio esegue l’acquisizione di un canale analogico in ingresso e copia il valore acquisito su di un canale analogico in uscita. Per eseguire l’acquisizione analogica viene utilizzato il blocco funzione SysGetAnInp e per eseguire l’uscita analogica il blocco funzione SysSetAnOut. Questi blocchi funzioni sono dei blocchi funzione embedded cioè presenti nel firmware del modulo CPU quindi non disponibili sul simulatore (Ecco la ragione dell’errore in compilazione con LogicLab).

In generale il simulatore su PC può essere utilizzato con semplici programmi che fanno riferimento a gestioni logiche, per l’analogica il simulatore rende disponibili 4 variabili analogiche di ingresso e 4 variabili analogiche in uscita che sono appoggiate direttamente su variabii REAL specifiche (Vedi post).

Quindi quando il target è Plc Emulator non è visualizzata la finestra delle FB. Selezionando il target corretto SlimLine MPS046****, come versione scegli sempre l’ultima proposta, avrai la possibilità di visualizzare la finestra delle FB embedded. Così facendo il programma si compila senza errori. Naturalmente per eseguirlo sul sistema devi avere il modulo con gli I/O analogici.

Per quanto riguarda la connessione del PC alla CPU SlimLine ricordo che se ti connetti in linea seriale devi selezionare il protocollo Modbus RTU (Parametri seriali 115200, e, 8) indirizzo di nodo modbus 1.

Se ti connetti in ethernet, protocollo Modbus TCP, indirizzo IP del modulo CPU (Di default 192.168.0.122) porta 502 address nodo 1 oppure 255. Per modificare l’indirizzo IP vedi post.

Tutti i parametri che ho indicato sono quelli di default, tramite pagina web è possibile definire sulla CPU SlimLine i parametri di comunicazione seriale, l’indirizzo di nodo ecc. vedi post.

[Sergio Bertana]

Nella libreria SlimLine, esiste un apposito blocco funzione per la lettura dei dispositivi HWgroup. Tramite il FB sHWgSProtocol è possibile effettuare la lettura di dispositivi Spider connessi in rete RS485 con un modulo CPU SlimLine.

Nel programma di esempio eseguo la lettura dei 4 sensori One-Wire connessi ad uno Spider (Indirizzo 000), per aumentare il numero di Spider letti basterà aggiungere chiamate al FB sHWgSProtocol impostando l’indirizzo del sensore da acquisire. Allego stampa programma e progetto LogicLab completo.

[Sergio Bertana]

Si in effetti pensavo ad una sola telecamera, perchè da come fai giustamente notare tu l’ATC-1000 può essere configurato per connettersi ad un unico indirizzo IP server e non è possibile modificare (Se non da pagina web) l’indirizzo a cui si connette.
 
Per gestire più connessioni puoi usare in alternativa un pannello operatore, in cui puoi configurare in modalità Free protocol fino a 64 dispositivi IP diversi (Vedi post). In questo modo con apposite macro di gestione puoi, volendo, comandare le telecamere anche direttamente dal pannello e/o se il pannello è connesso ad un modulo SlimLine le potrai comandare usando variabili di memoria SlimLine lette dal pannello in Modbus TCP.

[Sergio Bertana]

Con la versione attuale del sistema operativo (SFW167D150) il modulo CPU SlimLine può accettare connessioni TCP/IP in modalità server (Vedi questi post 1, 2) ma non può aprire connessioni TCP/IP in modalità client verso indirizzi IP. E’ possibile aprire connessioni verso altri indirizzi IP solo utilizzando il protocollo UDP (Vedi post).

Per risolvere il tuo problema puoi connettere alla porta seriale del modulo CPU un convertitore Ethernet/Seriale (Esempio ATC-1000), che configurato in modalità client si connette in TCP/IP all’indirizzo IP e porta definita della telecamera (Vedi screenshot).

Nel programma sul modulo SlimLine dovrai inviare ed eventualmente ricevere le stringhe dalla porta seriale connessa al convertitore. In merito all’invio delle stringhe non ci sono limiti per la loro dimensione, devi ricordare però che affinchè parta un unico pacchetto TCP verso la telecamera, la stringa deve essere inviata senza interruzioni sulla porta seriale (Il convertitore quando non riceve più dati seriali impacchetta la stringa ricevuta e la invia al server TCP). Inoltre la stringa TCP non può superare i 1500 caratteri. Allego stampa e programma LogicLab per gestire l’invio della stringa di comando).

[Sergio Bertana]

Ho realizzato il blocco funzione TSTATCommunication che gestisce la comunicazione, il FB può gestire fino a 16 termostati in rete RS485, ognuno con il proprio indirizzo modbus, basta nella FB definire i nodi utilizzati (Il nodo FF termina la gestione), nell’esempio è gestito il solo nodo 3.

Node[0]:=16#03; (* Modbus nodes *)
Node[1]:=16#FF; (* Modbus nodes *)

Per i dati in lettura e scrittura sul termostato sono state create le strutture dati TSTATDATARD e TSTATDATAWR, è possibile allocare un array di 16 elementi uno per ogni termostato.

Il FB esegue ciclicamente la lettura di 8 registri consecutivi, che trasferisce nella struttura TSTATDATARD, poi esegue la lettura del setpoint impostato sul termostato (Anche lui trasferito nella struttura TSTATDATARD).

La scrittura del setpoint è condizionata dalla attivazione del membro SPWrite nella struttura TSTATDATAWR. in questo modo il termostato mantiene il valore di setpoint impostato localmente dall’utente, mentre quando si desidera modificarne il valore da sistema centrale basterà definire il nuovo valore nel membro SetPoint della struttura TSTATDATAWR ed attivarne la scrittura, stampa e download programma.

[Sergio Bertana]

Per la lettura dei codici dai dispositivi iButton devi fare riferimento al manuale di programmazione SlimLine ed in particolare al blocco funzione sOWRdIdentifier. Questo blocco funzione ritorna l’ID univoco letto dall’iButton come array di 8 bytes.

Per quanto riguarda la gestione del file CSV di definizione codici puoi fare riferimento ad altri post su questo forum che trattano l’argomento. Ma per venirti incontro ho realizzato un programma completo che utilizzando parti reperite da altri esempi disponibili sul forum e modificandolo opportunamente esegue:

Lettura del codice dal dispositivo iButton connesso alla porta seriale tramite convertitore.
Lettura file CSV dalla memoria Storage di SlimLine (Vedi post).
Ricerca del codice TAG iButton all’interno del file CSV.

Il file CSV l’ho strutturato semplicemente con codice TAG (16 digit esadecimali) e numero porta da aprire (Ho gestito 2 porte). Ma tu puoi modificarlo a tuo piacere aggiungendo orari di abilitazione ed ogni altra informazione sia necessaria (Vedi post). Allego la stampa ed il programma sorgente.

[Sergio Bertana]

Siccome non è possibile controllare se la chiamata ha raggiunto il destinatario, il parametro Time determina il tempo per il quale l’FB rimane in attesa dal momento che ha composto il numero prima di interrompere la chiamata in corso.

Naturalmente dalla composizione del numero all’effettivo squillo del telefono passa un tempo variabile che dipende dal gestore e può essere anche molto lungo, ho visto che mediamente con 30 Secondi di attesa si hanno alcuni squilli sul telefono del destinatario.

Il tempo tra una chiamata e l’altra è pari al tempo Time impostato più altri tempi interni di gestione della FB ModemCore, in generale i tempi interni possono essere compresi tra 15 e 30 Secondi. Quindi con un Time impostato a 30 Secondi avremo nel caso peggiore 1 chiamata al minuto.

[Autore]

Post