Comunicazione TCP

[walterword]

Sto facendo un re-vamping e tra una cosa e l'altra ho passato la settimana piu brutta della mia vita....

Azionamenti che s impallano e che ripartono dopo aver distrutto e ricreato i db di interfaccia con il plc , scalance , sostituzione S7-400 con S7-317 F , aggiunto remotati con moduli F , compilazioni  rifacimenti di pannelli dai progetti inesistenti , di tutto e di piu....

Ora però ho un livello 2 del quale nessuno conosce il protocollo , ma c'e' sul pc un tool che mi informa sullo stato della comunicazione TCP.

Con i  nuovi plc S7-300 non c'e' piu bisogno di inserire il pc generico nel NETPRO , nel netpro si inseriscono solo i collegamenti S7 per la comunicazione del safety , gia fatto ,compilato e gira.

Essendo una S7-400 sostituita con una 317 , con l'aggiunta di una scheda CP DP 342 mentre prima usava una delle due porte della 400 ho dovuto rifare tutte le librerie di comunicazione sostituendo per esempio le SFC14 e 15 con le FC1 e 2 per il DP .Un lavoraccio di m.....considerando poi le modifiche sugli altri plc anch'essi modificati con schede e configurazione.

Ora mi manca solo di capire cosa mi manda il livello 2 e sto utilizzando due blocchi che chiamo  Server e Client ....lato plc 

Nel server utilizzo la FB65 "TCON" e la FB64 "TRCV" per mettere in ascolto il plc e per rispondere ai ping di "Alive" tra i due sistemi .

Poi con la FB63 "TSEND" mando i dati .

In definitiva 

TCON =creo la connessione 

TRCV=ricevo i dati 

TSEND=scrivo i dati

Nel client del plc uso gli stessi blocchi per connettermi al pc e scriverci .

Il pc usa due porte che ho configurato nel plc come porta client e porta server .

In sostanza tra i due sistemi , plc e pc , vi sono due connessioni client-server e server-client

La cosa che non capisco è che mentre il pc sa a chi scrivere , indirizzo ip , il plc bo.....c''e una struttura che ingloba l'indirizzo del pc remoto , l'ho impostata ma nulla 

Col ping da entrambe i lati funziona tutto e per lo scalance switch il pc è trasparente , non è in topologia.....

Avete qualche idea?

Ciao e grazie

Probabilmente lunedi Renzi si recherà qua con padoan e moretti e il dirigente del INPS perche se non risolvo praticamente ci saranno 300 cassa integrati ....situazione allucinante 

 

[dan64100]

Se non ho capito male quindi la comunicazione PC->PLC(server) dovrebbe essere OK, almeno come connessione/invio dati.

 

Comincia col capire se il PC è effettivamente in ascolto TCP su quelle coordinate (IP,Porta).

Digita sul PC da prompt dei comandi:

netstat -a

vedrai la lista di tutte le connessioni con relativi IP,Porte e Protocolli, inoltre le connessioni in ingresso le vedrai come LISTENING o ESTABLISHED.

 

Supponendo, come credo se il sistema funzionava prima, che il server sia in ascolto, se hai accesso al PC come amministratore, prova ad installarci WireShark.

Imposta il filtro "NET xxx.xxx.xxx.xxx" (con xxx... indirizzo del PLC per filtrare tutta l'immondizia) e setta come protocollo TCP.

 

In questo modo puoi:

- Vedere il dump di tutti i pacchetti che il PC manda al PLC

- Vedere se il PLC avvia correttamente la richiesta di connessione.

 

Se sei alle pezze escludi tutto da OB1 e chiama solo le procedure di connessione, a volte i copiaincolla sono assassini, così puoi debuggare solo la comunicazione PLC->PC.

 

In bocca al lupo  

[walterword]

Purtroppo su questo pc non ho installato Kali linux

Ho scoperto che in realtà i 2 blocchi FB chiamati con suffisso -server e -client sono due server , nel plc .

Questo lo dimostra il fatto che nella S7-400 vecchia i due collegamenti in NETPRO non inizializzano la comunicazione e non sanno chi sta dall'altra parte per con il TCON dovrebbero aprire due connessione su due porte che sono la 2001 e la 2002 e mettersi in ascolto .

Il blocco FB chiamato server dopo che la connessione sia diventata OK deve ricevere i dati e rispondere l'ack mentre quello chiamato erroneamente client dopo la connessione manda i dati al pc ed attende l'ack. Questo errore di interpretazione lo hanno fatto perchè a livello utente un blocco riceve i dati del tracking e del handling dal pc mentre l'altro invia gli stati e altre cose .

Una terza connessione nel plc è quella veramente client , ossia la richiesta dati dal barcode BCR .

Purtroppo ieri sera alle 17 , sabato, è stato deciso di ritornare piu o meno alla condizione finale.

Tolto il plc 317F dal rack ed aggiunto un IM, inserita la cpu della 400 e ripristinato tutto , domani lavoreranno e saremo di nuovo la ....senza nessuna idea precisa

Sto verificando i parametri della struttura TCON Parameters e tutto il resto compreso un documento siemens per questo tipo do comunicazione .

Nel manager , cliccando su blocchi e premendo CTRL+D si apre una finestra di debug degli stati e per quanto riguarda la comunicazione tcp ci sono 3 frecce verdi che indicano chi tenta di connettersi al plc , le porte e gli IP degli stessi , Uno dei due passa da verde a rosso continuamente , infatti nel pc viene visualizzato lo stato la comunicazione che tenta a connettersi , manda un check alive e ritorna un timeout o errore, la dimensione del pacchetto da e verso è sempre 272 

Situazione pesante anche da un punto di vista gestionale-commerciale  ...

Tra l altre cose ho perso un sacco di tempo con le cpu connesse in dp al master che gestiscono le CU degli azionamenti , ho dovuto cancellare i DB di istanza e di comunicazione , ricrearli e ricaricarli perchè negli azionamenti tramite Simotion vedevo gli stati e gli encoders tutti ok ma nel plc no , senza contare vari bachi e porcherie come rele' che si impastavano o altre cose , sempre all'ultimo minuto 

 

[walterword]

purtroppo questo impianto è in rete con altri impianti e la rete aziendali con scarsità di inidirizzi .

Ho proposto una soluzione di creare una sotto rete con relativo router-firewall siemens per disaccoppiare l'impianto da tutto il resto , ma questo non è possibile ora

Per cui vedro' centinaia di dispositivi e faro' fatica a capire ....

Credo che comunque il problema sia di natura locale , plc siemens