[Sergio Bertana]

Intanto se ti colleghi da porta Ethernet l’indirizzo di default dello SlimLine è 192.168.0.122.

Non mi dici se il tuo PC è nella stessa rete dello SlimLine e se sei riuscito a collegarti da LogicLab e a visualizzare le pagine web. La prima verifica da fare un ping del dispositivo da PC, vedi se riesci a pingare l’indirizzo IP dello SlimLine dal tuo PC prima di provare qualsiasi altra connessione TCP/IP.

[Sergio Bertana]

Il blocco funzione agisce da gateway tra una connessione Modbus su TCP/IP ed una connessione Modbus RTU. Quindi si presuppone che il dispositivo master Modbus sia esso uno SCADA, un terminale operatore od altro, apra una connessione TCP/IP verso lo SlimLine che agisce da gateway e quindi non serve un virtual COM.

Ma non capisco cosa vuoi dire quando vuoi fare dei tests, se devi interfacciarti da SlimLine con dispositivi Modbus RTU puoi utilizzare direttamente l’FB ModbusMaster, usa il cerca in alto e vedrai che trovi un sacco di informazioni. In questo topic trovi anche informazioni su programmi per il test del Modbus da PC.

[Sergio Bertana]

Quando è stata sviluppata la libreria ePowerOneLib non è stato implementato il comando di lettura allarmi dall’inverter, non era stato richiesto dal cliente per il quale è partito il progetto. Allego la tabella di allarmi che viene ritornata dal comando di lettura (Download). 

Implementare il comando nella libreria è una operazione fattibile ma deve essere richiesto al nostro ufficio commerciale che credo chiederà una partecipazione ai costi di sviluppo. Non potendo noi provare fisicamente il comando con l’inverter dovrei chiedere a te di fare i tests pratici ed eventualmente aprire una sessione di supporto remoto per il debug.

[Sergio Bertana]

Mi parli di due ingressi quindi immagino che i conteggi siano due, ma per chiarire il modo in cui sono gestiti gli I/O dal sistema ti rimando alla lettura di questo topic.

Quindi venendo al tuo problema e non conoscendo ne come hai fatto il programma ne in che task lo esegui, immagino tu stia utilizzando l’immagine di processo che di default acquisisce gli ingressi ogni 10 mS. Dovendo eseguire un conteggio, devi rilevare la variazione di stato dell’ingresso, quindi occorre che l’ingresso sia attivo per almeno 10 mS e poi disattivo per almeno 10 mS. In caso contrario il LED è acceso ma se l’ingresso si disattiva per un tempo inferiore ai 10 mS il programma non può catturane la variazione di stato.

Per acquisire ingressi velocemente, occorre utilizzare la task fast (Di default è eseguita ogni 1 mS), quindi gestendo tutta la logica ma anche l’acquisizione fisica degli ingressi nella task fast possiamo controllare variazioni di stato molto più veloci.

Ma come al solito più delle parole vale un esempio, ecco un programa che esegue un doppio conteggio su ingressi digitali, nel programma utilizzo gli ingressi del modulo CPU, ma tu puoi cambianto l’indirizzo di modulo usare gli ingressi che desideri. Da notare il modo di acquisizione DI_I_8_LL Read 0-7 input mode (Immediate), per eliminare il debouncing di 4.7 mS tipico degli ingressi digitali (Stampa programma, Programma sorgente).

[Sergio Bertana]

Lo scopo del forum non è di fornire il pesce già cotto e condito, ma di fornire una buona canna da pesca ed insegnare a pescare… Non è escluso che tempo permettendo, riesca ad ampliare il topic con un esempio di utilizzo del terminale operatore per l’impostazione dei valori di orario.

Nel frattempo ti consiglio di dare una occhiata a questo topic dove si parla dell’uso delle ricette da terminale operatore. Il programma riportato illustra come impostare i tempi di lampeggio in due lampeggianti, credo che sia una buona traccia su come utilizzare la gestione ricette (Sul nuovo EasyBuilder Pro) o l’utilizzo dei registri indice sul precedente EasyBuilder 8000 per realizzare quello che tu necessiti.

[Sergio Bertana]

Per utilizzo con VCOM si consiglia il modo TCP server. La prima prova da fare è testare il funzionamento del convertitore con un programma di emulazione terminale (Esempio Toolly) e con la seriale del convertitore in loopback (Pin 2 con pin 3) testare se vi è l’echo dei caratteri sia con connessione TCP/IP diretta che con il VCOM (Topic).

