Comunicazione Modbus Con S_send_si E S_recv_si - Si blocca la comuincazione

[matrixsellone]

Ciao a tutti,

mi trovo a dover comunicare via modbu con una centralina di protezione alternatore (Thytronic).

Ustilizzo una scheda 1SI MODBUS/USS con codice 6ES7 138-4DF11-0AB0, installata si di una periferica Profinet ET200S.

Il driver funziona corettamente, ovvero, una volta inviata la query allo slave (luce TX), questi risponde con RESPONSE coerente (luce RX).

Dopo un numero casuale di transazioni, la comunicazione si ferma, ovvero il PLC non restisce il DONE dalla fuinzione SEND, nonstante il bit di REQ (richiesta) continui a funzionare correttamente.

Il LED di TX ed RX di spengono, come se il driver fosse diabilitato.

Se faccio uno STOP/RUN della cpu (del tipo 315-2EH13-0AB0) la comunicazione riparte, salvo fermarsi dopo un altro numero x di transazioni eseguite.

Sapete per caso il motivo di questo "blocco"?

A scanso di equivoci, l'OB100 è completamente vuoto, ovvero non si esegue nulla a livello soft durante il riavvio.

Grazie mille.

[cagliostro]

Salve,

ovvero il PLC non restisce il DONE dalla fuinzione SEND

immagino tu faccia riferimento alla funzione S_SEND_SI [che per default è la FB3]??

Detto questo, i parametri di uscita ERROR e STATUS che informazioni danno???

Modificato: 2 luglio 2010 da cagliostro

[matrixsellone]

Ciao,

esattamente quello ..

Comunque, il problema è proprio il fatto che la funzione non mi restitusce più nulla; né valori su ERROR, né su STATUS, nonstante, come ripeto, il bit di REQ si alto.

Davvero non so cosa pensare .. mi preoccupa moltissimo il fatto che lo STOP/RUN della CPU faccia ripartire il tutto.

Domani mattina continuo coon le prove, sperando di trovare il problema.

[cagliostro]

la S_SEND, viene chiamata in modo continuo o su eventi ben precisi??

Sempre che tu non lo abbia preso in considerazione oppure già fatto, solo per fini di test sarebbe interessante provare a richiamare la S_SEND una volta solamente ogni x tempo.

Quindi su invio finito, attivare la corrispondente funzione di lettura, e poi sempre su lettura avvenuta, attendere un tempo x (circa 1 secondo) e poi eseguire nuovamente la S_SEND.....

Almeno per capire se il problema può dipendere dalle tempistiche determinate dall'esecuzione delle funzioni di trasmissione e ricezione dati.

Modificato: 2 luglio 2010 da cagliostro

[matrixsellone]

Ciao,

La S_SEND è chiamata continuativamente.

Eseguo la query, attendo la risposta, e nel caso in cui la risposta sia corretta, eseguo la query al registro successivo.

Posso comunque provare a fare come dici.

Lunedi implemento la modifica e ti faccio sapere.

Grazie mille.

[Falux]

Ciao, anche se non ho mai scritto vi seguo abbastanza spesso.

Io avevo un problema simile, con il tuo stesso modulo Modbus dovevo comandare 12 schede elettroniche e capitava che mi si impallasse la comunicazione proprio come ti si impalla a te. Fortunatamente ho scoperto che la causa del problema nel mio caso era ad un errata programmazione del micro delle schede slave. Mi è bastato sostituire i micro difettosi e tutto adesso (almeno per il momento) fila liscio.

[matrixsellone]

Ciao a tutti.

Questa mattina ho fatto le prove che mi aveva consigliato Cagliostro, senza però ottenere alcun risultato.

Ho risolto, tristemente, abbassando la frequenza con la quale eseguo le query, introducendo un clock a tempo variabile per calibrare correttamente il tempo di esecuzione delle richieste allo slave.

Risultato: a 50ms tra una query e la successiva, il sistema funziona correttamente, senza mai fermarsi.

Secondi vuoi può essere una soluzione sensata, stante il fatto che non mi occorre assolutamente una particolare velocità nell'eseguire le query?

Grazie mille.

[cagliostro]

Salve,

Ho risolto, tristemente, abbassando la frequenza con la quale eseguo le query, introducendo un clock a tempo variabile

probabilmente nel mio precedente messaggio non sono riuscito a spiegarmi correttamente, in sintesi lo scopo era appunto quello ritardare l'invio delle query attraverso un timer di tempo x che poi ragionevolmente in funzione di ciò che devi fare , avrai calibrato correttamente.

Secondi vuoi può essere una soluzione sensata, stante il fatto che non mi occorre assolutamente una particolare velocità nell'eseguire le query?

Se non ti occorre assolutamente una particolare velocità ed avendo trovato una soluzione affidabile, da un mio personale punto di vista direi che potresti lasciare così come hai fatto.

Ovviamente uno vorrebbe capire questo da cosa può dipendere, io non so se hai dato un'occhiata approfondita al manuale, ma tieni presente che trà l'invio di una richiesta, la risposta ed il succesivo invio, ci sono dei tempi tecnici di trasmissioni che definiscono il limite del sistema in funzione della velocità di comunicazione, tempo ciclo CPU, risposta dello slave alla query etc. etc.

Per esperienza personale uno penserebbe che cautelandosi con i bit di invio effettuato, risposta dello slave ricevuta, possa coordinare l'invio della query successiva senza nessun problema.

Ma nel tempo mi sono visto costretto anche io a dover inserire delle "pause" che poi si sono dimostrate determinanti nel corretto funzionamento della comunicazione.

[matrixsellone]

Ciao Cagliostro,

Ho ripreso in mano solo ora il progetto in esame.

