[Sergio Bertana]

Nel TAB Sensors (Screenshot) è possibile configurare i vari sensori connessi al dispositivo, il tasto Find Sensors permette di riconoscere tutti i sensori 1-Wire connessi (Ricordo che il sensore combinato umidità e temperatura equivale a 2 sensori). E’ comunque sempre presente il Battery Monitor che indica la carica della batteria interna al dispositivo.

E’ possibile definire i parametri di funzionamento per ogni sensore e se deve inviare SMS od Email. Con un menù a tendina è possibile impostare il Template dell’SMS e dell’Email inviata. Nei TABs SMS Template ed Email Template è possibile impostare la struttura dei messaggi inviati, è possibile definire 4 diverse strutture di messaggi sia per l’SMS che per l’Email. Nella struttura del messaggio inviato è possibile definire delle macro che indicano variabili il cui valore sarà sostituito all’interno del messaggio stesso.

Esempio la macro %SRC_NAME% nel messaggio verrà sostituita con il nome del sensore definito in Name, mentre la macro %SRC_VALUE% verrà sostituita con il valore e così di seguito (Elenco macro).

[Sergio Bertana]

Si certo il prodotto scelto fà quello che tu necessiti, al dispositivo Ares12 è possibile connettere al massimo 3 sensori 1-Wire scegliendo tra la gamma di sensori disponibili. Nella richiesta tu hai citato HWg-Ares12 set mentre sul nostro sito puoi trovare a stock solo HWg-Ares12 bulk (Si tratta del solo prodotto Ares12 senza accessori come HWg-Ares12 plain ma con in aggiunta la staffa di fissaggio a parete).

[Sergio Bertana]

Per semplificare il test allego tre stringhe nei tre diversi tipi di protocollo modbus con sottofunzione diagnostica 00 Return Query Data, ed indirizzo di nodo 0xFF. Inviando la stringa con un emulatore terminale esempio Toolly ad un sistema con protocollo modbus (Esempio un modulo CPU SlimLine) è possibile testare la funzionalità della comunicazione.

Modubus Ascii: FF0800001234B3$0D$0A
Modbus RTU: $FF$08$00$00$12$34$F8$A2
Modbus over IP: $01$23$00$00$00$06$FF$08$00$00$12$34

Come si vede tutti i frames eseguono l’echo del dato 1234, il formato ascii ha un byte di LRC, il formato RTU ha 2 bytes di CRC, il formato Over IP viene preceduto da un header di 6 bytes (Screenshot esecuzione Toolly).

[Sergio Bertana]

Molte volte capita di dover eseguire un semplice test di comunicazione per verificare se il sistema risponde alle interrogazioni modbus. Il protocollo mette a disposizione un apposito comando diagnostico (Function 08 Diagnostic) che facilita il test. Il comando prevede due byte di codice sottofunzione per definire il tipo di diagnostico da eseguire. Il comando modbus diagnostico si compone di 6 bytes seguiti da Error check con il seguente significato:
 
<Slave Address><Function><Subfunction Hi><Subfunction Lo><Data Hi><Data Lo><Error Check (LRC or CRC)>

Slave Address: Indirizzo di nodo (0xFF broadcast)
Function: Codice funzione (0x08 Diagnostic)
Subfunction (Hi, Lo): Sottofunzione
Data (Hi, Lo): Dato comando

Il comando deve terminare con il campo di controllo LRC o CRC in base al tipo di modbus (Ascii o RTU), nel caso di modbus Over IP non vi è alcun campo di controllo (Gestito dal protocollo TCP/IP).

[Sergio Bertana]

The answer is yes, it’s possible to use the serial lines to manage the bar code reader. As you can see in many posts of this forums, by using the ST language you can develop programs that manage serial strings. The SlimLine ARM7 CPU module doesn’t have a USB host connector, so it’s possible to connect only serial devices.

The function Sysfopen, file open, allow to open the serial port as a data stream, use is: Fp:=Sysfopen(‘COM0’, ‘rw’);
The function Sysfgetc, get character from file, receives the character from the serial line, use is: Ch:=Sysfgetc(Fp);
The function SysVarsscanf, extracts values from string, extracts values from the received string, use is: i:=SysVarsscanf(ADR(InputString), ‘Value:%d’, UDINT_TYPE, ADR(Variable));

Many other functions and FBs allow to manipulate the received data, and to create the command frame to be sent out. All the informations about functions and FBs availablecan be reached in the SlimLine system IEC61131-3 programming manual.

Please refer to these post for more information and program examples (Post a, Post b).

[Sergio Bertana]

Se l’implementazione del protocolo modbus sul PC fosse complessa ho pensato di realizzare un semplice blocco funzione EasyProtocol che gestisce lo scambio bidirezionale verso il PC. In pratica l’FB gestisce la ricezione di una stringa binaria di 4 bytes del tipo <STX><DOHigh><DOLow><LRC> e se corretta aggiorna lo stato delle uscite e trasmette una stringa binaria del tipo <STX><DIHigh><DILow><LRC>.

STX: Start of text (16#02)
DIHigh – DILow: Stato dei 16 ingressi digitali
DOHigh – DOLow: Stato delle 16 uscite digitali
LRC: Longitudinal redundancy check (Vedi Wikipedia)

L’uso di un LRC di controllo secondo me è essenziale per garantire la correttezza dei dati ricevuti specie su connessioni seriali. Naturalmente avendo scelto di utilizzare un protocollo binario al posto di uno ascii (Così ho dimezzato il numero di bytes da inviare) pone il problema della univocità del carattere si <STX>, nel campo dati potrebbero esserci valori che posono essere uguali a 16#02.

Per ovviare a questo inconveniente ho eseguito un padding dei dati, in pratica se uno dei dati assume valore 16#02 viene inviato prima il dato 16#FF e poi il dato invertito (Diventa <FF><FD>). Usando il dato 16#FF come padding è evidente che anche alla trasmissione del dato 16#FF deve essere aggiunto il padding (Diventa <FF><00>).

Allego stampa e programma sorgente LogicLab, dove viene utilizzata per la comunicazione la porta seriale COM0, basterà modificare la definizione dello stream sulla funzione Sysfopen per poter utilizzare un’altra porta COM e/o un socket TCP/IP.

Inviando la stringa binaria 02 01 03 FA, si attiveranno le uscite Do00M00, Do01M00, Do08M00, e verrà ricevuta la stringa con lo stato degli ingressi logici così come si evince dallo screenshot del programma Toolly. Da notare la stringa 02 01 FF FD FB, che attiva le uscite Do01M00, Do08M00 (Essendo il dato output low 16#02 viene fatto il padding e diventa FF FD).

Nella finestra di ricezione sono visualizzate 4 stringhe ricevute, nella prima nessun ingresso logico è attivo, nella seconda è attivo Di00M00, nella terza attivi  Di00M00 e Di01M00, nella quarta attivi Di00M00, Di01M00 e Di08M00.

[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.

[Autore]

Post