Pc - Plc Via Fetch_write - Comunicazione via Ethernet

[tavazzi]

Salve a tutti, so' che non scopro l'acqua calda, ma' il tema e' sempre "caldo". Ho seguito gli interventi precedenti in merito, che mi sono stati molto utili per impostare la cosa come serve a me, e cioe' :

programma in Delphi che fa' cio' che mi serve e tra l'altro si collega a un S7-315 via CP343 . La programmazione della configurazione HW della e' piuttosto banale e ben descritta sia dalla Siemens che dalla documentazione scaricabile in questo forum. Il programma in Delphi, a questo punto, e' ancora a minimi termini perche' non riesco a procedere con la connessione. In particolare ricevo in risposta ai miei tentativi dei codici di errore (10035, 10022, 10056, ecc.) che non trovo documentati da nessuna parte. Inoltre dalla documentazione vista non mi e' chiaro se il socket debba essere di tipo blocking o non blocking. Apparentemente e' piu' facile ottenere la connessione di tipo blocking, ma se la chiamata fallisce si pianta tutto. Qualcuno conosce qualcosa di piu' in materia e mi puo' dare una mano ? Ciao e grazie in anticipo.

Sergio

[tavazzi]

In mancanza di meglio mi rispondo da solo. Ho cambiato componente Socket (Piette) e ora mi collego subito. Ho nel frattempo trovato una descrizione deei codici d'errore (. di Delphi). Non riesco pero' ancora a procedere oltre. Con l'ausilio di NCM S7 vedo che dopo l'apertura della porta, si verifica un errore alla ricezione della stringa di interrogazione (sulla connessione FETCH, a port 2003). La cosa e' verosimile, ma alquanto inspiegabile perche' l'oggetto e' molto semplice, ed e' ben descritto dai manuali Siemens e dall'esempio in VB scaricato dal Forum. Aspetto sempre con fiducia che quacuno abbia un'illuminazione piu' brillante della mia. Ciao a tutti

Sergio Tavazzi

[Bruno]

Ciao sono Bruno (BR1)

Forse hai scaricato il mio esempio... (molto semplificato di come un protocollo da installare su un impianto

deve essere).

Tornando al tuo problema: non ho capito.... per cui parlo e basta

Io utilizzo sia VB6 che C e normalmente uso socket non bloccante

es. VB6 usando API di windows (stesse del C)

...

' Preparo messaggio

...

' Spedisco richiesta (sia essa Fetch o Write)

retval = send(sock, ByVal sMsg, Len(sMsg), 0)

' Controllo send OK

If retval = Len(sMsg) Then

' Definisco il Socket come non Blocking

retval = ioctlsocket(sock, FIONBIO, 1)

' Leggo la risposta dall'altro sistema

bRispOK = False

' Definisco time-out per risposta

dt = Now + iRespTimeOut * ONE_SECOND

buffer = Space(4096)

Do While Not bRispOK

If Not (bRispOK) Then

retval = recv(sock, ByVal buffer, Len(buffer), 0)

If retval <> 0 And retval <> SOCKET_ERROR Then ' SOCKET_ERROR = -1

bRispOK = True

Exit Do

End If

If (Now > dt) Then Exit Do

End If

Sleep (5)

Loop

' Controllo Risposta

If bRispOK Then

....

....

....

In questo modo mi funziona....

Forse non ho capito il tuo problema, se invece ti sono stato d'aiuto sono un poco più contento...

Ciao

BR1

[tavazzi]

Grazie Bruno, ma' nel frattempo sono andato avanti. Il problema che mi bloccava da ultimo era l'usare un tipo String piuttosto che array of char (il debugger NCM S7 mi diceva che la stringa era sbagliato, forse un carattere di troppo in testa alla stringa, non so'..). Ora comunque leggo e scrivo ma' ancora non in modo soddisfacente.

1) quando leggo sono limitato nella quantita' dei dati richiedibili, di fatto a meno della meta' della dimensione del DB che ho creato. Se sto' nei limiti funziona benissimo. Forse non ho capito bene come si fa' l'indirizamento dei dati.

