Rs485 2 Fili E Rs485 4 Fili

[sammirati]

Buona giornata.

Devo far comunicare in modbus RTU un PLC FP7 Panasonic(master) con 19 Flow Computer Microload della FMC(slaves). La distanza tra il master e l'ultimo slave è di circa 600mt.

A tale proposito ho una scheda AFP7CCM2 che fa da interfaccia hardware per il master. E' una scheda con 2 porte RS485(2 fili)/RS422(4 fili) configurabile e terminabile.

I Flow Computer possono comunicare sia in RS232 che in RS485(4 fili!!)

In campo hanno steso un cavo con una sola coppia twistata.

Il problema è adattare il master 2 fili con gli slaves 4 fili. Da quello che so basterebbe ponticellare il Tx+/Rx+ e Tx-/Rx- lato slaves e tutto dovrebbe funzionare.

Sto effettuando dei test simulando gli slaves utilizzando un convertitore modbus ethernet/seriale Moxa MB3180 e modsim sul mio PC.

Il problema è che se setto la porta seriale del Moxa su RS485 2 fili tutto va bene, anzi benissimo: il PLC FP7 della Panasonic è un vero gioiello di potenza.

Quando mi metto nella situazione che troverò in campo e cioè con la porta seriale del Moxa configurata come RS485 4 fili la comunicazione si interrompe(illegal packet).

No vorrei avere lo stesso problema nella condizione reale di impianto, cioè con i Flow Computers.

Qualche suggerimento?

Grazie in anticipo

[TiBo]

... non mi risulta esista la 485 a 4 fili.

Tu devi configurarti in RS485 e collegare due fili terminando la prima e l'ultima unità.

Ho ben compreso la tua domanda?

[Roberto Gioachin]

La rs485 4 fili ha le caratteristiche elettriche della rs422 ma permette di fare il multidroop con n. slave, la rs422 a volte non lo permette, dipende dall'elettronica interna.

I Flow Computer possono comunicare sia in RS232 che in RS485(4 fili!!)

Di solito si utilizza la rs485 4 fili quando non viene supportata la comunicazione half-duplex ma solo full-duplex.

Modbus però supporta la comunicazione half-duplex.

Il tuo problema secondo me è il convertitore, non ho mai usato quel modello, ma probabilmente ha una configurazione da fare.

moxa spesso ha delle configurazioni particolari da fare anche sul pc.

Da quello che so basterebbe ponticellare il Tx+/Rx+ e Tx-/Rx- lato slaves e tutto dovrebbe funzionare.

Ti conviene fare proprio così.

[fradifog]

Se la comunicazione è half duplex bastano due fili,ma bosogna ponticellare.Se è full duplex servono 4 fili

Modificato: 7 marzo 2015 da fradifog

[sammirati]

Purtroppo non riesco a trovare sui manuali del flow computer se questo è HD o FD, e nemmeno il supporto tecnico dalla casa madre mi è molto d'aiuto finora. Fosse FD temo che il contemporaneo funzionamento del trasmettiore e del ricevitore manderebbero la comunicazione in TILT come mi succede con il convertitore MOXA.

Sto provando a configurare il MOXA come half duplex 4 fili senza successo finora. E forse proprio perché 4 fili non ha nemmeno senso quello che sto facendo...

Ma tirare un cavo con 2 coppie twistate no?!

Domanda retorica che dovrei fare al cliente e sulla quale è meglio tacere...

[Roberto Gioachin]

Fosse FD temo che il contemporaneo funzionamento del trasmettiore e del ricevitore manderebbero la comunicazione in TILT come mi succede con il convertitore MOXA.

Mi sa che hai confuso.

A supportare il Full-Duplex non è la parte hardware, ma il protocollo.

Tu parli di protocollo modbus ed io ti ho già detto che il modbus supporta Half-duplex, quindi...

La scheda dei tuoi flow computer, da come hai detto tu, sono re485, quindi devono poter supportare half-duplex, altrimenti ti avrebbero scritto rs422.

Sto provando a configurare il MOXA come half duplex 4 fili senza successo finora

