Vai al contenuto

Trasmissione dati in UDP da PC a SlimLine

Support ElsistTopicTrasmissione dati in UDP da PC a SlimLine

Home › Forum › Controllori SlimLine e Netsyst (LogicLab) › Trasmissione dati in UDP da PC a SlimLine

Stai visualizzando 6 post - dal 1 a 6 (di 6 totali)
  • Autore
    Post
  • Febbraio 5, 2016 alle 7:29 am #35932
    Antonio
    Partecipante

    Ho realizzato un sistema per l’automazione di fontane artistiche (circa 160 uscite) con una applicazione in VBNet che invia una ciclicamente una stringa di comando (sequenza di byte) al PLC in UDP. Il tutto sembra funzionare egregiamente tranne che, occasionalmente l’interfaccia ethernet va in blocco e/o i moduli si spengono e sono costretto a riavviare per ripristinare il normale funzionamento.

    Intuisco che il problema sia legato alla velocità di trasmissione dei messaggi (dell’ordine di 3 -5 – 10 decimi di secondo) che probabilmente saturano il buffer per cui vorrei sapere se ci sono delle modifiche da fare nel programma del PLC che utilizza la funzione SysUdpRcv oppure c’è un limite fisico alla velocità di invio ? Mi basterrebbe una modifica che impedisse in ogni caso il blocco totale dell’interfaccia.

    Febbraio 8, 2016 alle 7:54 am #39345
    Sergio Bertana
    Amministratore del forum

    Non mi dici che versione hai del sistema operativo, dalla versione SFW184B000 abbiamo riscritto parte dello stack TCP/IP se hai una versione precedente ti consiglio di eseguire l’upgrade (Vedi FAQ).

    I pacchetti UDP sono bufferizzati in un buffer FIFO circolare, ad ogni loop della task di background (Back) il buffer viene controllato ed i dati sono estratti. L’unico problema che posso immaginare è che se sei troppo veloce nell’inviare i dati e/o se il tempo di esecuzione della task Back è troppo elevato (Screenshot) potresti perdere dei pacchetti.

    Non capisco cosa vuol dire i moduli si spengono, posso immaginare che l’esecuzione del programma si arresti (Viene disabilitata l’uscita di Ready). Se è così sarebbe utile avere il file di log e/o analizzare il risultato del comando Syslog (Topic).

    Il file di log di sistema (Logs.txt) si trova nella cartella System, per vederlo ci si connette in FTP con il sistema e si scarica il file (Topic), oppure è possibile da pagina web indirizzare il file per vederlo nel browser (Screenshot).

    Febbraio 8, 2016 alle 3:10 pm #39350
    Antonio
    Partecipante

    Per chiarire i moduli si spengono intendo che si spegne la spia gialla lampeggiante sui moduli, il sistema operativo è quello aggiornato. Per quanto riguarda il log ho operato il test in modo da provocare il blocco ottenendo il seguente risultato che però non capisco da che possa dipendere. Ecco un estratto del file Logs.txt.

    [E] SFR050 [08/02/2016 15:51:44]  1020, Except: WDOG At:0x00000000     
    [L] SFR050 [08/02/2016 15:51:44]  1000, System power on                
    …
    [L] SFW184 [08/02/2016 15:51:53]  6040, Restart:2, ApplID:0xB8525548   
    [L] SFW184 [08/02/2016 15:51:57]  6000, Run ApplID:0xB8525548          
    [E] SFR050 [08/02/2016 15:55:53]  1020, Except: WDOG At:0x00000000     
    …
    [L] SFW184 [08/02/2016 15:57:26]  6040, Restart:8, ApplID:0xB8525548   
    [E] SFR050 [08/02/2016 15:57:52]  1020, Except: WDOG At:0x00000000     
    [E] SFW184 [08/02/2016 15:57:52]  6030, Too restarts, ApplID:0xB8525548

    Febbraio 9, 2016 alle 9:19 am #39351
    Sergio Bertana
    Amministratore del forum

    Il sistema come dicevo nel post precedente và in stop resettando l’uscita di Ready che a sua volta blocca tutti i moduli di espansione (Spia gialla spenta). Ho analizzato i logs e come si vede vi sono una serie di eccezioni di watchdog, lo strano è l’indirizzo a cui avvengono 0x00000000 (Che versione hai del software ?), perchè l’errato indirizzo sulla eccezione di watchdog è un bug risolto sull’ultima versione, l’indirizzo è utile per capire dove avviene l’eccezione (Topic).

    Per normativa un programma non deve mai arrestarsi, quindi il sistema su eccezione tenta un riavvio, ma se il riavvio non riesce per 10 volte consecutive, per sicurezza si arresta in stop (Topic).

    Non mi spiego il tuo problema, la saturazione del buffer UDP non dovrebbe generare in alcun modo l’aresto ma solo la perdita di pacchetti dati. Comunque attiviamo una serie di test per cercare di riprodurre in laboratorio il problema. Nel caso non riuscissimo a vederlo potremmo organizzare una assistenza via TeamViewer.

    Febbraio 9, 2016 alle 10:00 am #39353
    Antonio
    Partecipante

    Sembra che ho appena risolto il problema con il totale azzeramento dei messaggi di errore nel log e il funzionamento ottimale del sistema anche con velocità elevata di trasmissione.

    In pratica operando un debug puntuale penso di aver individuato il problema nel parametro RxSize del FB SysSktListen, posto erroneamente a 10000 (l’ho eliminato completamente).

    Per quanto riguarda il SO sto adoperando il SFW184B000 su target 12. Per inciso ho visto che esiste una nuova versione delle funzioni UDP che mi riservo di testare in seguito.

    Febbraio 9, 2016 alle 4:06 pm #39354
    Sergio Bertana
    Amministratore del forum

    Nel nuovo sistema operativo come dicevo abbiamo completamente riscritto parte dello stack TCP/IP, per ricevere i pacchetti UDP devi utilizare il blocco funzione SysUDPServer. Ti consiglio di modificare il programma ed utilizzare questo nuovo FB perchè ottimizza anche la velocità di gestione e i vecchi FB con il tempo non saranno più supportati.

  • Autore
    Post
Stai visualizzando 6 post - dal 1 a 6 (di 6 totali)
  • Devi essere connesso per rispondere a questo topic.