visualizza l'elenco degli articoli
Industrial Ethernet S7-300/400 CPs -- Informazioni di prodotto -- Definizione delle prestazioni e delle quantità
Numero dei job possibili contemporaneamente
Quali risorse di connessione sono occupate per le connessioni di comunicazione o servizi dell'Industrial Ethernet CP nella CPU S7-300?
Quali sono i limiti di sistema di una CPU F nello scambio dati bidirezionale sicuro tramite la comunicazione S7?
Dove si trovano informazioni sui tempi di trasferimento su PROFIBUS opp. Industrial Ethernet?
Aumento del carico della CPU con una lunghezza dati maggiore di 240 byte nella comunicazione Send/Receive con i CP Industrial Ethernet
Quale capacità di memoria RAM utilizzabile mette a disposizione il CP 343-1 IT per i servizi FTP?
Perché con le connessioni TCP in determinate circostanze si arriva a tempi di reazione troppo lunghi?
Perché con le connessioni TCP in determinate circostanze si arriva a tempi di reazione troppo lunghi?
Numero di ordinazione:

Descrizione
Il comportamento descritto nel seguito vale per tutti i CP Industrial Ethernet, che supportano il tipo di connessione "Connessione TCP". Si tratta qui di un trasferimento dati a puro livello TCP (livello 4 secondo il modello di riferimento OSI). Per questo motivo questo tipo di connessione viene chiamata spesso "TCPnative".

Generalità
Il protocollo TCP ha un controllo di flusso. Questo significa che una unità in ricezione può rallentare una unità in trasmissione, quando questa trasmette i pacchetti dati più velocemente di quanto il ricevitore li possa elaborare. Per questo esiste nel protocollo TCP un elemento di protocollo con il nome "finestra TCP". Questa finestra viene concordata nella stesura della connessione. I CP sopraccitati concordano una dimensione di finestra di 560 byte. La dimensione della finestra si riferisce alla singola connessione e quindi è presente per ogni connessione. Per la comprensione del meccanismo di controllo del flusso occorre prendere in considerazione i seguenti due casi.

  1. Caso: il trasmettitore invia i pacchetti alla stessa velocità o più lentamente di quanto il ricevente li possa elaborare.

    Se sulla LAN (local area network) vengono inviati 10 byte al partner, questo conferma la ricezione dei dati inviando come riscontro per questi 10 byte un numero di acknowledge maggiorato di 10 byte. Un numero di acknowledge maggiorato di 10 byte in un telegramma di acknowledge significa la ricezione e l'elaborazione dei 10 byte inviati per ultimi.
    La finestra TCP in un caso come questo viene a sua volta confermata con la dimensione massima di 560 byte.
     
  2. Caso: il trasmettitore invia più velocemente di quanto il ricevente possa elaborare.

    Il ricevente riceve ora un nuovo telegramma nonostante non abbia ancora elaborato completamente (trasferito alla CPU S7) il telegramma precedente. Di conseguenza esso invia un telegramma di conferma (acknowledge) con un numero di acknowledge maggiorato di 10 byte, ma con una dimensione della finestra di soli 550 byte. Di conseguenza il trasmettitore nota che i dati sono arrivati perché il numero di acknowledge è aumentato del valore 10. Inoltre la finestra TCP è ridotta. (Max. finestra TCP – finestra TCP effettiva = 560 - 550 = 10 byte). Il trasmettitore può quindi trasmettere solo ancora 550 byte, poiché il ricevente ha ridotto di 10 byte la sua finestra di ricezione TCP. Questo è un chiaro segno che il ricevente non può elaborare in tempo tutti i dati.
    Questo meccanismo, descritto nel Caso 2, viene chiamato Controllo di flusso. Se il trasmettitore è sufficientemente veloce, l'unità ricevente riduce la propria finestra TCP fino a 0. In questo modo il trasmettitore non può più trasmettere dati fino a quando il ricevente, in un ulteriore telegramma di conferma, ha nuovamente aumentato la finestra TCP. La connessione di trasporto in questo caso non viene interrotta, succede solo che per un certo tempo non vengono più trasmessi dati.
    I processori di comunicazione elencati sono realizzati, a livello TCP, in modo che il successivo job (dati utili), con finestra TCP che diventa piccola, possa essere trasmesso direttamente. Si tratta qui di una ottimizzazione dal punto di vista della portata dati. Si ottiene solo di inviare tanti job quanti più possibile a partner diversi.

