MODBUS TCP

[marmoffa]

Buon giorno a tutti. Ho bisogno di una delucidazione sul protocollo modbust tcp del s7-1200.

Ho un dispositivo in rete che riesco a raggiungere tramite svariati software per la lettura del protocollo modbus tcp sia tramite pc che tramite dispositivi mobile, dopo configurato i vari parametri come indirizzo IP porta e indirizzo server  ottengo la lettura deggli indirizzi dei registri modbus.

A questo punto creo un progetto con tia portal V15.1 ed inplemento una comunicazione modbis tcp ma quaest'ultima mi sta creando dei problemi e cioe ottengo sempre un errore 8383(

Errore di lettura o scrittura dei dati o accesso al di fuori dell'area di indirizzi di MB_DATA_PTR.

) e cioe che gli indirizzi non sono giusti.

[Ctec]

Come hai scritto l'indirizzo del registro? Molte volte su apparecchiature moderne si usano indirizzi "puri", tipo 0x0123 (291 in decimale). Per le librerie Siemens, invece, devi usare gli indirizzi con la vecchissima notazione 4xxxxx, cioè 400291 nel caso sopra. Poi attenzione se il dispositivo usa l'inizio area registri da 0, perché Siemens, come le apparecchiature vecchie, usa la notazione da indirizzo 400001 , per cui dovrai aggiungere 1 all'indirizzo voluto.

Nota: Scordati la velocità con il Modbus/TCP sul 1200. E' lentissimo perché non fatto in hardware/firmware, ma con FB dedicate. Ci vogliono una marea di scansioni tra l'invio e la risposta del messaggio. Io ho dovuto cambiare perché non ero abituato a tempi di "risposta" (se così si può dire) così pessimi. Va più veloce in RTU.

[marmoffa]

Ok grazie. Nel mio dispositivo con gli applicativi che ho menzionato prima riesco a leggere gli indirizzi che vanno da16490 in poi .  Ed ho fatto come dici  tu quindi  nel tiaPortal ho impostato l'indirizzo a 56491 (40001+16490)ed anche a 416491 (400001+16490) ma niente sempre lo stesso errore.

[Ctec]

Per l'appunto, quel problema non l'ho avuto.

Proviamo a fare delle considerazioni. Al lancio della MB_Client, in uscita Status ti deve andare a 16#7004, segnale che la porta è aperta e il server è pronto a ricevere i comandi.

A quel punto, per esempio io leggevo il registro 0x211F, 8479 in decimale) devi impostare il registro da leggere con 400001+address, quindi scrivevo 408480 nell'ingresso MD_DATA_ADDR, impostato il MB_MODE a 0 (lettura), e il numero registri da leggere in MB_DATA_LEN, poi il buffer di ricezione in MB_DATAPTR e i dati di connessione nella struttura CONNECT. A quel punto, alzato l'ingresso REQ, dopo un'eternità, arriva la risposta completa in DONE. E i dati nel buffer.

Suppongo ovviamente che il server (il dispositivo da leggere/scrivere) fosse già programmato con IP e porta (502) giusti.

Altrimenti, prova a postare la parte di programma, io non sono esperto di Siemens, ma questa parte l'ho fatta funzionare subito. Solo l'ho cassata per scarsa velocità di risposta.

[marmoffa]

No infatti vedo solo 16#7002 dopo aver disattivato l'ingresso DISCONNECT . Pero se vado nel MB_CLIENT_DB lo stato di CONNECTED e true. Credo che il server e programmato giusto perche con gli alti applicativi riesco a comunicare con i parametri IP e porta 502.

[84paolo]

se ti da quell'allarme normalmente hai qualcosa sbagliato lato PLC.

Prova con le prove più semplici come invertire A e B, verificare velocità ecc e indirizzi.

Per esperienza se con i software in rete va solitamente c'è qualcosa di sbagliato lato PLC

[max.bocca]