Non esiste half-duplex a 4 fili, ma solo a 2 fili.

Visto che hanno steso solamente una coppia, rasegnati a configurare tutto in rs485, 2 fili, half-duplex.

Se poi il moxa non riesce a funzionare, cerca un prodotto alternativo, ne esistono molti.

Modificato: 9 marzo 2015 da Roberto Gioachin

[pomat]

Mi sa che hai confuso.

A supportare il Full-Duplex non è la parte hardware, ma il protocollo.

Forse [at]sammirati intendeva dire che quando ponticelli la rs485 4 wire, ovviamente quello che mandi in Tx te lo ritrovi in Rx, il che, salendo al livello del protocollo Modbus (ma vale per qualsiasi protocollo half-duplex), può significare il doversi beccare in ricezione una echo del pacchetto inviato. Se l'applicazione Modbus non si aspetta una echo e non è in grado di scartarla, tenta di parsarla e questo può generare un errore. Non so se sia questo che succedeva [at]sammirati (non è il MOXA il problema, a me è successo con altri media converter, ma di solito succede quando simuli il master), tuttavia questo non implica che il flow computer, opportunamente configurato, si comporti allo stesso modo e dia errore. Temo che la certezza aimé la si possa avere soltanto sperimentando direttamente sul flow computer.

Modificato: 10 marzo 2015 da pomat

[sammirati]

pomat è esattamente quello che intendevo dire. Spulciando ogni manuale possibile sono riuscito a trovare quello della porta seriale dove indicano che il line protocol è full duplex, no echo character. Il full duplex mi è stato confermato proprio oggi dal fornitore. Considerata questa caratteristica non dovrei avere problemi ponticellando rx e tx dello stesso segno ed utilizzando un master half duplex, o sbaglio?

Grazie per la partecipazione di tutti

[pomat]

@sammirati: il fatto che la linea fosse full-duplex era fuor di dubbio, altrimenti non ci mettevano certo la porta 4 fili... Ora, il "no echo character" penso sia riferito comunque ai 4 contatti NON ponticellati, il che comunque sarebbe ovvio: se mantieni i due canali Tx e Rx separati non hai un ritorno sulla linea, al contrario della RS485 a 2 fili, dove il canale è unico. Quello che mi sento di dire è che ponticellare potrebbe (potrebbe) semmai dare problemi in modalità master, ma dato che stai usando la modalità slave, è davvero improbabile che ci possano essere problemi. Uno slave, in presenza di più nodi di rete analoghi, scarta (discard) pacchetti continuamente: scarta tutti i pacchetti che non riconosce come request ben formate e indirizzate a lui. Perciò, se anche fosse che ponticellando dovesse ritrovarsi in ingresso tutte le response che invia, le scarterebbe a prescindere.

Non dovresti avere problemi, il condizionale è d'obbligo.

[Roberto Gioachin]

Il full duplex mi è stato confermato proprio oggi dal fornitore.

Allora mi sa che non hai alternative, devi per forza avere una linea con due coppie di cavi (twistati).

Per tecnica full duplex si intende la possibilità di far coesistere dati inviati e ricevuti allo stesso istante; su un singolo doppino questo non è possibile.

Devi avere per forza due linee (due doppini), una per la trasmissione dal master che arriva sulla ricezione degli slave, tx+ e tx- del master collegati con rx+ e rx- di tutti gli slave, e una per la trasmissione degli slave con tx+ e tx- di tutti gli slave collegati con rx+ e rx- del master; in questo modo il master può inviare dati anche mentre sta terminando la ricezione dei precedenti.

Devi considerare inoltre che il protocollo modbus potrebbe benissimo lavorare in half duplex, ma ad ogni messaggio che il master invia, c'è sempre un messaggio di ritorno dallo slave interessato verso il master, quindi avrai sempre sia trasmissione che ricezione. Gli slave non interessati rimangono semplicemente in ascolto.

Non è la prima volta che vedo una situazione di questo tipo, anche se con protocollo modbus non servirebbe, ma probabilmente è proprio l'hardware che non supporta la modalità a due fili.

[pomat]