Premessa
Per un ulteriore chiarimento, il tempo di reazione si calcola sul caso peggiore. Un trasmettitore molto veloce invia ciclicamente job che contengono sempre solo un unico byte di dati utili. Teoricamente il trasmettitore potrebbe inviare ancora 560 job, fino a quando la finestra TCP del ricevente viene portata a 0. Questo significa che sul ricevente c'è una coda con ancora 560 job che non sono stati ancora elaborati. Il ricevente deve restituire il byte ricevuto. Sul lato trasmettitore il byte da inviare ciclicamente viene modificato. Si deve rilevare il tempo entro il quale il byte di dati utili modificato è nuovamente tornato nella stazione di trasmissione. Si tratta qui della definizione del tempo di reazione. Anche qui vengono considerati separatamente i due casi citati sopra.

  1. Caso: il tempo di reazione è molto breve poiché i byte di dati utili vengono ricevuti direttamente e immediatamente rispediti indietro. 
    Il tempo di reazione è molto breve.
  2. Caso: il byte dei dati utili appena modificato arriva presso il ricevente come 560-esimo job. Questo deve dapprima elaborare e rispedire indietro 559 vecchi job contenenti il vecchio byte di dati utili. Solo dopo viene elaborato e rispedito il byte rilevante in quel momento, dal punto di vista del trasmettitore, per il tempo di reazione.
    Di conseguenza si può verificare un forte aumento del tempo di reazione. 
    Per determinate applicazioni, questo può essere non accettabile.

Rimedio
Un rimedio diretto non esiste. Il meccanismo del controllo di flusso funziona a livello di protocollo e non può essere letto oppure influenzato dall'utente. Il produttore delle applicazioni può solo ripensare alla frequenza di trasmissione, in particolare dei job ciclici, e provvedere ad adattamenti. Per essere completamente sicuri sarebbe consigliabile una analisi della LAN con un analizzatore di rete durante il funzionamento continuo nella fase di messa in servizio. Se la finestra TCP è permanentemente molto piccola, il trasmettitore deve essere "rallentato" oppure il carico sul ricevitore deve essere distribuito oppure limitato.

Registrazione sulla LAN:
Il grafico seguente, con relative spiegazioni, è dedicato ai tecnici di rete che hanno esperienza di analisi di bus a livello di protocollo. In esso è stato registrato il traffico di telegrammi di una connessione TCP tra 2 processori di comunicazione SIMATIC S7. A partire dalla riga selezionata, i telegrammi sono chiariti più in basso. Il trasferimento dati avviene in modo bidirezionale, cioè i dati vengono trasferiti in entrambe le direzioni. L'indirizzo 140.90.4.1 viene contrassegnato di seguito come stazione 4 e l'indirizzo 140.90.5.1 come stazione 5.

( 37 KB )
Figura 01: Traffico di telegrammi

  • Nella riga 13 selezionata, la stazione 4 invia un telegramma di acknowledge alla stazione 5, in cui la finestra TCP (WIN) è impostata sulla massima dimensione di 560 byte. 
  • Nel telegramma 14, la stazione 5 invia dati utili con una lunghezza di 160 byte (LEN=160). 
  • Immediatamente dopo la stazione 5 invia, direttamente nel telegramma 15, 240 byte di dati utili. Questo è corretto, poiché la finestra TCP è già stata confermata con dimensione 560 byte nel telegramma 13. 
  • Nel telegramma 16 la stazione 4 conferma la ricezione dei dati inviati per il fatto che il numero di acknowledge è aumentato di 400 (160 + 240) byte rispetto al numero di acknowledge nel telegramma 13 (ACK). La finestra TCP ha però ancora una dimensione di 160 byte. Questo indica che i dati sono arrivati nel livello di trasporto (livello 4) dell'unità di ricezione, però non sono ancora stati elaborati. 
  • Poco tempo dopo dalla stazione 4 viene inviato un nuovo telegramma di acknowledge impostando nuovamente la finestra TCP sulla dimensione massima di 560 byte.

In conclusione la registrazione LAN viene resa disponibile come download autoscompattante. In essa i singoli elementi di protocollo possono essere esaminati con un tool opportuno, per es. Wireshark, che serve per l'analisi di connessioni di comunicazione di rete.

TCP_1V_condati.exe ( 30 KB )

 Articolo con ID:13664998   Data:2012-08-20 
Questo articoloè stato utilenon è stato utile                                 
mySupport
My Documentation Manager 
Newsletter 
CAx-Download-Manager 
Support Request
Vai all'articolo
Stampa
Creazione PDF 
Invia l'articolo
QuickLinks
Strumento di compatibilità 
Argomenti
Aiuto
Aiuto on-line
Guided Tour