[Sergio Bertana]

Ho testato da me il programma che mi hai inviato, effettivamente dopo un po di tempo compare il pop-up di PLC no response.

Ma da come vedo la comunicazione è perfetta, anche spiando il dialogo seriale non noto comparsa di tempi di attesa tali da giustificare un timeout di comunicazione (Nel tuo progetto è impostato 2 Sec). In queta condizione il pop-up dovrebbe sparire da solo e comunque anche agendo sul tasto chiudi del po-up non si riesce a chiudere.

Questo mi fà pensare che la comparsa non sia dovuta ad un errore di comunicazione, ma piuttosto ad un oggetto finestra di pop-up che erroneamente visualizza la finestra 5 quella dell’errore PLC no response. Stò ancora indagando. Tu che hai fatto il programma hai sicuramente più informazioni per poter capire quale oggetto potrebbe visualizzare questo pop-up.

Sicuramente però non è un problema di comunicazione.

[Sergio Bertana]

At the moment there is no possibility to access to the SD-Card. We are currently working on a new release of operating system to give access to the SD-Card in read and write by the IEC user program.

We have not a scheduled time for this new release of operating system. A forecast could be at the beginning of may 2011. When it will be available, all the SlimLine systems can be upgraded with it, directly by the user.

[Sergio Bertana]

Tutta la famiglia di radiomodem disponibili nelle bande

VHF 169.400-169.475Mhz
UHF 433.050-434.790MHz
UHF 868-870Mhz
UHF 2,4Ghz

Sono a libero uso, i modelli a 169 Mhz possono essere utilizzati solo per telemetria, inseguimento e tracciamento di beni. Per tutti occorre comunque fare riferimento alle raccomandazioni CEPT ERC/REC 70-03. E’ possibile infatti che vi siano limitazioni sull’uso della banda, cioè non è possibile trasmettere consecutivamente ma occorre utilizzare la banda con tempi tipici del 10% (Ad esempio 1 secondo di trasmissione e 9 secondi di pausa).

Per tutti i modelli se l’installazione o l’esercizio avviene al di fuori del proprio fondo dovrà essere presentata una dichiarazione, conforme al modello di cui all’allegato 19, il modulo è scaricabile dal nostro sito nella sezione download della pagina FAQ.

[Sergio Bertana]

La finestra PLC no response compare quando vi è un errore di comunicazione con il PLC, la finestra scompare quando non vi sono più errori. Nel tuo caso sembra che vi sia un errore su di un oggetto mentre gli altri oggetti funzionano correttamente.

Le cause degli errori possono essere molteplici, un oggetto indirizza una variabile fuori range, oppure indirizza una variabile si di un nodo modbus non esistente, oppure utilizza per la gestione della variabile un comando modbus non supportato dal sistema.

Per eliminare la comparsa della finestra di errore, vi sono dei bits specifici che devono essere settati nel terminale i bits vanno da LB-11960 a LB-11967, esiste un bit per poter gestire fino a 8 tipi diversi di PLC definiti come dispositivo, estratto manuale.

Per settare il bit basterà ad esempio nella Common window, definire un oggetto Imposta bit su attivazione pagina definendo l’indirizzo del bit desiderato.

[Sergio Bertana]

Il prodotto HWPNBM5G22 NanoBeam M è il prodotto migliore per realizzare un bridge tra due punti, nel codice di acquisto è compreso sia il kit di fissaggio a palo che l’alimentatore. Quindi per realizzare il bridge basta ordinare Nr 2 pezzi del codice indicato.

L’accessorio HWPPASPOE, è da utilizzarsi se l’alimentazione del NanoBridge non è da corrente elettrica 220 Vac ma ad esempio è da batteria (Cellule fotovoltaiche), in questo caso non viene utilizzato l’alimentatore compreso nella confezione del prodotto e si usa in alternativa il passive PoE injector.

