Sharp7 ed errore 5

[markolino]

Ciao a tutti. Vi scrivo per un piccolo problema che si verifica circa una volta ogni 30-60min nella mia applicazione  scritta in csharp.

L'applicativo gira, per caso mi sono messo in debug per vedere se potevo migliorare qualcosa e mi sono accorto che un task che legge circa 300 bytes da una db ogni tanto va in errore 5: TCP receiving data.

Dopo di che grazie all'auto reconnect che ho implementato tutto torna a funzionare. Non è un problema di PDU superato perché nel caso Sharp7 splitta automaticamente le richieste.

L'applicativo non esegue scritture, ha solo un paio di task che continuano a leggere.

Qualcuno sa dirmi perché può succedere l'errore 5 ?

Ho visto che anche staccando il cavo tra PC e plc...viene generato lo stesso errore.

 

[84paolo]

Non dici nulla su che tipo di PLC stai usando. L'unica cosa che mi viene in mente è provare a dividere la richiesta di 300 byte in 2 da 150 e vedere se cambia qualcosa. Per esempio sui message tra i PLC il limite del singolo message è 240 byte

[markolino]

Paolo hai ragione, ero di fretta e ho tralasciato questa informazione.

La comunicazione è tra il mio applicativo sviluppato in .net framework ed un plc siemens S71500, ma è un software plc perchè il dispositivo è un siemens microbox.

Non penso che sia un problema di max byte superati perchè so per certo che le richieste vengono splittate già automaticamente da Sharp7. Stessa cosa nelle ultime versioni di Snap7.

E' un problema ripeto che capita circa una volta ogni 30-60min per poi scomparire nuovamente, però sarebbe interessante capirne il motivo.

Ho provato anche con un S71200, 1211c esattamente, e dopo un oretta circa è comparso per un attimo lo stesso errore.

Grazie del supporto.

[84paolo]

Da come dici sembra un problema di sovraccarico di richieste da parte del tuo software. Se hai la possibilità di fare dei test prova a dividere i messaggi e ad aumentare il tempo di polling tra i messaggi e vedi se il problema sparisce o cambia e poi valutiamo

[markolino]

Ho avuto modo di farebqualche test, ed ho visto che in realtà l'errore viene causato da una chiamata con meno carico a livello di byte. Ora non ho il numero esatto ma siamo intorno ai 20-25 byte quindi pochissima roba. Detto questo ho provato a ritardare una chiamata di lettura con l'altra di circa 500ms, il problema più o meno è rimasto invariato.

È vero però che con questa modifica non ho l'assoluta certezza che tutte le richieste di lettura siano eseguite una ad una.

Per farlo dovrei mettere un lock sulla chiamata alla dbRead, cosa che potrei provare senza problemi visto che ci sono 5 task con 5 client diversi (ciascuno task ha il suo client) che fanno questa lettura sullo stesso plc, non so se questo può causare questa piccola problematica.

Precisazione: il plc è un 1507F emulato dal microbox.

 

Modificato: 17 gennaio da markolino

[drugo66]

Ciao,

mi ricordo che esiste anche un numero di connessioni max e non vorrei che il PLC interpretasse ogni singolo task (client) come singola connessione; mi ricordo un 4 contemporanei come valore massimo.

Prova a disabilitare un task, se è possibile, e vedi se ti rifà l'errore.

[markolino]

Grazie Drugo. Purtroppo non posso farlo.

Al momento, visto che capita di rado e il tempo di riconnessione è minore del tempo in cui posso perdere dei dati legati alla disconnessione, va bene così. Però ti confermo che al momento ho 5 client connessi allo stesso Plc.

[drugo66]

Mi spiace solo che è passato del tempo e la memoria fa un po' cilecca; da allora abbiamo sempre cercato di non usare più di 3 connessioni contemporanee senza farci troppe domande ("funziona, quindi da ora in poi si fa così"). Appena ho tempo e voglia, provo a fare qualche test e poi, magari, posto i risultati.

Buon lavoro.