- Questo topic ha 14 risposte, 6 partecipanti ed è stato aggiornato l'ultima volta 3 anni, 4 mesi fa da
.
-
Post
-
In riferimento al blocco ModbusMaster, nel manuale Programmazione IEC 61131-3 LogicLab, si citano i codici di errore captabili attraverso la funzione SysGetLastError. In particolare gli errori durante la ricezione del frame di risposta ai messaggi trasmessi dal master che vengono indicati come 10007500~7 (ovvero da 0 a 7) ma senza associare i vari casi. Nel mio caso particolare ottengo l’errore 10007505 ma non capisco a quale condizione si riferisca (carattere errato, lunghezza errata, CRC, ecc.. ).
Da quanto ho capito dalla lettura del manuale ogni qual volta si esegue un ciclo di lettura/scrittura, a fine ciclo viene alzata l’uscita “Done” sia che l’azione sia andata a buon fine che in caso contrario. E’ però possibile avere indicazioni in tal senso mediante i valori assunti dalle uscite “Ok” e “Fault”. Ma nel caso in cui il ciclo non vada a buon fine, il successivo tentativo di lettura/scrittura viene eseguito direttamente dal blocco ModbusMaster o è necessario eseguire una nuova commutazione dell’ingresso Enable ?
Nel caso in cui si debba leggere sempre la stessa area di memoria in un unico slave tenendo sempre attivo l’ingresso “Enable” i cicli di lettura vengono eseguiti direttamente dal blocco ModbusMaster oppure va sempre implementata l’alternanza dell’ingresso Enable per attivare i vari cicli ?
In effetti non abbiamo riportato tutti gli errori indicando genericamente che l’errore è nella trasmissione o ricezione del pacchetto anche perchè molte volte l’errore dà una indicazione non corretta di quello che è effettivamente il problema. Nel tuo caso l’errore 10007505 indica la ricezione di una risposta da un ID di nodo diverso o la ricezione di un codice di funzione diverso da quello richiesto. Il modo migliore per capire dove risiede il problema è nell’attivare lo spionaggio (Topic).
Per quanto riguarda la lettura consecutiva occorre connettere l’uscita di Done negata sull’ingresso Enable, eventualmente definendo un tempo di Delay se si desidera interporre un tempo tra i comandi. Il FB è stato pensato per permettere il funzionamento in cascata ed in questo topic trattiamo l’argomento.
La risposta all’ultima tua domanda è implicita nella risposta precedente.
Sto cercando di configurare un NetlogIII per la comunicazione in modbus RTU con un drive ABB ACS580 connesso su fieldbus RS485. In LogicLab ho utilizzato i blocchi Sysfopen e ModBusMaster. Il primo dubbio è sulla numerazione delle porte, non sono riuscito a trovare indicazioni sui manuali, il fieldbus corrisponde alla COM2, corretto ?
Una volta caricato il programma, l’inverter mi conferma che la connessione è ok, nessun errore e mi indica che sta ricevendo e inviando dati sul modbus correttamente mentre sul PLC la variabile SysGetLastError mi da l’errore 10007506 e dalla console telnet di Toolly visualizzo l’errore “Answer frame too long”.
Sto cercando di leggere una word a 16bit su un registro di memoria. Ho ricontrollato cavi, polarità, velocità e bit di parità del bus sui due dispositivi e tutto mi risulta corretto. Sul bus non ci sono altri dispositivi, è attiva la resistenza di terminazione sia sul Drive che sul PLC mentre sul drive è attivo anche il bias.
Su XTarget_12 (Da firmware SFW184B000) per aprire la porta seriale è stato realizzato il FB SysSerialPort che permette oltre alla apertura anche di impostare i parametri di comunicazione. Anche se è corretto usare la Sysfopen ti consiglio di usare il nuovo FB (Eventualmente fai l’upgrade del firmware sul NetlogIII, Vedi FAQ). La porta Fieldbus è la porta COM2, l’errore 10007506 che tu vedi come riportato sul manuale si riferisce ad un errore in ricezione.10007500~7 Errore in ricezione frame risposta (Carattere errato, lunghezza errata, CRC).Ora tu mi dici che in Telnet con Toolly vedi “Answer frame too long”, quindi significa che hai attivato lo SpyOn e stai spiando la comunicazione modbus verso il drive. Quindi è visualizzato sia il frame di richiesta inviato che il frame di risposta ricevuto, se controlli questi frames seguendo le specifiche Modbus vedrai probabilmente che nella richiesta è stato richiesto un certo numero di registri e che nella risposta sono stati ricevuti più dati di quelli attesi. Perchè succede questo, dovrei vedere il report di spionaggio su Toolly, ma in generale, sei sicuro di avere impostato correttamente il modo di comunicazione (Baud rate, parità, bits), sei sicuro di usare il giusto codice di lettura e di usare il giusto indirizzo di registro (Ricordati l’offset di 1). Il FB ModbusMaster cita: “In accordo alle specifiche modbus l’indirizzo inviato nel frame dati è (Address-1)” Questo perché chi è Modbus compliant somma 1 all’indirizzo ricevuto, ma molti devices non fanno questa somma, quindi devi essere tu ad aggiungere 1 al valore di Address passato alla FB. Se mi mandi un printscreen della schermata di Toolly magari posso essere più preciso.
Intanto grazie per la velocissima e completa risposta, supporto eccezionale!
Appena riesco faccio un test con il blocco SysSerialPort, effettivamente avevo qualche dubbio sulla differenza tra i due blocchi. Sulla console di Toolly vedo che il pacchetto inviato e ricevuto coincidono:|Tx| 02 04 9C 44 00 01 5F BC
|Rx| 02 04 9C 44 00 01 5F BC
|Er| Answer too longModBusMaster: Type: 0; Node: 2; FCode: 16#03; Address: 40005, Points: 1; IFTime: 286; Timeout: 500; Delay: 1000.
(Mi scuso ma non trovavo come allegare le immagini al forum…)L’indirizzo non è un problema perchè ho una serie di registri adiacenti quindi al massimo dovrei leggere un dato diverso da quello voluto.
Grazie per i complimenti… oggi giornata di ponte ed allora senza le telefonate si ha più tempo per il forum. Il frame modbus inviato non mi torna. il nodo è 02, ma il codice funzione è 04 non 03 come dici di avere impostato. L’indirizzo del registro come vedi è 9C44 che corrisponde a 40004 (Indirizzo impostato -1), chiedi un registro 00 01 ed il CRC è 5FBC.
Ma la risposta è errata, non deve affatto coincidere con la richiesta, sembrerebbe un echo fatto dal drive cosa che non deve assolutamente avvenire, perchè il FB si attende la risposta che dovrebbe essere del tipo 02 04 02 xx xx CRC. Cioè hai chiesto un registro ed il drive ti risponde con 02 bytes seguiti dal loro valore e dal CRC.
Puoi provare a spiare con una porta RS485 in parallelo sulla linea di comunicazione per vedere se dopo il frame di richiesta vi sia un frame di echo e poi effettivamente il frame di risposta. Il FB dopo il primo frame ricevuto lo controlla e se in errore abortisce in attesa del prossimo comando e quindi non ti visualizza l’eventuale frame corretto che segue.
Il perchè dell’errore è evidente sono attesi 7 bytes di risposta ed invece ne arrivano 8.
Ho effettuato il test con il FB SysSerialPort ma senza successo. Il Drive mi dice che non c’è attività sul Bus e non scambia dati, mentre sul PLC il FB ModBusMaster mi da errore 10007010.
Se invece riprovo con il Sysfopen riottengo lo scambio di pacchetti con l’errore già evidenziato. Ho verificato anche sul manuale del drive se esiste la possibilità di risposta echo ma non ho trovato traccia per cui non mi spiego la risposta. Ho riprovato anche abbassando la velocità del bus a 9600 ma senza successo, il cavo non è il top ma considerato che ha una lunghezza di nemmeno 2m non credo ci siano problemi di interferenze.
L’errore indica che il valore di File non è definito, ma hai passato al FB ModbusMaster il valore di File in uscita dal FB SysSerialPort ?Su lunghezze cosi corte il cavo non ha normalmente problemi, ora per capire il problema l’unica è spiare la comunicazione sulla RS485 oppure inviare i comandi Modbus da Toolly (Vedi l’ultimo post di questo topic) o con un programma di simulazione Modbus esempio l’ottimo Modbus Master Simulator.
Ho un problema con Toolly in pratica dopo l’autenticazione al comando SpyData mi risponde che non è attivo. Eppure ho configurato lo SpyOn del FB ModbusMaster a TRUE, come mai? Dove sbaglio?
Il FB ModbusMaster viene eseguito?, in che task hai messo l’esecuzione ricordo che deve esere nella task Back.
Il parametro File è settato corettamente, è riferito ad un FILEP valido ?Ok Grazie, era l’ubicazione del programma che non era in Back. Adesso vedo i dati trasmessi e ricevuti…
Stò sperimentando l’utilizzo del FB ModbusMaster senza successo. Ho un oggetto che accetta comunicazioni Modbus TCP. La connessione all’oggetto avviene correttamente, il parametro File in uscita non è NULL. Utilizzando il programma Modbus Master Simulator consigliato un un altro post… mi legge il dato correttamente.
Ho impostato i parametri nella FB di connessione TCP e Modbus Master nello stesso modo del programma di simulazione. Ottengo l’errore 10007506: immagino di aver definito in modo non corretto i dati e quanti registri leggere… può essere?
Il dato che sto cercando di leggere è un valore al registro numero 5 definito come 32 bit integer (è una temperatura).
Definisco una variabile DINT in LogicLab, definisco gli altri parametri, l’indirizzo meno uno, quindi gli do 4, ma ottengo sempre quell’errore. Ho provato a definire in modo differente la variabile (INT, USINT, ecc…) ma nulla.
So che sto commettendo un errore banale perché l’oggetto comunica in modbus, ma non capisco dove sbaglio.
Utilizza lo spionaggio è la soluzione che ti permette di capire dove sbagli. Ne parliamo prima in questo post o se cerchi troverai molti arogomenti che parlano della console di spionaggio (Articolo).
Riprendo questo post per capire la differenza degli errori di tipo 10007500-7. Mi spiego meglio. Ho uno SlimLine Cortex M7 [MPS054B110], tramite connessione TCP/IP interrogo un dispositivo modBus che mi restituisce su 8 indirizzi diversi 4 BYTE ognuno per comporre dei valori float (REAL). La richiesta avviene in continuo e mi capita in modo assolutamente casuale (ho verificato di tutto: ora, contemporaneità con altre funzioni ecc..) che dopo 2-3 giorni o dopo 5, la comunicazione si interrompa generando l’errore 10007505.
L’unico modo per riavviare la comunicazione è eseguire il reboot dello SlimLine. Pensando potesse essere un problema del dispositivo, ho collegato un PC al dispositivo stesso e con un programmino in Python l’ho monitorato per 2 settimane consecutive ma la comunicazione non si è mai interrotta. In dettaglio questo errore cosa significa oltre al generico “Errore in ricezione frame risposta (Carattere errato, lunghezza errata, CRC)”?. Vi viene in mente qualche altra prova da effettuare?
L’errore che citi compare se si paerdono caratteri nella stringa di risposta, potrebbe essere un problema simile a quello riportato negli ultimi post di questo topic. Utile a capire il problema sarebbe avere un report di spionaggio della comunicazione con Toolly.
Perchè per un pò funziona e poi si blocca è stranissimo, certo che usando il FB ModbusMaster che utilizza il tempo di IFTime per dividere i pacchetti modbus, basta che il dispositivo slave per qualche motivo frammenti la risposta sui più pacchetti TCP che questo potrebbe generare il problema.
Come consigliato nel topic che ti ho linkato ti consiglio di sostituire il FB gestione Modbus con la nuova versione ModbusMaster_v1 che è stato completamente ridisegnato, eliminato il controllo sul tempo di interframe, il pacchetto viene completamente sniffato e verificato rendendolo indipendente dai tempi.
- Devi essere connesso per rispondere a questo topic.