Il modello NanoBridge M5-22 è il modello più richiesto e lo trattiamo a stock, i modelli NanoBridge M2-18 e NanoBridge M5-25 sono disponibili a richiesta ed hanno un tempo di consegna di 2/3 settimane.

[Sergio Bertana]

Le configurazioni di default dei vari modelli di radiomodem della serie DL sono riportate nei rispettivi manuali utente di cui è possibile il download dalla pagina del sito. Riporto per comodità i valori di default stabiliti per i vari modelli della serie.

Modello DL169
– Canale radio 169,40625 MHz , modalità broadcasting trasparente all’utilizzatore
– Data rate UART 9600, 8, N, 1; nessun controllo di flusso, buffer 448 bytes
– Data rate radio 4800 b/s, canalizzazione 12,5 kHz
– Potenza RF 200 mW

Modello DL433
– Canale radio 434.0625 kHz , modalità broadcasting trasparente all’utilizzatore
– Data rate UART 9600, 8 , N, 1; nessun controllo di flusso, buffer 448 bytes
– Data rate radio 9600 b/s
– Potenza RF 10 mW ( 200 mW per usi consentiti)

Modello DL868
– Canale radio 869.412,5 kHz , modalità broadcasting trasparente all’utilizzatore
– Data rate UART 9600, 8, N, 1; nessun controllo di flusso, buffer 448 bytes
– Data rate radio 9600 b/s, canalizzazione 25 kHz
– Potenza RF 25 mW

Tutti i modelli se non è richiesta una configurazione particolare, possono essere immediatamente utilizzati connettendoli tramite la porta seriale RS232 o RS485 al DTE di competenza (PC, RTU, PLC o altro).

Se si desiderano funzionalità aggiuntive occorre configurare il prodotto tramite il programma DL148SW-IN (Riferirsi all’HELP del programma per le informazioni necessarie).

[Sergio Bertana]

Utilizzando il blocco funzione SysETimeToDate è possibile ricavare dal valore del tempo di sistema (Riportato nella variabile SysDateTime) variabili separate per data e ora.

Collegandosi alla variabile ora è possibile realizzare un semplice controllo sulla variazione ed attivare una flag di programma per un loop. Alllego stampa programma e files sorgenti per download.

[Sergio Bertana]

Ho letto la funzionalità del IP Watchdog Lite e dice “commuta un circuito di emergenza” mentre a me occorre un distacco di corrente ed un successivo riattacco di corrente (Quindi off e on).

La funzionalità è proprio quella richiesta, in caso di errore viene commutato un relè di uscita (Per un tempo impostabile) che interrompe l’alimentazione della apparecchiatura da controllare, naturalmente l’alimentazione della apparecchiatura dovrà avere in serie il contatto del relè dell’IP Watch dog. Ed è proprio a questo che serve il power egg, per evitare di tagliare il cavo di alimentazione della apparecchiatura da controllare per sezionarlo con il relè dell’IP Watch dog, si inserisce in serie al cavo il power egg che contiene all’interno il relè di sezionamento (Ma questa e solo una semplificazione il power egg non è indispensabile).

La mancanza di ping è temporizzabile? Ad esempio 20 minuti. Un tempo troppo breve…

Certo esistono due parametri per questa configurazione Pinging Timeout e Failed pings per timeout for reboot, vedi questo post per ulteriori informazioni.

Costo a Noi ? Considerando che ce ne occorrono più di uno ? Non vedo il listino anche se clicco sul link.

Come già riportato in altri post, il listino è consultabile solo dagli utenti registrati, basta registrarsi al sito. In alternativa è possibile richiedere una quotazione automatica.

Ma cosa mi garantisce che questo dispositivo non si blocca allo sbalzo di tensione ?

Il prodotto è stato studiato appositamente per questa aplicazione quindi ha al suo interno circuiti di controllo che ne garantiscono il riavvio anche dopo sbalzi di alimentazione.

[Sergio Bertana]

Continuo il dialogo con il cliente che mi pone ancora le seguenti domande:

1) Ho letto la funzionalità del IP Watchdog Lite e dice “commuta un circuito di emergenza” mentre a me occorre un distacco di corrente ed un successivo riattacco di corrente (Quindi off e on).

2) La mancanza di ping è temporizzabile? Ad esempio 20 minuti. Un tempo troppo breve potrebbe causare distacchi improvvisi poco motivati… magari l’apparecchio si è resettato e quindi necessita due minuti per ripartire, se il timer del IP Watchdog Lite non è settabile a 20 minuti finisce che stacca proprio mentre l’apparato sta partendo. O peggio in caso di guasto del router creare on off continui sino a quando il tecnico va sul posto non è bella coda per apparati che magari nella stessa location sono operativi. O peggio se uno degli  apparati si resetta e perde le impostazioni, l’intera location fa on-off continuo.

3) Costo a Noi ? Considerando che ce ne occorrono più di uno ? Non vedo il listino anche se clicco sul link. In totale la soluzione che costa ? Vorremmo poter ritirare una (soluzione) come possiamo procedere ?

4) Il Power Egg non ho capito che fa….. sincero sincero.

Un’altra domanda, molto importante. Ma cosa mi garantisce che questo dispositivo non si blocca allo sbalzo di tensione ? Come quasi tutti gli altri ?

[Sergio Bertana]

Il prodotto IP Watchdog Lite attivando l’opzione Outgoing ping (Vedi post), fà esattamente quello che occorre.

Basterà configuralo per inviare un ping verso l’IP del router da controllare e se non sono ricevute risposte provvede ad attivare una uscita logica per un certo tempo. Per gestire i 220V di alimentazione del router è possibile abbinare al prodotto un dispositivo Power Egg, oppure in alternativa utilizzare un comune relè che sezionerà la tensione di alimentazione del router.

Come si evince dalla documentazione l’IP watch dog ha due canali indipendenti, quindi può controllare due diverse apparecchiature.

[Sergio Bertana]

Vedo di dare risposte per i vari punti esposti.

Il finecorsa che determina l’ingresso del pezzo deve essere in grado di generare un’interrupt software in modo da memorizzare (tramite il segnale dell’encoder) l’ingresso del pezzo e la sua lunghezza, che serviranno alle lavorazioni successive.

Esiste la possibilità di abilitare GateEn nel blocco funzione SysGetEncoder, questo permette all’hardware della scheda encoder di acquisire il valore di conteggio encoder su variazione fronte dell’ingresso logico di Gate. Il valore ritornato in GQuote sarà il valore della quota encoder acquisito sul fronte del Gate senza alcun ritardo indotto dai tempi di esecuzione.

Quindi serve avere un tempo di aggiornamento delle uscite più veloce, minore di 0.5mS. Ad esempio sarebbe comodo poter impostare una task veloce a 0.1ms e poter leggere encoder/finecorsa ed l’eventuale attivazione delle uscite.

Quello che serve eseguire nella task veloce è la lettura dell’encoder, il confronto sulle quote di attivazione/disattivazione uscite logiche e la gestione delle stesse. Come si evince da questo post, i tempi maggiori sono proprio nella gestione dei moduli periferici (Lettura encoder, gestione uscite) che possiamo determinare in ~620uS. Quindi anche per non occupare tutto il tempo direi che il minimo tempo di esecuzione della task fast può essere impostato in 1 mS.

In più se supponiamo di creare una task ‘fast’ a 0.1ms, cosa succede qualora il codice all’interno di questa task impiega più di 0.1ms ad essere eseguito ?

Se il tempo di esecuzione di una task Fast o Slow, supera il tempo di esecuzione definito, l’esecuzione del programma viene arrestata, il sistema si pone in stop e nella variabile SysErCode viene riportato il codice di errore relativo.

[Sergio Bertana]

Di default in entrambi i convertitori non è impostato nessun delimitatore, ma è comunque prevista la gestione di delimitatore a tempo. Il delimitatore a tempo serve per evitare di inviare pacchetti TCP ad ogni singolo carattere ricevuto dalla porta seriale impegnando notevolmente la rete ethernet.