2) quando scrivo, va bene la prima volta , subito fa cadere la connessione causa stringa malformata (la stessa della prima volta. Forse devo svuotare qualche buffer di trasmissione ?

3) nella stringa di risposta c'e' un dettaglio che non capisco : in testa dovrei avere "S5", ma invece ho sempre "x5", dove per x c'e' un numero hex diverso a seconda delle circostanze.

Non so' se sono stato chiaro, ev. (se hai voglia) posso essere piu' esplicativo. Grazie comunque per l'aiuto, ciao

Sergio Tavazzi

[Bruno]

Grazie Bruno.....

Prego !

quando leggo sono limitato nella quantita' dei dati richiedibili, di fatto a meno della meta' della dimensione del DB che ho creato. Se sto' nei limiti funziona benissimo. Forse non ho capito bene come si fa' l'indirizamento dei dati.

Attenzione le schede Siemens 300 (le 400 sono più potenti) riescono a spedirti solamente pacchetti con max 240 byte

(240 - 16 byte di intestazione = 224 ---> 112 word )... forse ora i conti ti tornano !

Quindi se tu richiedi più dati lui ti manda due o più pacchetti consecutivi che tu devi rincompattare (header presente solo nel

primo pacchetto)

Per quanto riguarda l'indirizzamento fai rifermineto al manuale siemens, probabilmente lo trovi sul tuo computer

il file è mn_ncm-ie_72.pdf e in fondo c'è una appendice chiamata Accoppiamento con altri sistemi con FETCH/

WRITE. Sempre per l'indirizzamento ricorda che è un protocollo compatibile con S5, per cui l'indirizzamento è da

pensare sempre a word (word 0 --> byte 0 e 1, word 1 --> byte 2 e 3, word 2 --> byte 4 e 5) non come funziona

l'indirizzamento per S7.

quando scrivo, va bene la prima volta , subito fa cadere la connessione causa stringa malformata

la stessa della prima volta. Forse devo svuotare qualche buffer di trasmissione ?

Non ho capito bene il problema... comunque io pulisco sempre il buffer di ricezione prima di uno scambio (quello di

trasmissione lo svuota il sistema operativo)

nella stringa di risposta c'e' un dettaglio che non capisco : in testa dovrei avere "S5", ma invece ho sempre "x5", dove per x c'e' un numero hex diverso a seconda delle circostanze.

Ti devi trovare S5 !!! l'Header dei telegrammi è quello... controlla la ricezione dei dati e magari lo spacchettamento nel caso di telegrammi diversi

Ciao

Bruno

[tavazzi]

Buongiorno Bruno, e' un piacere conversare con una persona cortese e competente. Peccato il tempo sia limitato. Anche di questo progetto mi occupo nei ritagli di tempo, in effetti. Ad ogni buon conto la ricezione ora e' ok. Ho messo a fuoco le quantita' che posso ricevere e per ora va bene cosi. Non ho ancora provato la ricezione oltre i 240 bytes totali, suddivisa in piu' pacchetti, magari piu' in la'. E' a posto anche l'header ricevuto (ero io a sovrascriverlo ...). L'unico problema rimasto riguarda la trasmissione. In effetti il primo pacchetto va a destinazione, la stringa di risposta e' corretta e poi il patatrac : 1) secondo la diagnostica NCM S7 "Error in the frame structure of a fetch or Write job" 2) conseguente "The module is terminating a connection actively" e fine della trasmissione. Per il momento non saprei che altro dire, se hai qualche idea, sara benvenuta. Ciao

Sergio

[Bruno]

Per quanto riguarda il tuo problema in scrittura, dopo la prima, ti consiglierei di verificare che l'operazione di send sul socket sia della lunghezza giusta rispetto al tuo messaggio. (E' una ipotesi perchè non conosco tale istruzione in Delphi).

Es:

Se scrivi una word significa che sperirai 18 byte (16 per Header e 2 per la word da scrivere), verifica che il send sia fatto di 18 byte.