Un dubbio; se alzo il tempo di ritardo tra una query e l'altra (ad esempio, 60ms .. con il quale eseguo una scansione di tutte le query in circa 5sec), mi metto in una condizione di sicurezza da eventuali "blocchi" del driver, oppure è consigliabile utilizzare un delay calcolato correttamente?.

Il problema in sostenza è che il driver andrà inserito in diversi PLC, ognuno dei quali avrà ovviamente tempi di ciclo differenti; mi risulterebbe quindi difficile ricalcolare ogni volta il delay delle query.

Grazie mille per l'attenzione.

[cagliostro]

Salve,

nei precedenti post scritti, affermi che non hai bisogno di una particolare velocità per inviare le query.........

mi metto in una condizione di sicurezza da eventuali "blocchi" del driver, oppure è consigliabile utilizzare un delay calcolato correttamente?.

La condizione di sicurezza basandosi così sul buon senso potrebbe andar bene, ma potresti anche sebbene ribadisco per te non è un problema rendere il sistema per quanto concerne la comunicazione un tantino più lento.

Se per te non è un problema io farei un calcolo del ritardo sulla base delle informazioni passate da Siemens, introducendo magari un offset di sicurezza di qualche 4-5 ms.

Il problema in sostenza è che il driver andrà inserito in diversi PLC, ognuno dei quali avrà ovviamente tempi di ciclo differenti; mi risulterebbe quindi difficile ricalcolare ogni volta il delay delle query

La butto li.........io prenderei in considerazione il caso più sfavorevole per applicare poi i medesimi delay anche agli altri. se questo non è un problema praticherei questa soluzione.

Modificato: 10 luglio 2010 da cagliostro

[bigalex]

Personalmente non ho mai utilizzato Modbus con Siemens però ho utilizzato ed utilizzo Modbus con Schneider ed altri costruttori.

Normalmente Non si fanno le query temporizzate.....

Le query in caso di lettura ciclica devono essere vincolate al fatto di avere la porta di comunicazione non attiva ovvero l'ultima comunicazione (in lettura o scrittura deve essere) terminata.

I blocchi di comunicazione che utilizzi dovrebbero avere dei bit (o registri) di stato dove si può sapere se il job di lettura o scrittura è terminato.

L'importante è quindi interbloccare le query con lo stato di busy della porta di comunicazione.

In questo modo la comunicazione sarà ottimizzata alla massima velocità che il sistema consente di ottenere.

Inoltre considera che non tutti gli slave Modbus rispondono con la stessa velocità a prescindere dal baudrate.

Infatti tu fai la query a 19200 baud lo slave riceve la query e poi con il suo tempo di elaborazione esegue la richiesta Modbus della query e risponde comunicando la risposta a 19200 baud.

In alcuni casi la lentezza di preparazione della risposta da parte dello slave può creare errori di timeout.

Altra cosa se la tua funzione ha un settaggio del time out verifica che non sia disabilitato.

Infatti se controllo del timeout non è abilitato in caso di errore nella comunicazione la funzione di comunicazione attivata non si chiude automaticamente.

bigalex

Modificato: 10 luglio 2010 da bigalex

[matrixsellone]

Ciao Bigalex,

il sistema funzionava originariamente come da illustarto:

1) Eseguo la query

2) attendo la response dello slave

3) solo se questa è positiva e coerente, procedo alla query successiva, altrimenti richiedo la query errata, sino a generare un eventuale allarme di query errata

Il problema è che, anche facendo cosi, il sistema si ferma dopo x transazioni, per i motivi sopra illustrati da cagliostro.

Il tutto resta in test (per adesso sono circa 3 giorni di scambio continuativo di dati senza interruzioni).

Se mai a qualcuno dovesse servire il sorgente, sarò ben lieto di postarlo.

Buona giornata a tutti.

[cagliostro]

Salve,

Se mai a qualcuno dovesse servire il sorgente, sarò ben lieto di postarlo.

se per te non è un problema inviare il sorgente,la prossima settimana potrei darci un'occhiata.

Quanto postato da Bigalex non fa una grinza, ora non so se le routine per la trasmissione in Modbus sviluppate da Schneider restituiscano degli stati di porta occupata in ricezione o trasmissione o di job eseguiti, diciamo più precisi o accurati.

Immagino come già da postato nel messaggio #5, matrixsellone utilizzi i bit di stato DONE (ordine terminato senza errori) oppure NDR a seconda delle funzioni scelte per interbloccare la comunicazione.

Da questo punto di vista, Siemens non mi sembra metta a disposizione altre informazioni, quindi per i discorsi fatti in precedenza, purtroppo bisogna ricorrere a questi sotterfugi non proprio eleganti per aggirare l'ostacolo.

Magari al posto di un ritardo con timer, si può pensare sul bit di Job eseguito, di ritardare il successivo ordine di lettura o scrittura dopo che è stata eseguita una o due scansioni del programma. Tieni presente che il bit di DONE o NDR sono disponibili per una sola scansione........

Potrebbe anche darsi che qualcosa ci stia sfuggendo, ecco che visionando il codice e se possibile anche quanto impostato nella configurazione hardware del modulo Modbus, magari salta fuori qualcos'altro che permetta di risolvere il problema del blocco della comunicazione senza cause di errori.

Ultima cosa, hai pensato di interpellare la hot line Siemens per sottoporre a loro il problema??

Io non ho guardato inoltre se su questo modulo ET200S, siano stati rilasciati anche degli aggiornamenti al firmware della scheda e non so neppure se ci siano, peò giusto guardare o chiedere conferma di ciò potrebbe anche essere utile, sempre che tu non lo abbia già considerato.