Se così funziona verifica i parametri seriali, ti consiglio di impostarli corretti anche dalla pagina web del convertitore e non solo tramite le impostazioni di Hyperterminal.

Altra possibilità è che i criteri seriali DTR-RTS non siano nello stato corretto, verifica il funzionamento del modem utilizzando solo una connessione a 3 fili (Rx, Tx, GND), provala sia con la seriale reale che con il convertitore per assicurarti che il modem non necessiti dei criteri seriali.

[Sergio Bertana]

La prima impostazione dell’indirizzo del server và fatta dal programma di configurazione del sensore Mowi. Poi quando il sensore si connette e si registra al programma iMonnit Express sarà possibile effettuare tutte le impostazioni dal programma stesso.

Tutte le modifiche effettuate alle impostazioni del sensore rimangono residenti nel programma iMonnit Express (Il relativo sensore diventa giallo nell’elenco) e sono inviate al sensore solo quando il sensore si connette al server. Se vi sono configurazioni latenti e/o il sensore non si è mai connesso al server non è possibile effettuare modifiche alle impostazioni.

[Sergio Bertana]

Sul sito Monnit Knowledge Base sono reperibili le informazioni relative alla configurazione dei sensori Mowi con il programma iMonnit Express (Link). In estrema sintesi il concetto di funzionamento dei sensori Mowi e che tramite la rete WiFi si connettono al server configurato nella loro parametrizzazione. Per connetterli al programma iMonnit Express o Enterprise occorre configurare l’indirizzo IP (Od il DNS) del PC in cui il programma è in esecuzione. In pratica dall’utility programmazione sensori Wi-Fi (MoWi) come si vede dallo screenshot, occorre nel campo Server Address al posto del server iMonnit sul cloud (u1.sensorsgateway.com) definire l’IP del proprio PC.Una volta configurato correttamente e connesso al programma iMonnit sarà possibile agire direttamente dal programma per effettuare tutte le impostazioni.

[Sergio Bertana]

I segnali EN (Enable) ed ENO (Enable out) sono dei segnali opzionali che sono automaticamente inseriti da LogicLab nelle funzioni e nei blocchi funzioni per permettere di essere inseriti in un ramo di programma ladder.

Se la funzione o il blocco funzione ha come prima variabile di input e di output due variabili BOOL (Vedi ad esempio l’FB eTOF che ha come prima variabile in ingresso IN e come prima variabile in uscita Q) è possibile evitare di inserire i segnali EN/ENO mettendola direttamente nel ramo ladder. Tutti gli esempi del manuale infatti non usano i segnali EN/ENO.

Per togliere questi due segnali occorre prima di inserire l’oggetto (Funzione o FB) nel ramo disabilitare il pulsante di LogicLab EN/ENO e poi inserire l’oggetto nel ramo ladder. Se l’oggetto è già stato inserito nel ramo con i segnali EN/ENO non è più possibile rimuoverli, occorre cancellare l’oggetto e poi inserirlo con il pulsante EN/ENO disabilitato (Screenshot).

Nota, nella programmazione ladder i segnali EN/ENO sono obbligatori se l’oggetto (Funzione o FB) non dispongono di due variabili BOOL nella prima posizione di ingresso e di uscita. Senza queste variabili non può essere collegato al ramo logico.

[Sergio Bertana]

LogicLab non permette di definire come variabile in uscita un array, ma questo non è un problema c’è un modo molto semplice di sopperire al problema. In pratica si fornisce come parametro in ingresso alla FB l’indirizzo dell’array su cui deve operare. Meglio di tante parole ecco l’esempio (Screenshot). Nello screenshot trovi anche le risposte alle domade su EN/ENO.

Come vedi dalla stampa del programma ho gestito l’indice dell’array con una operazione di somma sul valore dell’indirizzo. Attenzione, questo è un semplice esempio, occorre controllare che il valore di indice IDx non superi la dimensione dell’array per evitare di andare a sporcare memoria (Download programma).

[Sergio Bertana]

Rispolvero questo vecchio quesito a seguito di prove che ho effettuato sui diversi Gateway Modbus che distribuiamo nella gamma dei convertitori Ethernet-Seriale.