ma ad ogni messaggio che il master invia, c'è sempre un messaggio di ritorno dallo slave interessato verso il master, quindi avrai sempre sia trasmissione che ricezione

Direi piuttosto - se ovviamente ogni slave ha un indirizzo diverso come è giusto che sia - che c'è al più una risposta da un singolo slave per ogni richiesta del master, ma proprio perché il protocollo a livello superiore (Modbus) è comunque half duplex, trasmissione e ricezione lato slave (e lato master) non saranno mai contemporanee se la comunicazione avviene correttamente. Tutto questo dovrebbe garantire che non ci siano collisioni sulla linea anche nel caso in cui si mettano in cortocircuito Tx e Rx (ricreando di fatto la condizione della rs485 bifilare). Come ho detto bisognerebbe provare direttamente con un dispositivo reale, il resto sono supposizioni.

[Roberto Gioachin]

Si è vero che sono supposizioni, ma il dubbio viene proprio perchè il costruttore dichiara il prodotto come full duplex.

Da notare che in genere dichiarare full duplex significa dare dei limiti rispetto un half duplex.

Certo che la miglior soluzione è sempre quella di provare, a volte le informazioni sono fuorvianti.

[pomat]

Non sono sicuro sia questo il dispositivo (e vedo diverse porte COM), ma in vari schemi di collegamento di questo manuale Tx e Rx sono raffigurati ponticellati.

A pag. 30 c'è addirittura scritto:

NOTE: Jumper Tx- to Rx- and Tx+ to Rx+ for RS-485 communications

Si direbbe che possa funzionare in entrambi i modi...

Modificato: 12 marzo 2015 da pomat

[sammirati]

pomat, lo strumento è proprio quello. Infatti ho premesso nel primo post che 'da quello che so basta ponticellare tx/rx+ e tx/rx-'. Avevo appunto letto i manuali. Il fatto ha cozzato con i test fatti col convertitore che evidentemente è un 'vero' full duplex quando impostato come 4 fili. La mia preoccupazione deriva anche dal fatto che in una precedente occasione, con lo stesso strumento ed un DCS ABB come master, la comunicazione con i ponticelli ha sì funzionato, ma con molti errori e con una lentezza sconcertante.

Non sono mai riuscito a capire quanto questo fatto fosse influenzato dall'uso del DCS, che non è sicuramente lo strumento più adatto ad una comunicazione seriale così spinta (molti slaves) o dal collegamento 'modificato' rispetto a quanto richiesto dal flow computer.

Comunque questa settimana dovrebbero arrivare in ditta due flow computer dello stesso tipo come spare parts che dovrò portarmi in Iraq quando metterò in servizio la comunicazione in oggetto. Potrò così testare definitivamente la comunicazione a due fili e come si dice a Roma "levasse la sete cor prosciutto'. Vi tengo aggiornati.

Modificato: 16 marzo 2015 da sammirati

[pomat]

Ah, non ce l'avevi detta tutta!

Non sono mai riuscito a capire quanto questo fatto fosse influenzato dall'uso del DCS, che non è sicuramente lo strumento più adatto ad una comunicazione seriale così spinta

Non credo che questo fosse un problema. Quando parli di "lentezza sconcertante", intendi nella lettura del singolo slave o nel monitoraggio globale? Conta che fare un "giro" completo di polling degli slave, se sono parecchi, in certi casi potrebbe impiegare anche dei minuti. In più parli di distanze considerevoli, quindi presumo baud rate relativamente basso...

[sammirati]

La seriale è settata a 9600/8/even/1 con una distanza tra il master e l'ultimo slave di circa 600 mt: stando allo standard 485(anche se lo standard non certifica distanze e baud rate in realtà) potrei alzare a 19200...questo lo vedrò a risultati ottenuti. Ho cominciato a fare i test con i flow computer reali e non c'è nessun problema per la comunicazione a due fili. Sto trovando dei problemi con il master perchè è fin troppo veloce e non da il tempo allo slave di rispondere anche se i nuovi comandi li mando sempre a porta non attiva. Ho verificato il fatto mettendo un piccolo delay tra una chiamata ed un'altra, cosa che ha risolto il problema della collissione/time out. Ora devo concentrarmi sui flag di sistema del FP7 Panasonic per trovare se ce n'è qualcuno ad hoc per 'temporizzare' le chiamate automaticamente.