In questo modo i caratteri ricevuti dalla seriale sono bufferizzati nel dispositivo e quando dalla seriale non arrivano più caratteri per il tempo necessario a ricevere almeno 3 caratteri, i dati ricevuti sono trasmessi come pacchetto TCP.

[Sergio Bertana]

L’esecuzione dei calcoli e/o l’esecuzione di funzioni e blocchi funzioni che eseguono operazioni su parametri interni alla CPU richiedono tempi ridotti di esecuzione.

I tempi maggiori sono da considerarsi per l’esecuzione di funzioni e blocchi funzioni che accedono ai moduli di estensione. Essendo i moduli connessi alla CPU tramite un bus I2C l’accesso a questi moduli richiede un certo tempo. Per dare una idea riporto i tempi di esecuzione di alcuni blocchi funzione che accedono ai moduli periferici.

SysGetPhrDI, get peripheral digital input: ~300 uS
SysSetPhrDO, set peripheral digital output: ~300 uS
SysGetAnInp, get analog input: ~500 uS
SysSetAnOut, set analog output: ~450 uS
SysGetEncoder, get encoder input: ~320 uS

[Sergio Bertana]

Nelle impostazioni dei convertitori Ethernet/Seriale ATC-1000 ed ATC-2000 è possibile definire i criteri utilizzati per delimitare le stringhe (Download screenshot). Per comprendere il significato di questi delimitatori, occorre comprendere come funziona il convertitore.

I dati ricevuti dalla porta seriale non sono inviati uno per uno sulla porta ethernet, sono memorizzati in un buffer e vengono trasferiti in un pacchetto ethernet secondo le condizioni definite nel delimitatore. E’ possibile definire due diversi caratteri di delimitazione, quando uno di questi caratteri è ricevuto dalla seriale tutti i caratteri ricevuti precedentemente sono inviati in un pacchetto TCP su rete ethernet.

Esempio, si definisce il delimitatore carriage return (Chr(13), 0x0D). Se dalla seriale viene ricevuta la stringa “Hello!” la stringa rimane nel buffer, poi se si riceve la stringa ” World” la stringa rimane nel buffer, alla ricezione del carriage return <CR> l’intera stringa “Hello! World<CR>” verrà inviata come pacchetto TCP su ethernet.

Spuntando l’opzione Drop Character, il carattere delimitatore non verrà inserito nel frame TCP, quindi nel caso precedente il carriage return <CR> non viene incluso nella stringa.

Il valore definito in Silent Time o in Force Packet Transmit Time, forzano la trasmissione del pacchetto TCP se dalla seriale non sono ricevuti caratteri per il tempo impostato nel parametro, questo indipendentemente dalla ricezione del carattere delimitatore.

[Sergio Bertana]

Il modo più semplice è attivare un segnale hardware prima degli statements di cui si vuole testare il tempo di esecuzione e disattivarlo al termine. Se il segnale è disponibile in uscita è possibile rilevarne con l’oscilloscopio il tempo di durata.

Solitamente scelgo il segnale DTR (Presente sul Pin 4 del connettore RJ45 delle porte seriali COM0 e COM1), con la funzione SysSetSerialDTR è possibile attivare (+6 volt) e disattivare (-6 volt) il segnale. Collegando un oscilloscopio al pin del connettore è possibile rilevare il tempo di esecuzione degli statements.

E’ anche possibile utilizzando la funzione SysGetSysTime, memorizzare il tempo di sistema (Espresso in uS) prima degli statements di cui si vuole testare il tempo di esecuzione. Al termine della esecuzione sarà possibile calcolare il tempo necessario alla esecuzione con risoluzione in uS.

Allego la stampa di un programma di esempio di cui è possibile il download, che calcola il tempo di esecuzione della funzione SysGetRandom, la funzione viene eseguita in ca 9 uS.

[Autore]

Post