Io direi che sicuramente il tuo send non è minore in quanto la prima scrittura avviene con successo, però se il messaggio che spedisci ha lunghezza maggiore forse (e ripeto forse) i successivi messaggi sul socket di scrittura (che non è lo stesso delle letture) potrebbero essere interpretati in maniera non corretta dalla CP.

Altre cose non saprei.

Buona fortuna.

Ciao

BR1

[tavazzi]

Ciao Bruno, avevi perfettamente ragione, c'era un byte in piu'. Anche stavolta avevo usato per comunicare la lunghezza del buffer un'istruzione che va bene per il tipo string ma non per array of char: e' bastato mettere il numero nudo e crudo e tutto e' andato a posto. Ora funziona tutto e posso cominciare a dedicarmi al grosso dello sviluppo. Se mi spieghi come si fa', posso uploadare lo zip del progetto, cosi altri non dovranno risudare le stesse gocce di sudore, Ciao

Sergio

[Bruno]

Sono felice che ora hai la base pronta !

Se intendi fare l'upload in archivio dovresti poterlo fare senza problemi : sei già registrato !

Ti consiglio di fare un esempio il più scarno e autonomo possibile (in modo che sia il più comprensibile).

Ciao, alla prossima

BR1

"Good night and good luck"

[Gabriele Corrieri]

Ciao

intervengo solo per dire che qualunque membro dello staff può aiutare nella pubblicazione di file, se Sergio ha bisogno di una mano può contattarmi liberamente.

Ciao

[tavazzi]

Ok, lo zip ora riposa sotto "Software" a disposizione di chiunque. Purtroppo non ho tempo per renderlo piu' esemplificativo, facendo un lavoro frettoloso rischierei solo di introdurre altri errori. La versione Delphi e' la 7, ci sono alcuni componenti esterni (tutti reperibili free su Torry's o analoghi), il piu' importante e' l'interfaccia Socket (da Ics di F. Piette). Sono disponibile ovviamente per ogni chiarimento. Ciao e grazie a tutti.

Sergio Tavazzi

[tavazzi]

Un paio di cosette rapide : 1) (per Bruno ..) ho scoperto che le nuove CP343 (gia' da anni pero'), permettono di leggere/scrivere piu' di 240 bytes. Non ho ancora indagato, ma scommetterei che siamo al livello 8k, che mi sembra meraviglioso. 2) qualcuno ha idea di quanto si possa stressare la comunicazione con un S7-300 mediamente occupato. So benissimo che la questione e' posta in modo un po' generico, ma' per adesso mi basterebbe sapere che non ci sono colli di bottiglia particolari. Grazie e ciao a tutti.

Sergio Tavazzi

[Bruno]

Bentornato !

E' vero le CPU nuove permettono messaggi lunghi, ma mio giovane guerriero non ti far tentare la lato oscuro della forza...

prepara il tuo software in modo che possa gestire hardware diverso, pensa che lo stesso protocollo

ti potrà funzionare su S7-300, S7-400, S5 e schede VIPA.

Ti dico questo perchè io purtroppo mi sono trovato PLC vecchi da connettere in rete e questo protocollo

è uno dei pochi realmente standard e documentato anche se ha i suoi limiti.

Per quanto riguarda lo stress da comunicazione sei un poco troppo generico... considera comunque che le schede ethernet hanno un chip che gestisce la comunicazione con il mondo esterno e poi comunicano con la CPU via bus, non penso che il collo di bottiglia sia la comunicazione...

dipende da che cosa devi fare, tieni presente solo che la comunicazione NON è sincrona con il programma PLC quindi il livello di stress della comunicazione e il loop di ciclo non si influenzano, ma ne devi tenere conto.

Ciao

[tavazzi]

Ciao Bruno, 1) infatti pensavo di procedere per vie parallele, cioe' di mantenere 2 versioni. Modularizando bene il tutto non dovrebbe essere complicato. Non vi va di rinunciare ai benefici di una grossa, grassa mailbox cosi facilmente .. 2) Pensavo anchio piu' o meno le stesse cose, ma volevo verificare se qualcuno aveva qualche termine di paragone, qualche dato o esperienza precisi. Ciao e alla prossima

Sergio Tavazzi