Io quando facevo gli esperimenti mettevo sempre un oscilloscopio sul bus per vedere cosa succedeva, le terminazioni e polarizzazione del BUS è fatta correttamente?

[ETR]

@84paolo @max.bocca se non ho letto male, abbiamo solo modbus TCP e non un gateway di mezzo che poi ci porta in RTU.

 

@marmoffa come segnalava Ctec, purtroppo l'abbinamento 1200 e TCP non è dei più felici. Hai provato con la più semplice delle prove a sostituire il tuo server con un programma che ti permetta in simulazione di valutare cosa ti arriva ? Magari fallo in loopback ti modo da utilizzare wireshark.

 

I tuoi diversi applicativi con il dispositivo, funzionano, il server funziona, allora sarà solo lato TIA. Se riuscissi a fare la prova con il server, sempre come diceva Ctec, il primo passo sarebbe quello di metterli in connessione con il canale aperto, ma senza transito di richieste.

 

Passo per passo, dovresti riuscire, come ci sono riuscito anni fa anche io, ma non cosi semplicemente come ci si poteva aspettare.

 

Buona giornata

 

Ennio

 

 

[Ctec]

Sono andato a rivedere. Lo stato #7002 indica che è ancora in corso di collegamento. Pertanto sembra quasi un problema di connessione ethernet.

Che versione dell'istruzione MB_CLIENT hai? Tutto quanto da me indicato sopra (scusa se me ne sono scordato) fa riferimento alla V6.0 (uso TIA V19).

Non ho la V15.1, sono andato a guardare l'errore 8383, e non sembra un problema di indirizzi, ma il fatto che il tuo buffer di ricezione/trasmissione è non adeguato.

Devi, in MB_DATAPTR, puntare a un buffer (generalmente un array di word o di Int) sufficientemente grande da contenere tutti i registri in lettura o in scrittura. Se ad esempio leggi 16 registri, dovrai avere un buffer di almeno 16 word.

 

Modificato: 13 maggio da Ctec

[marmoffa]

Grazie ETR vuol dire che proverò con un altro server  e vi aggiorniamo. Proverò anche a ricontrollare la rete ethernet  come suggerisce  Ctec perché ho notato che a volte anche gli applicativi non riuscivano a collegarsi anche se di raro . Volevo ricordare a gli altri che non sono su bus ma su ethernet TCP 

[cagliostro]

Come saprai, nel DB di istanza della MB_CLIENT, si trova anche una struttura dati denominata TCON_IP_v4.

Che valore è stato associato al parametro ID?

Modificato: 13 maggio da cagliostro

[marmoffa]

Grazie anche a te cagliostro ,questa cosa che mi dici la devo controllare  appena rientro ti aggiorno .

[max.bocca]

@ETR Ennio mi ero lasciato trascinare da @Paolo '84 @84paolo inverti A B pensando che intendeva Modbus con modulo RS 485....

Wireshark con uno switch e porta in monitor è un bel strumento di diagnosi.

 

[ETR]

Come primo istinto  @max.bocca anche io avrei risposto nella medesima maniera, dato che sono cresciuto proprio con il modbus. E' curioso osservare come me lo ritrovo ancora di grande attualità, quando lo davano morente, decadente, vetusto, nel 1996  😮 . Cambia il supporto ma tutto sommato è sempre lui.

 

Buona serata

 

Ennio

 

 

[marmoffa]

cagliostro e staro ma io nel MB_CLIENT_DB non trovo questo parametro.Sto usando la V3.1 di client modbus.

[batta]

25 minuti fa, marmoffa ha scritto:

cagliostro e staro ma io nel MB_CLIENT_DB non trovo questo parametro.Sto usando la V3.1 di client modbus.

È una versione vecchia.
Ma perché stai ancora usanto TIA V15.1? È roba di un bel po' di anni fa!

[marmoffa]

Allora ho testato lo stesso progetto leggendo un simulatore di slave e tutto funziona .Qindi adesso e' ancora meno chiaro di cosa puo essere

