[Sergio Bertana]

Tutti i moduli CPU SlimLine gestiscono il protocollo Modbus ascii ed RTU su porta seriale ed over IP su connessione TCP/IP, in modo nativo. Il modo più semplice è quindi di gestire la comunicazione da PC utilizzando il protocollo modbus, con modbus è possibile leggere e scrivere registri nella memoria del modulo CPU. Il programma PLC eseguirà il semplice trasferimento degli ingressi digitali sui registri modbus letti ed il trasferimento dei registri modbus scritti sulle uscite digitali.

Ho realizzato un semplice programma DIOManage che con un programma FBD trasferisce 16 ingressi digitali nella WORD di memoria DInputs (Allocata a MX100.16) e trasferisce il valore della WORD DOutput (Allocata a MX100.18) su 16 uscite digitali. E’ possibile modificare il programma per gestire più registri di I/O, stampa e download programma.

Per accedere da modbus alla DB100 dove sono presenti i registri da gestire occorre definire indirizzo modbus 40000 seguito dall’indirizzo del registro da leggere (Nel caso di variabili WORD l’indirizzo deve essere diviso per 2). Quindi accedendo da modbus in lettura (Comando modbus 03 Read holding registers al registro 40008) sarà possibile leggere lo stato dei 16 ingressi digitali. Accedendo da modbus in scrittura (Comando modbus 10 Preset multiple registers al registro 40009) sarà possibile impostare lo stato delle 16 uscite digitali.

[Sergio Bertana]

Premesso che non ho ben compreso dove nel tuo schema applicativo vuoi collocare il terminale Weintek, ma seguendo la tua richiesta mi pare di capire che tu hai due dispositivi che agiscono come modbus master, e li vuoi fare dialogare entrambi con un terminale Weintek.

Come si evince da questo post i terminali Weintek possono operare sia in modalità master che in modalità slave. Quindi basterà configurare il terminale in modalità slave definendo due connessioni su due diverse porte seriali (Se la connessione è modbus RTU o ascii) oppure su due porte TCP/IP (Se la connessione è modbus over IP) vedi  post.

[Sergio Bertana]

If the user program uses all the COMs serial lines of the SlimLine CPU module, the modbus RTU server available on them it’s stopped, and obviously the LogicLab cannot connect to it. To solve the problem, you must delete the program loaded on the CPU module, to do this you have to use the Toolly utility.

With the CPU module switched off, connect the COM0 serial port of the module with a PC COM port using the programming cable (CBL054*000 and CBL057**00).

Execute Toolly, and activate the SlimLine CPU Catch procedure (See screenshot). Select the COM port of the PC on which is connected the SlimLine. By pressing the Catch button, on the screen will appear a message like:

Please follow these instructions:
1) Switch OFF the device
2) Switch ON the device

Switch on the CPU Module, after a short time on the Toolly screen, the message Device catched! will be displayed.

Open the Toolly terminal emulation procedure. Select the COM port of the PC on which is connected the SlimLine. Now it’s possible to login to the CPU module, press Enter on the terminal screen, the login prompt will appear (The default credentials for the Administrator are Login:Admin Password:Admin).

When are you logged in, use the PLCCommand -pc command to completely delete the user program (See screenshot). For a complete list of available commands please refer to the SlimLine CPU’s Telnet commands reference manual.

Now you can restart the SlimLine CPU module and connect to it the LogicLab program.

[Sergio Bertana]

Le operazioni per trasferire il programma sorgente sul target (Modulo CPU SlimLine) sono riportate in questo post. Ricordo che per i moduli CPU SlimLine ARM7 per trasferire il programma sorgente sul target occorre avere inserito una memoria SD Card nell’apposito Slot micro-SD.

Inoltre il codice sorgente può essere protetto da password ed in tal caso l’operazione di upload è possibile s olo se si conosce la password di protezione.

[Sergio Bertana]

Non mi indichi il prodotto a cui ti riferisci, ma credo si tratti del nuovo I/O Controller II, in effetti nel manuale utente non sono riportate in modo chiaro le connessioni degli I/O. Ho avvertito il fornitore che provvederà a modificare il manuale, nel frattempo riporto le indicazioni di connessione che si possono evincere dal manuale dell’I/O controller PL di cui riporto estratto.

Gli ingressi sono optoisolati, ed hanno il comune negativo sul pin I.GND, mentre con il positivo (Da 5 a 20 Volt) è possibile attivare l’ingresso.

