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

[Sergio Bertana]

Tutti i convertitori Wireless-Seriali fanno quello che tu hai bisogno, il semplice ATC-3200 utilizza una trasmissione Zig-Bee per inviare i dati seriali in modalità point-to-point o point-to-multipoint.

l’ATC-1000WF e l’ATC-2000WF utilizzano una connessione WiFi quindi incapsulano i dati seriali in un pacchetto TCP/IP che poi viene inviato ad un access point e/o ad un altro convertitore. l’ATC-1000WF si configura da pagina Web (Topic) mentre l’ATC-2000WF solo da comandi testuali inviati sulla porta seriale.

Sicuramente la trasmissione Zig-Bee è più veloce rispetto alla WiFi ma il WiFi ha il vantaggio di utilizzare l’infrastruttura di rete già esistente e poter trasferire dati anche su cavo ethernet e/o Internet. I convertitori ATC-1000WF e ATC-2000WF non supportano il multicast (Topic) (Trasmissione point-to-multipoint) ma solo il point-to-point.

Dopo tutte queste considerazioni veniamo alla tua domanda, i due convertitori WiFi-Seriale possono dialogare tra di loro sia con un access point intermedio sia direttamente, ma se si fanno dialogare direttamente perchè non usare l’ATC-3200 ?

[Sergio Bertana]

Per fare un pò di  luce nella gestione del modbus ti consiglio di attivare la funzione di spionaggio (Topic) sulla FB ModbusMaster, in questo modo puoi vedere da telnet i pacchetti dati inviati e ricevuti da SlimLine verso e da inverter KEB. Vedendo i pacchetti puoi capire cosa risponde l’inverter e capire eventuali errori di numero di nodo, indirizzo registro, numero di registri letti, valore impostato nel registro scritto, ecc. Dai una occhiata a questo topic che tratta un argomento simile al tuo.

Su Internet trovi molti programmi di simulazione Modbus, il sito che ti consiglio di visitare è quello della ModbusTools, dove trovi sia programmi per simulare il modbus master che il modbus slave.

[Sergio Bertana]

Non c’è una tabella con tutte le combinazioni possibili, sarebbero troppe, per il calcolo occorre sommare tutti i valori di consumo dei moduli di estensione, fare riferimento al valore indicato nel campo Alimentazione (da bus espansione) presente nelle caratteristiche del modulo di estensione.

Il consumo totale deve essere inferiore o uguale al valore indicato nel campo Alimentazione fornita al bus espansione presente nelle caratteristiche del modulo CPU.

Come esempio un modulo Compact eroga una corrente di 0.65A (650mA) mentre un modulo CPU Full eroga una corrente di 2.5A (2500mA). Ai moduli Compact inoltre non possono essere connessi più di 4 moduli di estensione.

Nel tuo caso ogni Modulo espansione 20I/O mixed signal assorbe 0.28A (280mA), 2 moduli in totale assorbono 0.56A (560mA). Quindi possono essere connessi anche ad un modulo Compact a maggior ragione come nel tuo caso ad un modulo Full.

Lo stesso ragionamento è applicabile ai moduli della serie NetsystIII.

[Sergio Bertana]

Si l’uso delle strutture dati permette di aggregare sutto un unico tipo di dati, dati di tipo eterogeneo, permettendo un ordine ed una semplificazione nella stesura del programma ed una mnemonicità di accesso ai dati. La visualizzazione automatica dei membri della struttura durante la scrittura del programma “IntelliSense” gestita da LogicLab ne rende ancora più agevole l’uso.

Corretto il conteggio del numero di bytes utilizzati, e corretto l’indirizzo definito nella pagina HTM, attenzione invece per quanto riguarda l’indirizzamento da parte del terminale HMI. L’indirizzo 3×40000 corrisponde alla UINT allocata a DB100.0, Quando si accede a registri a 16 bits occorre dividere per 2 l’indirizzo quindi DB100.0->3×40000, DB100.2->3×40001, …, DB100.2048->3×41024.

Ti segnalo questi topics che possono essere utili (1), (2), (3), inoltre visto che ti piace utilizzare le corrette tecniche di programmazione, su HMI ti consiglio di utilizzare le Tags, questo permette una facile modifica degli indirizzi nel programma HMI in caso di variazione allocazione variabili nel PLC (Topic).

[Sergio Bertana]

E’ una situazione davvero strana vediamo di fare altri tests per capire, se tu elimini dal programma l’accesso al file, dopo la formattazione provi a scrivere un file da una connessione FTP riesci a scriverlo ?

Puoi mandarmi il report del comando da telnet fsstats, subito dopo la formattazione, dopo la scrittura di un file da FTP (Sempre se riesci a scriverlo) e quando hai il problema con il tuo programma.

Eventualmente se puoi mandarmi in privato il programma che provo a fare dei tests.

[Sergio Bertana]

Il più semplice è creare un array 336 variabili USINT che allocherai nella DB100.2048, ogni elemento dell’array corrisponde ad un campo da impostare a gruppi di 6 avremo (HOn, MOn, SOn, HOff, MOff, SOff). Per accedere da pagina web basterà definirne l’indirizzo 2048, 2049, 2050, … è così via.