[marmoffa]

Batta non credo che la versione del tia portal influenzi questo problema. Sono rimasto alla V15 perche fino ad ora mi sono trovato benissimo per i progetti che faccio di solito.

[cagliostro]

Usando la v3.1 della MB_CLIENT con un TiaPortal V15.1, il parametro da controllare è quello in ingresso alla funzione denominato CONNECT_ID

[84paolo]

Se dalla configurazione di rete click destro sulla CPU, aggiungi nuova connessione TCP e poi configuri ip e porta 502 del nodo modbus. Scarichi sul PLC e vai online su stato connessioni vedi se viene verde la connessione. Poi sul blocchetto mb client usi la connessione configurata con lo stesso id e deve andare. Io una volta ho perso diversi giorni perché al posto di usare il blocchetto mb_client del modbus TCP avevo inserito erroneamente il blocchetto mb_client del modbus rtu

[NoNickName]

Nella specifica modbus gli indirizzi sono massimo 65535 (16bit), e di solito non superano mai i 49999. Quando vedo dei client o dei dispositivi che usano una loro specifica numerazione per indirizzare i registri, usando addressing fuori standard, mi sale il crimine. Scusate l'offtopic

[batta]

12 ore fa, marmoffa ha scritto:

Batta non credo che la versione del tia portal influenzi questo problema. Sono rimasto alla V15 perche fino ad ora mi sono trovato benissimo per i progetti che faccio di solito.

Nel TIA 15.1 trovi una versione più vecchia delle funzioni Modbus. Certo, tutto dovrebbe funzionare lo stesso (funzionava quando è uscita, e deve funzionare ancora), ma passare a versioni più aggiornate potrebbe, forse, risolvere qualche problema.
Domanda: come fai, con TIA V15, a lavorare con hardware recente?
Non so quanti e quali progetti tu debba sviluppare, ma siamo alla V19!
 

[marmoffa]

Ok ho controllato CONNECT_IlD e risultano essere uguali cioè 1 sia dalla mia configurazione sia nil MB_CLIENT_DB .Poi ho fatto come mi ha suggerito 84paolo quindi ho inserito gli ID che risultavano nei collegamenti creati cioè 101 ma niente da fare sempre 8383.

Si Batta sicuramente ci sono aggiornamenti recenti nelle nuove versioni ma ti ripeto per adesso mi ero trovato bene ed ho usato sempre modbus RTU su rs485 e con la versione V15 non ho avuto problemi. 

[marmoffa]

A

Modificato: 14 maggio da marmoffa
Errore

[NoNickName]

14 minuti fa, marmoffa ha scritto:

Ho notato una cosa nel MB_CLIENT_DB nella variabile SAVED_DATA__ADDR il valore che viene salvato è privo della prima cifra ,esempio se imposto come indirizzo modbus 36004  nella variabile si salva il valore 6004 se imposto 16495 si salva 6495 e così via . Vi più aiutare a capire qualcosa?

 

Certo perchè la prima cifra dell'address è l'offset della funzione desiderata.

L'address 6004 ad esempio è in realtà aggiunto ad un offset di +10001 se è un coil, +20001 se è un discrete input, +30001 se è un input register, ecc.. quindi interrogando il 36004 in realtà interroghi un input register con indirizzo di partenza 6003.

 

Example
Request
This command is requesting the content of analog input register #30011 from the slave device with address 11. Each register contains 16 bits.

1
0B 04 000A 0001 1162
0B: The Slave Address (0B hex = address 11)
04: The Function Code 4 (Read Input Registers)
000A: The Data Address of the first register requested (000A hex = 10, + 30001 offset = input register #30011)
0001: The total number of registers requested (read 1 register).
1162: The CRC (Cyclic Redundancy Check) for error checking.

 

Questo è dovuto al fatto che i primi dispositivi avevano memorie condivise e contigue, quindi si aggiungeva un offset per raggiungere le locazioni corrette

Modificato: 14 maggio da NoNickName