Le uscite sono Open-Collector, hanno il comune su GND ed ogni uscita chiude verso il comune, quindi il carico da comandare và posto in serie tra l’uscita ed il positivo. Sulle uscite vi è un diodo di protezione, tutti i diodi fanno capo al morsetto O.COM.

[Sergio Bertana]

Da tutto quanto detto, visto le differenze di risposta tra la comunicazione seriale e quella TCP/IP è evidente che i server seriali funzionano bene solo se vi sono dei tempi morti tra i vari pacchetti dati, o se la comunicazione è di tipo master/slave esempio modbus, dove ad un pacchetto inviato si attende il pacchetto di risposta e non si invia nulla fino a quando non viene ricevuto o dopo un timeout.

Sono proprio i tempi morti a permettere di svuotare i buffers dati verso il relativo file stream compensando le differenze di velocità e permettendo di garantire una comunicazione senza perdita di dati.

[Sergio Bertana]

Per  fare un server seriale però occorre tenere presente alcune indicazioni su come gestire il flusso dati dai due file stream attivi (Porta seriale e socket TCP/IP). Dalla seriale i caratteri arrivano uno alla volta, mentre sul socket TCP/IP sono trasmessi a pacchetti, per questo non bisogna che ogni dato ricevuto dalla seriale venga inviato immediatamente al socket, ma conviene attendere che dalla seriale non arrivino più caratteri per un tempo e poi si inviano quelli ricevuti sul socket.

Naturalmente se dalla seriale si continuano a ricevere caratteri ad una certa soglia di riempimento del buffer (70 %) i dati fino a li ricevuti devono essere inviati al client per svuotare il buffer di ricezione da seriale (Attento non il buffer interno da 256 bytes ma quello esterno da te gestito di almeno 512 bytes o superiore).

Più semplice invece la ricezione da TCP/IP, il pacchetto ricevuto dovrà essere spostato in un buffer temporaneo (512 bytes o superiore) e da lì inviato verso la seriale. Se dai una occhiata a questo post è indicato come funzionano i server seriali commerciali.

[Sergio Bertana]

Quando cito i tempi del TCP/IP indico il fatto che quando SlimLine invia il pacchetto TCP verso il Client deve attendere il pacchetto di ACK di risposta dal client, i tempi dipendono dal traffico di rete e dalla velocità con la quale il client risponde con l’ACK. Su reti cablate ethernet i tempo possono andare da decine di mS anche a centinaia di mS, se poi si utilizzano reti WiFi i tempi possono dilatarsi anche di un fattore 10. Ma avendo la possibilità di inviare pacchetti dati abbastanza grandi (Massimo 512 bytes) in un unica trasmissione dovremmo riuscire a gestire comodamente il flusso dati.

Per quanto riguarda il parametro FlushTm, esso indica il tempo in mS dopo il quale i dati caricati nel socket vengono inviati. Cosa si intende, dopo avere aperto il socket con la Sysfopen i caratteri vengono trasferiti nel socket o singolarmente con una Sysfputc oppure a blocchi con una Sysfwrite, terminato il trasferimento di dati viene atteso il tempo definito in FlushTm prima di inviarli al Client. Questo permette di effettuare più volte la funzione di trasferimento per creare un pacchetto unico che sarà inviato dopo il tempo.

Quindi se FlushTm è 10 mS vuol dire che dopo avere caricato i dati nel socket, dopo 10 mS questi saranno inviati al Client. La funzione SysFOBfFlush permette invece l’invio immediato dei dati.

[Sergio Bertana]

Ti ricordo che per l’orologio in simulazione il programma EasyBuilder 8000 usa l’orologio del PC quindi non simula eventuali sincronismi con il PLC.

Per quanto riguarda il progetto come hai eseguito il download dello stesso nel terminale? Dovresti eseguirlo da  EasyBuilder 8000 dopo aver salvato e compilato e devi selezionare anche la voce firmware in Tools->Download. In pratica oltre ad eseguire il download del progetto esegui anche l’aggiormento del firmware e dei fonts nel terminale. Non vorrei che tu abbia scaricato il progetto senza aggiornare il firmware.

[Sergio Bertana]

Quando inizi il download il progetto presente nel terminale viene cancellato, quindi se il download si interrompe non vi è più alcun progetto nel terminale. Ma il terminale continua ad essere operativo e raggiungibile via TCP/IP quindi puoi ritentare l’operazione. D’altronde anche se manca la corrente dal cliente o da te durante il download sei nella stessa condizione.

