Problemi di comunicazione Modbus RS232
Home › Forum › Controllori SlimLine e Netsyst (LogicLab) › Problemi di comunicazione Modbus RS232
- Questo topic ha 5 risposte, 3 partecipanti ed è stato aggiornato l'ultima volta 9 anni, 1 mese fa da
Enrico Viviani.
-
AutorePost
-
Febbraio 22, 2016 alle 11:09 am #35956
Enrico Viviani
PartecipanteSalve, ho realizzato un sistema piuttosto complesso che implica un notevole uso della comunicazione tramite seriale tra più dispositivi. Nello specifico ogni “sottosistema” usa due CPU che dialogano tramite seriale (fin qui tutto bene), una delle due (Una compact ethernet) funge sia da “slave” per un sistema ethernet che da “master” per l’altra CPU e per un PLC Panasonic FP0R che gestisce alcuni motori passo-passo.
Proprio quest’ultima comunicazione genera il problema, ovviamente a bordo della CPU Compact c’è una sola seriale e quindi uso la seriale di un modulo mixed per dialogare con il Panasonic. Anche usando 19200 ottengo una notevole quantità di errori 10007050, ho provato sia ad alterare il valore di IFTime che quello di Timeout ma senza risultato.
Ognuno dei 4 sottosistemi presenti nella macchina mostra lo stesso tipo di problema in modo più o meno marcato quindi penso di poter escludere problemi di cablaggio. Mi viene il dubbio che la seriale del modulo mixed io non sia in grado di essere gestita per questo scopo e vorrei capire che soluzione mi potete proporre.
Febbraio 22, 2016 alle 3:19 pm #39405Sergio Bertana
Amministratore del forumAbbiamo parecchie situazioni in cui viene utilizzato il ModbusMaster su porte PCOMx.x sui moduli di espansione, queste porte sono gestite ad ogni loop di programma in background, è d’obbligo che l’esecuzione della FB ModbusMaster che la utilizza sia nella task Back. Il modulo periferico cattura i dati seriali e li bufferizza e poi li passa al modulo CPU ad ogni loop di programma, essendo il protocollo Modbus basato sui tempi di pausa della comunicazione tutti questi passaggi creano notevoli perturbazioni sui tempi.
Ma il tuo vantaggio è che gestisci il protocollo lato master, quindi puoi avere il completo governo dei tempi, quindi il consiglio è di impostare il valore di IFTime ad almeno 2 volte il tempo di esecuzione della task Back, o per stare tranquillo puoi anche impostarlo a valori grandi (Esempio 5000 o più). L’aumento del IFTime garantisce che il FB ModbusMaster prende in considerazione il frame ricevuto solo dopo l’assenza di ricezione caratteri per il tempo impostato.
Febbraio 22, 2016 alle 3:36 pm #39406Enrico Viviani
PartecipantePurtroppo succede che il programma gira sulla back e sono arrivato ad un IFTime di 15000 con velocita 19200 senza ottenere esiti positivi, altri suggerimenti ?
Potrebbe essere il caso che il buffer della seriale non sia adeguato o che, siccome gestisco contemporaneamente anche le uscite analogiche la CPU del modulo “non ce la faccia ?”.
Un ulteriore nota a rafforzamento di quello che ho sperimentato, su uno dei moduli sto usando la COM in dotazione alla CPU con lo stesso programma e, pur con le impostazioni “consigliate” da manuale, non da mai come risultato l’errore citato.
Febbraio 22, 2016 alle 4:02 pm #39407Sergio Bertana
Amministratore del forumDa quello che dici si è svelato il problema… Consiglio comunque l’utilizzo dello spionaggio per capire meglio cosa capita… a causa dei ritardi di loop non arrivano i caratteri in tempo sufficentemente breve al modulo di espansione per garantire un flusso di trasmissione costante. In pratica il frame modbus viene trasmesso con delle interruzioni, ed il PLC Panasonic interpreta queste interruzioni come fine frame. Andando ad interpretare il frame su di un fine frame errato non capisce il comando e quindi non risponde.
Mi sembra di capire che utilizzi la COM standard del modulo CPU per dialogare con un’altro modulo SlimLine, se è così basta scambiare le porte, usi la COM standard per dialogare con il Panasonic e quella del modulo di espansione per dialogare con lo SlimLine. Nello SlimLine slave dovrai inserire il FB modbus slave ed aumentare il tempo di IFTime per compensare i buchi di trasmissione.
Altra soluzione, imposti un valore in DTROnTime sulla PCOMx.x in questo modo prima di trasmettere i caratteri sulla seriale il modulo attende il tempo definito. Ma nel frattempo si dà modo al modulo CPU di trasferire tutti i caratteri da trasmettere e così quando inizia la trasmissione non ci saranno più buchi.
Non è che il Panasonic supporta il modbus Ascii, il modbus ascii non patisce i problemi legati ai tempi di ritardo. Puoi anche usare il Modbus ascii nel caso decidi di usare la PCOMx.x per dialogare con il modulo SlimLine così non devi effettuare modifiche puoi usare la gestione modbus gestita dal sistema operativo.
Febbraio 23, 2016 alle 9:58 am #39408Massimo
ModeratorePer dare una risposta al problema lamentato ho fatto delle verifiche pratiche ed ecco i risultati:
Eseguendo una Sysfwrite() di un frame dati lungo 64 byte sulla PCOM di un modulo PCB122 impostata a 19200, e, 8, 1 ed avendo un tempo di loop del task back di circa 2 mSec, si iniziano a vedere dei “buchi” in trasmissione. Ciò è dovuto al fatto che l’invio dei 64 bytes del frame sul bus di espansione I2C (Sono trasmessi pacchetti da 4 bytes) non è abbastanza veloce da garantire una uscita continua dei caratteri sulla PCOM. In pratica fà prima la seriale a trasmettere i caratteri di quanto non sia in grado il sistema a fornirglieli.
Per ovviare a ciò basta impostare la PCOM con DTRManagement:=DTR_AUTO_W_TIMES; DTROnTime:=50; DTROffTime:=0; In questo modo non sono più visibili i “buchi” perché mentre la PCOM sta attendendo il tempo DTR On riescono ad arrivare i bytes sufficienti a fare in modo che il flusso in uscita sia costante.
Febbraio 23, 2016 alle 10:35 am #39411Enrico Viviani
PartecipanteGrazie per il supporto. A riprova di quanto discusso, dato che il Panasonic in uso non supporta il protocollo ASCII (se non usando un modulo esterno) ho provato questo:
Invertendo le porte in effetti sul Panasonic non avvengono più gli errori di trasmissione ma non riesco ad usare la funzione Gateway per accedere all’altro slave (la uso per programmarlo dato che non è fisicamente accessibile percui è indispensabile).
Portando a 25 DTROnTime e a 5 DTROffTime riesco ad eliminare completamente gli errori Modbus (1 ogni 620.000 trasmissioni è un valore accettabile), se lascio a 0 OffTime non ottengo le stesse prestazioni, inoltre ho inserito un ritardo di 10 mS sulla FB MobusMaster e mi sembra che tutto lavori correttamente.
Quindi attualmente ho l’altro SlimLine sulla COM0 e il Panasonic sulla PCOM0.0 entrambi a 19200 E 8 1 e con IFTime come da manuale a 1720, l’unica differenza che sulla PCOM ho impostato DTROnTime a 25 e DTROffTime a 5.
In un particolare momento dell’esecuzione invio di seguito 32 messaggi da 32 word (sono i parametri del Panasonic) e ne leggo 12 da 30 word in meno di 2 secondi (prima potevano occorrere anche 3 minuti dato che in caso di errore reinviavo o rileggevo lo stesso messaggio).
-
AutorePost
- Devi essere connesso per rispondere a questo topic.