Ma questo non si sposa bene con il pannello operatore, perchè operando in Modbus si opera su variabili a 16 bits, quindi se vuoi avere una assegnazione che vada bene anche per il pannello userei un array di UINT. Certo si sprecano 336 bytes ma tanto ve ne sono 2048 disponibili.

Se vuoi cimentarti in qualcosa di esteticamente più finito allora devi definire una struttura dati, esempio una struttura che contiene i 6 dati di una programmazione (HOn, MOn, SOn, HOff, MOff, SOff) e poi fai un array di strutture dati. Ancora meglio crei un’altra struttura dati con la programmazione giornaliera e poi un array di queste strutture. Ho cercato di farti un semplice esempio che come vedi dalla stampa gestisce due zone con due orari per zona per tutti i giorni della settimana. L’uso delle strutture semplifica enormemente l’accesso alle variabili di orario, basterà aggiungere altre 2 zone ed il programma è completo (Download programma).

[Sergio Bertana]

Aggiungo per completare l’argomento che la comunicazione via radiomodem è comunque più lenta rispetto alla comunicazione WiFi, nel radiomodem i dati seriali sono prima ricevuti dal radiomodem, poi impacchettati e spediti via radio all’altro radiomodem che li spacchetta e li invia in seriale al dispositivo.

Nel WiFi la comunicazione è molto più veloce ed i pacchetti dati possono essere di dimensioni maggiori, inoltre la stessa connessione veicola oltre che il traffico dati anche il protocollo di programmazione e debug del PLC. Esempio con i nostri prodotti serie SlimLine abbiamo blocchi funzioni già predisposti per lo scambio dati su Ethernet e quindi in WiFi (Vedi topic, topic).

[Sergio Bertana]

Trattandosi di S7-200 non hanno nativa la connessione Ethernet quindi escludo una connessione WiFi, possiamo utilizzare una soluzione basata su linea seriale. Utilizzando le librerie Modbus sul PLC possiamo scambiare dati in seriale tra un PLC master e tanti PLC slaves.L’area non è molto grande ed essendo i carri ponte in posizione rialzata immagino che ci possa essere sempre una visibilità ottica tra l’antenna del dispositivo master e le antenne dei dispositivi slaves. Se questa condizione è assicurata possiamo utilizzare il radiomodem ATC-3200. Un radiomodem configurato come master connesso alla seriale del PLC master e un radiomodem configurato come slave connesso alla seriale di ogni PLC slave (Topic). Se l’ambiente operativo presenta ostacoli che impediscono la visibilità ottica o è un ambiente più grande, occorre utilizzare dei radiomodem a frequenze più basse rispetto all’ATC-3200. Nella gamma di radiomodem serie D5 abbiamo modelli a 868Mhz e modelli a 169Mhz, con questi modelli si possono raggiungere distanze in aria superiori ad una decina di Km.

[Sergio Bertana]

La pagina HTM a cui ti riferisci è quella che noi utilizziamo al nostro interno per schedulare le accensioni della climatizzazione (Screenshot). Il sorgente pagina non è altro che una serie di tags di vualizzazione e tags di impostazione variabili allocate nella DB100 dello SlimLine (Download file HTM).

Ho suddiviso ogni zona in un form di impostazione, agendo sul pulsante Save i dati definiti sono inviati in POST allo SlimLine che automaticamente provvede a scriverli nelle variabili relative. Come vedi dal sorgente pagina ho utilizzato tutte variabili a partire  dall’indirizzo 2048 in avanti, queste variabili infatti sono RETAIN e quindi mantengono il valore anche allo spegnimento del sistema.

[Sergio Bertana]

Il problema nella somma in FBD deriva dal fatto che nella operazione di MUL moltiplichiamo due UINT e quando arrivi alle 19 il valore è 19*3600=68400 che non può essere contenuto in un UINT. Per risolverlo bisogna convertire tutti i numeri in UDINT, quindi occorre mettere uno statement TO_UDINT su ogni ingresso della MUL e della ADD. Oppure utilizzare tutte variabili UDINT nel calcolo ed automaticamente il compilatore considererà anche il risultato di tipo UDINT.

Per quanto riguarda la tua funzione in linea di massima è Ok, ma vorrei fare due considerazioni, non fare il confronto IF NOT(STTimeSwitch1) THEN perchè la variabile STTimeSwitch1 è il risultato della funzione e entrando in funzione il suo valore è indeterminato. Diverso discorso sarebbe se tu facessi un blocco funzione che essendo istanziato ha sempre valori definiti.

Seconda considerazione, non farei una funzione con due confronti, ma farei un programma che esegue la funzione da un singolo confronto per tutte le volte che serve. Così puoi avere tutte le temporizzazioni che vuoi.

Ti ho realizzato un progetto di esempio con le due temporizzazioni come tu desideri, ma puoi aumentare il numero delle temporizzazioni aggiungendo rami nel programma. Nell’esempio ho accorciato il nome alle variabili per dare maggiore leggibilità, ecco la stampa del programma ed il programma sorgente.

[Autore]

Post