[pomat]

Ora devo concentrarmi sui flag di sistema del FP7 Panasonic per trovare se ce n'è qualcuno ad hoc per 'temporizzare' le chiamate automaticamente.

Il tempo di timeout è un parametro fondamentale per i protocolli di tipo master-slave e finora l'ho trovato impostabile, entro determinati limiti, in tutti i sistemi hardware e software che ho visto (anche i più economici). Se il Panasonic non dovesse permettere di configurarlo, beh, avrei trovato un PLC da cui stare alla larga!

Modificato: 17 marzo 2015 da pomat

[sammirati]

Il problema non è l'assenza del timeout, che è impostabile anche sul Panasonic FP7 e testandolo da anche il riscontro dei millisecondi impostati. Il problema è il timing tra un comando ed un altro. Forse non mi sono spiegato bene. Esiste un flag di di sistema, che si chiama nello specifico sys_bIsComPort[xx]MasterCommunicationActive, con il quale è possibile monitorare l'attività della porta usata per la comunicazione. I comandi consecutivi li lancio solo se la porta è disattiva. Credo (devo indagare) che non sia sufficiente al master per decratare la definitiva completezza della 'conversazione' con lo slave. Ho potuto riscontrare questa cosa proprio ieri sera sul tardi quando ho provato impostando un timer on delay sullo stesso flag di 200 ms e riscontrando una comunicazione senza problemi. Mi chiedevo, e chiedevo alla comunità, se questa cosa è possibile farla in maniera più elegante di un timer on delay 'utente'.

[pomat]

Ok, ora penso di aver capito. In effetti il nome di quel flag mi suona strano, forse perché per me il master è "attivo" mentre invia la richiesta, e se effettivamente il flag andasse a 0 appena finito di inviare la request, senza un delay nell'invio della richiesta successiva si verificherebbero ovviamente problemi.

I sistemi più "comodi" dal mio punto di vista hanno la logica al contrario: c'è un bit che va a 1 quando il ciclo di richiesta-risposta risulta completato ("done"), eventualmente per intervento del timeout, e quindi il canale è di nuovo libero per una nuova interrogazione. Al bit "done" poi è associato il codice d'errore (es. ok, timeout, bad response, ecc...) relativo all'ultima (o alla specifica) interrogazione, ed eventualmente un bit ausiliario "error" che indica solo la presenza o meno dell'errore.

Ci dovrebbe poi essere un parametro a livello di "porta COM" che stabilisce il delay tra l'invio di un pacchetto e l'altro (con limite superiore proprio di qualche centinaia di millisecondi), ma nel tuo caso potrebbe non risolvere il problema, se lagato alla programmazione del momento in cui richiami la funzione d'invio (che per ora hai risolto almeno in parte con il timer "utente"). L'eleganza è secondaria...

Modificato: 18 marzo 2015 da pomat

[sammirati]

Dopo ricerche, studi sui manuali e contatti con Panasonic sono riuscito a trovare quella soluzione di sistema che stavo cercando. Esiste un parametro per la porta seriale che si chiama 'Tempo di ritardo nell'invio' con un range tra 0 e 100 ms, del tutto simile al parametro ipotizzato da pomat. Questo parametro realizza a sistema più o meno quello che io avevo realizzato con il timer on delay a software utente. Impostato quello tutto ha funzionato a meraviglia. Il classico bit 'done' per il driver modbus non c'è. C'è per altri driver settabili sulle porte seriali del FP7 ma non per il modbus. Ciò che mi portava fuori strada era il fatto che questo parametro di sistema sembrava legato solo al modbus in versione slave e non per il master. Fatto smentito dalla realtà dei fatti.

A questo punto non mi resta di andare in impianto e mettere su la rete reale.

Grazie a tutti per la partecipazione alla discussione.

Modificato: 19 marzo 2015 da sammirati