Quello che è importante capire è che il terminale funziona ed è operativo anche in assenza del progetto, quindi è raggiungibile sempre per la programmazione, via FTP e via accesso remoto VNC se abilitato.

[Sergio Bertana]

In effetti lo SlimLine ha un buffer seriale di 256 caratteri in ricezione ed uno da 256 caratteri in terasmissione, i due buffers sono gestiti in interrupt, quindi nessun carattere viene perso. Tu mi parli di un baud rate di 115200 baud, che corrisponde a circa 11000 caratteri al secondo (1 carattere ogni 0.1 mS). Ipotizzando che la task di back (Unica task in cui puoi gestire le comunicazioni) venga eseguita ogni 10 mS (E’ un tempo cautelativo, sicuramente viene eseguita mediamente in molto meno) devi gestire al massimo 100 caratteri, qunindi ampiamente entro la dimensione del buffer seriale.

Naturalmente devi provvedere togliere i caratteri dal buffer seriale e a memorizzarli in un tuo buffer molto più grande per attendere i tempi di gestione lato TCP/IP che saranno molto maggiori (Vedi post).

[Sergio Bertana]

Aggiungo che tramite l’oggetto Funzioni PLC (Screenshot) è possibile sia modificare la pagina visualizzata sul terminale (E quindi passare alla pagina salvaschermo) che gestire la retroilluminazione direttamente dal PLC.

Questa soluzione permette di attivare/disattivare l’illuminazione in base a condizioni logiche del programma gestite direttamente dal PLC.

[Sergio Bertana]

Dal menù Edit -> Parametri di sistema è possibile accedere alle impostazioni generali del pannello (Screenshot). Come vedi è possibile impostare un tempo di inattività dopo il quale viene automaticamente visualizzata una pagina di salvaschermo, sia un tempo di inattività dopo il quale viene automaticamente spenta la retrolluminazione del pannello.

Lo spegnimento della retroilluminazione si disattiva non appena tocchi lo schermo del terminale, quindi basterà toccare lo schermo per riaccendere la lampada. Per uscire dalla pagina salvaschermo invece occorre inserire nella pagina stessa un oggetto che attivato indirizzi su di un’altra pagina.

[Sergio Bertana]

Ci sono molte soluzioni per sostituire una connessione RS485 via wireless, sia si tratti di un collegamento point to point sia si tratti di un collegamento multipoint. Quello che occorre conoscere sono le distanze in gioco, la velocità dei dati sulla connessione seriale e il tipo di applicazione.

Tra i nostri radiomodem puoi trovare diversi modelli con interfaccia RS485 basta scegliere il modello più adatto alla tua esigenza. Il modello ATC-3200 è un modello molto economico dalle buone prestazioni, per rispettare la normativa deve essere utilizzato con l’antenna a corredo. Operando su frequenza di 2.4GHz copre distanze che possono arrivare fino ad 1Km ma le due antenne devono essere tassativamente a vista.

Abbiamo modelli che operano su frequenze inferiori e qui puoi raggiungere distanze anche di 10/15 Km con la Serie D1 a 169MHz a cui puoi connettere una antenna Yagi direttiva (Vedi post). Le frequenze minori permettono distanze maggiori e possono operare anche in presenza di ostacoli.

Ma attenzione alla ampiezza di canale, i radiomodem che operano sulle frequenze minori hanno un baud rate radio massimo che arriva a 9600 Baud, contro i 200 KBauds dei radiomodem ZigBee. Inoltre la normativa su alcune frequenze pone vincoli sull’impiego di banda (10% della banda) e sul tipo di applicazioni.

[Sergio Bertana]

Lo scaricatore surge HWPNSURGE è stato disegnato come naturale complemento alle antenne che terminano con un connettore N maschio (Esempio l’antenna collineare da palo), alla quale si fissa direttamente sulla base per poi ripresentare nuovamente un connettore N femmina per la connessione del cavo (Esempio il CBL073*500). Nel tuo caso mi parli del cavo CBL069*500, che è un cavo da SMA-Maschio a RPSMA-M quindi immagino che tu debba connettere l’antenna (Che termina con un connettore SMA-Femmina) ad un dispositivo che ha un connettore RPSMA-Femmina. Quindi il cavo CBL073*500 potrebbe andare bene in uscita dal surge, ma non abbiamo un cavo per connettere il surge all’antenna, servirebbe un cavo da SMA-M a N Maschio. Ma attenzione a collegare antenne ad alto guadagno a radiomodem, la normativa ne prevede l’uso (In trasmissione) solo con l’antenna fornita con il prodotto.

[Autore]

Post