Scambio dati tra due (o più) PLC SlimLine
Home › Forum › Programmazione IEC 61131 (LogicLab) › Scambio dati tra due (o più) PLC SlimLine
- Questo topic ha 8 risposte, 2 partecipanti ed è stato aggiornato l'ultima volta 6 anni, 5 mesi fa da
Sergio Bertana.
-
AutorePost
-
Settembre 22, 2018 alle 6:14 am #45422
Giorgio Boero
Partecipante(1) Ho provato la comunicazione tra due PLC SlimLIne utilizzando le funzioni TCPDataExchServer e TCPDataExchClient (Come descritto in questo topic) e tutto OK funziona come previsto.
(2) Ho poi provato a scambiare dati tra i due PLC usando il protocollo Modbus TCP, sul server non ho fatto nulla in quanto il protocollo è nativo ed è gestito dal sistema operativo. Sul client ho definito due FB ModbusMaster: una in read di un certo numero di registri e l’altra in write di un altro numero di registri. Per dare spazio ad entrambe attivo l’esecuzione alternativamente ad una o all’altra sul “Done” di quella precedente ed ottengo lo stesso risultato del punto (1).
A questo punto mi domando quale metodo è meglio utilizzare per scambiare dati tra due PLC e che differenze ci sono tra i due metodi.
In entrambi i casi staccando il cavo il PLC “si accorge” della caduta di comunicazione dopo un ritardo di secondi (Active=false) e riprende poi con altrettanto ritardo. Per capire la caduta di connessione più rapidamente quindi l’unico modo è gestire in loop una variabile costantemente incrementata?
A cosa serve la SysTCPServer se il PLC ha già la funzione nativa?
Settembre 22, 2018 alle 8:16 am #45426Sergio Bertana
Amministratore del forumIn effetti ottieni lo stesso risultato con entrambi i metodi, ma ci sono differenze sostanziali tra i due.
(1) Utilizzo di TCPDataExchServer e TCPDataExchClient
Questi FB permettono lo scambio bidirezionale di un blocco di memoria. I dati contenuti in TxBuffer, sono inviati su attivazione del bit TxData e se attivo il bit AutoTxD sono inviati automaticamente quando c’è una variazione del contenuto di TxBuffer. Questo permette di inviare all’altro PLC i dati immediatamente su variazione con un tempo di ritardo minimo (Dipende dalla velocità di connessione, su rete locali pochi mS).Il parametro TxHeartbeat definisce il tempo di verifica la connessione con l’altro PLC , quindi più piccolo è il tempo più veloce è il controllo. Naturalmente per eseguire il controllo è inviato un pacchetto TCP con conseuente consumo di banda.
(2) Modbus TCP
Il PLC che esegue la ModbusMaster deve sempre interrogare lo slave per conoscere lo stato dei suoi dati anche se questi non sono cambiati. Questo porta ad un consumo di banda, inoltre vi è un tempo per l’inoltro del pacchetto Modbus di interrogazione che si somma al tempo di esecuzione della eventuale operazione di scrittura dati verso lo slave.Controllando l’uscita Fault è possibile accorgersi dell’errore di comunicazione dopo il tempo definito di Timeout.
Conclusioni
Sicuramente il punto (1) è molto più prestante in termini di velocità e consuma meno banda del punto (2) in quanto i due sistemi scambiano dati solo quando necessario (Heartbeat o variazione). Con il modbus invece si è costretti a scambiare continuamente dati anche se non necessario.Naturalmente staccando il cavo di rete le connessioni TCP vanno tutte in errore ed è necessario un tempo minimo di alcuni secondi per ripristinarle. Ma l’importante credo sia accorgersi immediatamente del problema.
Settembre 22, 2018 alle 8:40 am #45427Sergio Bertana
Amministratore del forumIl FB SysTCPServer permette di mettere in ascolto dei servers TCP direttamente da programma utente, mentre il sistema operativo ha servers TCP in ascolto sulle porte dedicate ai veri servizi gestiti direttamente. Esempio la 21 per l’FTP, la 23 per il Telnet, la 80 per l’HTTP, la 502 per il Modbus.
Settembre 26, 2018 alle 12:01 pm #45457Giorgio Boero
PartecipanteOK, capito la differenza. Grazie!
Nella risposta si parla del bit AutoTxD per attivare l’automatismo di invio su variazione dei dati. Nel vecchio esempio di comunicazione la struttura parametri TCPDEXCHNODEDEFS non contiene tale bit e per vederlo occorre importare nuovamente gli oggetti dalla nuova libreria.
Non ho però trovato la relativa documentazione aggiornata, esiste?
Settembre 26, 2018 alle 12:35 pm #45459Sergio Bertana
Amministratore del forumLa nuova versione della libreria eLLabDataExchLib_A510, è scaricabile dal sito, ecco l’estratto del manuale.
Novembre 9, 2018 alle 6:34 am #45745Giorgio Boero
PartecipanteSeguendo il consiglio ho adottato la soluzione TCPDataExchServer e TCPDataExchClient collegando inizialmente 2 moduli CPU. Si tratta ora di gestire la comunicazione tra 3 cpu: 1 master e 2 slave.
Ho configurato quindi il master con due definizioni dati (DEDefs1, DEDefs2) e due TCPclient e una definizione di server per ciascun slave. Tutto ok, funziona ma mi chiedo: è il modo corretto?
In questo modo alcune informazioni che devono scambiarsi i due slave devono necessariamente passare dal master.
Novembre 9, 2018 alle 6:46 am #45748Sergio Bertana
Amministratore del forumSe molti dei dati in scambio tra i 2 slaves servono anche al master questa è la soluzione corretta, nello scambio dati tra più sistemi solitamente si triangola sempre sul master essenzialmente per questi motivi:
Su connessioni Internet solo il master deve avere indirizzo IP pubblico
La topologia di comunicazione è lineare, 1 master e tanti slavesMa puoi istanziare un FB TCPDataExchServer anche sugli slaves e quindi farli diventare master di un’altra rete di comunicazione. Mi spiego meglio gli slaves 1 e 2 sono slave del master, lo slave 1 può essere master di un’altra rete dove lo slave 2 è slave. In questo modo i dati tra gli slaves passano direttamente tra di loro senza passare dal master.
Novembre 9, 2018 alle 9:57 am #45749Giorgio Boero
PartecipanteCosa significa “un’altra rete”?
Il plc ha una porta Ethernet sola, vuoi forse dire semplicemente che tra i due slave creo altre due instanze, una server ed una client?
Ancora una cosa: non mi è chiaro l’effetto della variabile TCPClient.SpyOn sul tempo ciclo.
Novembre 9, 2018 alle 10:13 am #45754Sergio Bertana
Amministratore del forumSi certo volevo proprio dire quello, per “rete” intendevo una nuova connessione tra vari sistemi.
Attivare lo spionaggio (SpyOn:=TRUE) obbliga il FB ad inviare i dati di spionaggio alla connessione Telnet (Solo se da Telnet si è dato il comando SpyData). Naturalmente l’invio aggiunge dei tempi sulla esecuzione del FB, i tempi saranno più o meno lunghi in base al tempo di comunicazione con il client Telnet.
Lo spionaggio è un ottimo strumento per individuare errori, naturalmente se attivo aumenta il tempo di esecuzione del FB che viene spiato.
-
AutorePost
- Devi essere connesso per rispondere a questo topic.