[Sergio Bertana]

Sia il protocollo modbus che il protocollo proprietario della Power One sono protocolli a pacchetto a singolo master, quindi non puoi connettere all’inverter contemporaneamente sia il data logger che in convertitore Modbus. Noi abbiamo sviluppato applicazioni gestendo direttamente il protocollo Power One tramite i nostri sistemi programmabili SlimLine (Vedi post). Quindi con un semplice programma, lo SlimLine può diventare una interfaccia Modbus/Power One, ma non risolveresti il problema. Ti do alcune possibili soluzioni, ma sono abbastanza complesse e se hai una sola applicazione il tempo/costi di sviluppo probabilmente non sono compatibili. Una soluzione è di utilizzare una CPU SlimLine connessa all’inverter od agli inverter in multidrop ed utilizzando un pannello operatore realizzare il datalogger eliminando il Solarlog. Il pannello operatore può visualizzare dati storici in trend grafico e salvarli su disco (E’ dotato di un file system). In questo modo la CPU SlimLine rende disponibile una porta seriale per la connessione di un telecontrollo in Modbus. Inoltre connettendo un modem al modulo è possibile inviare/ricevere SMS con allarmi e/o riepilogativi di produzione (Vedi post). Un’altra soluzione è di utilizzare una CPU SlimLine connessa all’inverter od agli inverter in multidrop e tramite un programma da realizzare ad hoc, su una delle sue porte seriali rendere disponibile lo stesso protocollo Power One cosi da poter collegare il datalogger Solarlog. Sull’altra porta seriale sarà disponibile il protocollo Modbus per il telecontrollo.

[Sergio Bertana]

Per quanto riguarda la comprensione dei valori riportati occorre fare mente locale con la posizione delle variabili nella memoria. Prendendo ad esempio una definizione come quella riportata nello screenshot, avremo le variabili:

BOOLVar, allocata ad indirizzo DB100.2048, con valore TRUE
USINTVar, allocata ad indirizzo DB100.2049, con valore 120 (16#78)
UINTVar, allocata ad indirizzo DB100.2050, con valore 12000 (16#2EE0)
UDINTVar, allocata ad indirizzo DB100.2054, con valore 120000 (16#1D4C0)
REALVar, allocata ad indirizzo DB100.2058, con valore 12,5 (16#41480000)

La prima cosa da notare è che la variabile UDINTVar è allocata ad indirizzo DB100.2054 (Vengono lasciati liberi due bytes DB100.2052 e DB100.2053) questo perchè le variabili a 16 bits vanno sempre allocate ad indirizzi divisibili per 2 e le variabili a 32 bits vanno sempre allocate ad indirizzi divisibili per 4. Il file dump è il seguente:

00000000: 01 78 E0 2E 00 00 C0 D4 | 01 00 00 00 48 41 00 00

Come si nota il primo valore è 16#01 e corrisponde alla variabile BOOLVar, poi segue il valore 16#78 che corrisponde alla variabile USINTVar, queste sono variabili ad un solo byte e quindi non vi è il problema della endianness dei dati.

Per le variabili a 16 e 32 bits occorre ricordare che SlimLine è basato su un ARM, e sfrutta una architettura Little-Endian, quindi il byte meno significativo si trova ad indirizzo più basso rispetto al byte più significativo. La variabile UINTVar viene riportata con i valori 16#E0 e 16#2E. La variabile UDINTVar viene riportata con i valori 16#C0, 16#D4, 16#01, 16#00.

Per la variabile REALVar il discorso è ancora più complesso, le variabili REAL utilizzano 4 bytes (32 bits) il valore è espresso nel formato IEEE 754-1985 (1 bit di segno, 8 bits di esponente, 23 bits di mantissa) (Vedi post). Il valore 12,5 è rappresentato in esadecimale con 16#41480000 che nel file di dump viene riportato con i valori 16#00, 16#00, 16#48, 16#41.

[Sergio Bertana]

Il blocco funzione di dump memoria esegue la copia del valore di ogni byte di memoria sul file, il valore è scritto in esadecimale usando due digit per ogni byte, vengono riportati 16 bytes per ogni riga del file. Nel file l’indirizzo parte sempre da 00000000 ma devi tenere presente che in realtà quell’indirizzo corrisponde all’offset a partire dal valore che tu hai definito in MBufferPtr. Nel tuo caso che esegui il dump di tutta l’area RETAIN a partire da DB100.2048 per 2048 bytes, avrai definito:

RMng.MBufferPtr:=ADR(%MX100.2048); (* Pointer buffer parametri *)
RMng.MBufferSize:=2048; (* Dimensione buffer parametri *)

Il file di dump ottenuto partirà da indirizzo 00000000 e all’ultima riga riporterà l’indirizzo 000007F0. Ecco un esempio di file (Sono state omesse tutte le righe tranne le prime due e l’ultima):

00000000: 01 78 E0 2E 00 00 C0 D4 | 01 00 00 00 48 41 00 00
00000010: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00
………….
000007F0: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00

Quindi l’indirizzo 00000000 corrisponde al byte di memoria %MX100.2048 ed ha valore 16#01, l’indirizzo seguente corrisponde al byte di memoria %MX100.2049 ed ha valore 16#78 e così via. L’indirizzo 000007F0 corrisponde al byte di memoria %MX100.4080 e l’ultimo indirizzo della riga corrisponde al byte di memoria %MX100.4095.

[Sergio Bertana]

Ora è tutto chiaro, quindi avendo bisogno di un solo ingresso digitale, puoi utilizzare il solo modulo CPU che dispone di 2 ingressi digitali. Per contare i sacchi quindi occorre verificare il tempo di attivazione dell’ingresso che potrebbe essere una fotocellula di lettura sacco.
 
Nel programma prevederò due valori di tempo soglia minimo e massimo per i due tipi di sacco. Se il tempo è compreso nel range del sacco piccolo incrementerò il numero di sacchi piccoli, se il tempo è compreso nel range del sacco grande incrementerò il numero di sacchi grandi. Tutti i tempi non compresi in questo range saranno scartati (Errore di lettura).
 
Ti realizzo un programma completamente testabile sul simulatore PC, attivando opportunamente l’ingresso Fotocellula vedrai gestire i counters di sacco. Nel programma ho realizzato un blocco funzione TimeRange che poi viene utilizzato in linguaggio ladder per gestire il conteggio sacchi.
 
L’FB TimeRange ha un ingresso a cui collegare l’ingresso di fotocellula e prevede la definizione di un tempo minimo e massimo di attivazione ingresso. Se l’ingresso è attivato per un tempo compreso nel range si attiva per un loop di programma l’uscita Ok che gestisce l’incremento del counter di sacco.
 
Nella task di Boot viene eseguito il programma StartUp che definisce le etichette ed i ranges delle variabili sul simulatore in modo da personalizzarlo per il tuo programma (Screenshot). Per aggiornare le etichette occorre dopo avere trasferito il programma nel simulatore agire sul tasto Reboot Plc.
 
Usandolo sul simulatore potrai vedere i valori sia nel simulatore che in debug, mentre per la tua applicazione devi usare forzatamente un modulo CPU SlimLine e per leggere i valori puoi utilizzare un pannello operatore oppure un programma su PC utilizzando il protocollo Modbus RTU oppure Modbus over IP. Stampa programma e download programma sorgente.

[Sergio Bertana]

La domanda non è chiarissima, ho cercato di interpretarla, ho realizzato un semplice progetto LogicLab che utilizza due programmi. Il controllo del tempo viene eseguito sull’ingresso 0 del modulo CPU di SlimLine, ma può essere facilmente modificato per gestire ingressi logici da qualsiasi modulo di estensione.

LogicIO: Programma in LD, esegue l’acquisizione dei due ingressi sul modulo CPU di SlimLine.
CheckTime: Programma in ST, esegue il calcolo del tempo di attivazione e gestisce i counters.

Ho definito 3 soglie di tempo e 4 counters, un counter per ogni soglia ed uno se il valore di tempo è inferiore alla 1a soglia. I tempi sono calcolati in uS, se tempo inferiore ad 1 secondo viene incrementato il Counter[0], tempo tra 1 e 2 secondi  viene incrementato il Counter[1], tempo tra 2 e 3 secondi viene incrementato il Counter[2], tempo superiore a 3 secondi viene incrementato il Counter[3].

Download stampa programma e programma sorgente.

[Sergio Bertana]

Lo standard RS422/485 riporta come indicazione di distanza massima tra due apparati 1200 metri (4000 ft), utilizzando un cavo telefonico twistato da 24 AWG con capacità tipica di di 52.5 pF/m (16 pF/ft) e 100 Ohm di impedenza. Il cavo deve essere terminato da entrambe le estremità con una resistenza da 120 Ohm.

Se  si verificano le caratteristiche del convertitore RS232-RS422/485 ATC-108N e del repeater RS422/485 ATC-109N, si riscontra come indicazione di velocità:

15.2K Bps to 1.2 Km, 38.4K Bps to 2.4 Km, 9600 Bps to 5 Km

Questo dato è riscontrabile anche su altri convertitori di altri fornitori. Essendo un dato in contrasto con quanto riportato dalle specifiche, ho chiesto al nostro fornitore delucidazioni. Il fornitore mi informa che nel mondo hanno clienti che hanno realizzato reti in RS422/485 utilizzando i loro convertitori, su distanze da 3 a 5 Km, usando velocità di comunicazione inferiori ai 9600 Bps.

Io non ho informazioni dirette di comunicazioni su distanze superiori ai 1200 metri, l’unico feedback che ho dai miei clienti è che comunicazioni su lunghe distanze sono molto sensibili ai fulmini, anche se il cavo di comunicazione è interrato le estratensioni generate da fulmini che colpiscono la zona possono distruggere i convertitore.

Quindi il consiglio che dò è quello di utilizzare un buon soppressore sulla linea RS422/485 in ingresso al convertitore. L’unico problema è che il soprressore costa molto di più del convertitore.

[Sergio Bertana]

Il modem TC65-Terminal dispone di un connettore a 24 pin per l’interfacciamento degli I/O, per la connessione occorre utilizzare un connettore Tyco Micro Mate-N-LOK Series. Sul connettore sono presenti 10 GPIO oltre a 2 analog inputs, è anche presente un bus I2C ed un bus SPI per la connessione ad un hardware esterno.

Tutti i segnali dei GPIO sono a livello logico 3 Volt, quindi sono utilizzabili solo tramite una opportuna interfaccia di adattamento del livello del segnale. Gli ingressi analogici accettano un segnale massimo di 5 Volt con risoluzione di +/- 1 mV.

Allego un estratto del manuale di riferimento hardware con le connessioni degli I/O e le loro specifiche elettriche.

[Sergio Bertana]

La funzione Pass-Through permette di poter accedere tramite connessione TCP/IP su rete ethernet ed anche Internet, al PLC connesso in seriale al pannello operatore. Attivando il Pass-Through, sul PC viene installata una porta seriale virtuale, che è fisicamente connessa alla porta seriale del pannello.

Attivando il tool di sviluppo del PLC connesso al pannello e definendo come porta seriale di connessione la porta virtuale (COMx) installata dal Pass-Through, è possibile operare sul PLC tramite la connessione ethernet al pannello come se il PLC fosse fisicamente connesso alla porta seriale del PC.

Durante questa fase naturalmente il pannello non può dialogare con il PLC per lo scambio dati, quindi viene visualizzato un pop up con l’indicazione PLC no response (Screenshot). Se la finestra viene chiusa con il tasto Close, è possibile continuare ad operare sul pannello ma tutte le operazioni che vengono effettuate non hanno alcun effetto sul PLC.

Non vi è alcun bit interno al pannello che indichi che è in corso la procedura di Pass-Through, se si vuole evitare che l’operatore operi sul pannello durante questa fase occorre predisporre un quadro di service e tramite l’accesso remoto al pannello (Client Vnc, vedi post), attivare il quadro in modo da informare l’operatore che è in corso una procedura di servizio da remoto.

Per quanto riguarda l’arresto del servizio di Pass-Through, ci sono comportamenti diversi in base ai diversi protocolli veicolati dal servizio.

Nel caso di protocollo modbus la procedura corretta è: Disattivare PLC on line sul tool di programmazione PLC e poi agire sul pulsante Stop pass-through.

Nel caso di Omron la procedura corretta è: Agire sul pulsante Stop pass-through e poi disattivare PLC On line sul tool di programmazione PLC.

[Sergio Bertana]

Mi è stato chiesto da un cliente se è possibile gestire l’invio di SMS da connessione TCP piuttosto che da connessione UDP. Naturalmente sì, basta aprire uno stream di I/O definendo come nome file il socket TC, uno statement come questo:

Fp:=Sysfopen(‘TCPSKT’, ‘rw’); (* File pointer *)

Ritorna un file pointer che opera su un server TCP, utilizzando l’FB SysSktListen sarà possibile definire la porta in cui il server si pone in ascolto oltre ai parametri di gestione del socket stesso. Nell’esempio che ho realizzato e di cui fornisco il codice sorgente (Download) viene posto in ascolto un server TCP sulla porta 1000.

Collegandosi con un client telnet (Esempio Toolly) sulla porta 1000 alla connessione viene ritornato un messaggio di Welcome e poi è possibile gestire il comando di invio SMS come indicato nel post precedente.

[Sergio Bertana]

Per quanto il tempo di conversione del modulo occorre fare riferimento al numero di convertitori A/D presenti nel modulo:

PCB126*110 e PCB126*170: Utilizzano un solo convertitore A/D
PCB126*130: Utilizza due convertitori A/D

Nel caso di tensioni e correnti il tempo di conversione di un convertitore A/D è di 16 mS per ogni canale, nel caso di acquisizione in temperatura è di 60 mS. Per calcolare il tempo di conversione totale occorre moltiplicare il tempo di conversione di un canale per il numero di canali acquisiti sullo stesso convertitore A/D.

L’acquisizione da parte del convertitore avviene ciclicamente e non dipende dalla chiamata al blocco funzione SysGetAnInp, ad ogni esecuzione del blocco funzione viene ritornato l’ultimo valore acquisisto.

[Sergio Bertana]

Il  modulo di espansione I/O analogico PCB126*** utilizza un convertitore sigma/delta a 23 bits per le acquisizioni analogiche. Dovendo adattare l’ingresso per i diversi range di acquisizione, non viene sfruttata l’intera risoluzione del convertitore e quindi si ha un deprezzamento sulla precisione, nel caso di acquisizione in 4-20mA la risoluzione reale è di 15 bits.

La risoluzione di acquisizione è di 0.6 uA (20000 uA/2^15), nel tuo caso sulla lunghezza di 2700 mm si avrà una risoluzione di 0.082 mm. Il fatto che oscilli in +/- 1mm sembra denotare un problema di disturbi. Consiglio di collegare i morsetti in modo differenziale ed usare il modo di acquisizione AD_CURR_4_20_DIFFER, in pratica il segnale in corrente và acquisito con un cavo schermato e twistato direttamente ai capi del generatore di corrente.

Per miminizzare le oscillazioni di lettura è anche possibile introdurre un filtro digitale sul valore letto (FB Average presente nella libreria PLCUtyLib).

[Sergio Bertana]

Ubiquiti non rilascia indicazioni sul grado di protezione IP dei proprii dispositivi, pur essendo indicati per uso in esterno (Il materiale plastico con cui sono costruiti è stabilizzato ai raggi UV), non vi è una indicazione precisa sulla loro tenuta alla pioggia.

A livello costruttivo sono stati presi accorgimenti per proteggere dalla pioggia, nel caso della Picostation l’antenna ha un ORing di protezione, l’uscita del cavo Ethernet è orientata verso il basso per evitare che l’acqua possa entrare, ma non vi è una vera tenuta stagna.

Il consiglio è di siliconare il punto di entrata del cavo per aumentarne la tenuta, od addirittura come fanno alcuni nostri clienti è di chiudere il prodotto in una scatola stagna (Naturalmente plastica) che lo protegge.

Attenzione alle tettoie, non usare nulla di metallico perchè andresti a chiudere la Fresnel zone di emissione del prodotto limitandone le prestazioni.

[Sergio Bertana]

La prova che ti consiglio di fare è quella di testare l’ATC-1000 senza utilizzare il programma Comunicator. Per fare questo puoi utilizzare l’utility Terminal di Toolly, imposti la modalità TCP client e definisci l’indirizzo IP dell’ATC1000 e la porta TCP impostata (Nel tuo caso, IP 192.168.1.103, porta 60023). Se connetti sul connettore RS232 un loopback (Connetti tra di loro i pins 2 e 3 del connettore), inviando da Toolly una stringa ne vedi l’eco nella finestra (Screenshot) l’IP del convertitore è 192.168.0.95 porta 2000. Questo dimostra che la connessione TCP/IP con il convertitore funziona.Puoi fare la stessa cosa da remoto (Via Internet) testando se tutte le impostazioni apertura porte e NAT sono corrette.Se così tutto funziona, il problema è da ricercarsi nelle impostazioni del software Communicator.
Attenzione! hai verificato dalla pagina web dell’ATC di avere impostato correttamente i parametri di comunicazione seriali come richiesti dall’inverter ?

[Sergio Bertana]

Da come mi dici il tuo dispositivo dispone di una connessione RS485 full duplex a 4 fili. Le comunicazioni in RS485 sono differenziali, in pratica esistono due fili per il Tx (Tx+ e Tx-) e due fili per Rx (Rx+ e Rx-). La connessione tra i dispositivi deve essere realizzata con cavo twistato a coppie. Per la connessione con l’ATC-1000 devi fare riferimento allo schema di connessione della RS422, in pratica connetti:
 
Pin 1 (T+) con il segnale Rx+ del tuo apparato
Pin 2 (T-) con il segnale Rx- del tuo apparato
Pin 3 (R+) con il segnale Tx+ del tuo apparato
Pin 4 (R-) con il segnale Tx- del tuo apparato
Pin 6 (GND) con il segnale signal return del tuo apparato

[Sergio Bertana]

Quello che hai fatto è corretto e se fai riferimento al manuale registri modbus della WAGO (Download estratto) puoi vedere la corrispondenza tra gli indirizzi modbus e gli I/O reali.

Facendo riferimento al manuale per accedere agli I/O reali devi usare un indirizzamento a bit 0x oppure 1x.

Nel range di indirizzi da 0-255 troverai lo stato di tutti gli ingressi digitali.
0…255 0x0000…0x00FF %IW0…%IW255 Physical input area (1) First 256 words of physical input data

Nel range di indirizzi da 512…767 troverai lo stato di tutte le uscite digitali.
512…767 0x0200…0x02FF %QW0…%QW255 Physical output area (1) First 256 words of physical output data

Ma attenzione alla gestione delle uscite logiche, se nel programma PLC tu attivi una uscita tramite un ramo logico, non potrai da Modbus andarla a modificare, prevale lo stato forzato dal programma.

Per gestire le uscite da protocollo Modbus, meglio è agire su variabili bit interne e poi realizzare un programma che ne copia lo stato sulla uscita reale. Non conosco l’organizzazione di memoria del Wago, ma puoi utilizzare come bit di appoggio l’area delle uscite addizionali.
28672…29436 0x7000…0x72FC %QW512…%QW1275 Physical output area (2) Additional 764 words physical output data.

[Autore]

Post