- Questo topic ha 8 risposte, 2 partecipanti ed è stato aggiornato l'ultima volta 5 anni, 5 mesi fa da
.
-
Post
-
(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?
In 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.
Il 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.
OK, 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?
La nuova versione della libreria eLLabDataExchLib_A510, è scaricabile dal sito, ecco l’estratto del manuale.
Seguendo 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.
Se 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.
Cosa 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.
Si 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.
- Devi essere connesso per rispondere a questo topic.