In effetti il protocollo Modbus TCP prevede un campo definito Unit Identifier che altro non è che lo Slave Address del protocollo Modbus RTU o Ascii. Quindi a rigore di logica è possibile fare passare questo campo sul protocollo RTU/Ascii per poter gestire connessioni multidrop su rete RS485 con diversi dispositivi in cascata al convertitore.

Ma i convertitori da noi distribuiti al momento attuale non prevedono di fare transitare questo campo (In pratica deve sempre essere indicato come Unit Identifier il valore 0x01). Stiamo “lavorando” con ATC per modificare il firmware del modulo ATC-3001 in modo da permetterne la definizione. Sarà mia cura informare con un post in questo topic sull’evolvere della situazione.

Vista la flessibilità (Ed il costo simile a quello del Gateway) della nostra serie di sistemi programmabili SlimLine, ho realizzato un blocco funzione ed un relativo programma che emula il funzionamento di un Gateway Modbus (Topic). Il vantaggio di un sistema programmabile è che oltre a fare da Gateway può anche essere programmato in base alle proprie esigenze aumentando la flessibilità del sistema.

[Sergio Bertana]

Aggiungo questo post per chi volesse utilizzare una connessione Ethernet in alternativa alla connessione seriale. Ho modificato il progetto precedente suddividendolo in tanti programs:

SerialCom: Questo programma gestisce la connessione seriale.
TCPCom: Questo programma gestisce la connessione Ethernet.
Logic: Questo programma esegue la logica.

Come si vede nella sezione Task (Screenshot) ho inserito nella Back i programmi TCPCom e Logic, in qiuesto modo è operativa la connessione in Ethernet. Occorre connettersi in TCP/IP sulla porta 1000 usando un client telnet (Esempio Toolly).

Se si vuole provare la connessione seriale, basterà dalla task back eliminare il programma TCPCom ed inserire il programma SerialCom (Stampa programma, Download progetto sorgente).

[Sergio Bertana]

Post a link to this topic (Is in italian, but the source code is easy to understand) that is an enhancement of this topic. The program linked in this topic added to the program linked in the new topic are a useful startup to write own communication program.

[Sergio Bertana]

Questo è un esempio di applicazione di un modulo CPU Compact che esalta la natura del modulo, cioè la possibilità di essere utilizzato come un remote I/O connesso al PC in seriale (O in Ethernet nella versione ETH) potendo gestire nel programma locale delle logiche real-time.

Partendo dal programma del topic che tu citavi ho tolgo la FB di invio stato ingressi digitali ed ho modificato la FB DOReceive per adattarla alle tue esigenze. Ora come vedi alla ricezione dei comandi seriali “S0”, “R0”, “SA” l’FB attiva le sue uscite in accordo alle specifiche richieste.

Ho poi aggiunto un piccolo programma in ladder per realizzare il resto della logica che è richiesta dalla tua applicazione (Stampa programma, Programma sorgente).

[Sergio Bertana]

La perplessità è sul protocollo, non conosco il DNP.3 ma da quanto trovato in rete leggo.

Application layer messages are broken into fragments. Maximum fragment size is determined by the size of the receiving device’s buffer. The normal range is 2048 to 4096 bytes. A message that is larger than a one fragment requires multiple fragments. Fragmenting messages is the responsibility of the application layer.

Sembrerebbe che i messaggi DNP.3 possano essere lunghi minimo 2048 bytes, ed è questa la perplessità, per trasmettere un messaggio sia via Zig-Bee che WiFi il dato và impacchettato ed il buffer per questo nell’ATC-3200 è previsto un buffer di 64 bytes, mentre nei WiFi seriali non conosco la dimensione del buffer ma posso immaginare che sia pari alla dimensione di un frame Ethernet 1500 bytes.

Quindi frames di dimensioni maggiori vengono frazionati per essere spediti e nella ricomposizione da parte del ricevente si hanno dei ritardi che potrebbero creare problemi di interpretazione se il protocollo è time dependant (Esempio Modbus RTU). Quindi non ho una risposta certa su questo punto della tua domanda, ma di certo è che la trasmissione wireless di dati è fatta fisicamente come ho descritto da qualsiasi apparecchio, quindi se è possibile trasmettere wireless il protocollo DNP.3 il convertitore WiFi-Seriale dovrebbe andare bene.

[Autore]

Post