Multimasters Dp - Comunicazione tra maestri intelligenti

[LaRocca]

Ciao a tutti,

Voleva sapere come potere fare una comunicazione tra maestri intelligenti, che possono comunicare direttamente tra di loro, quando stanno in sistemi maestri distinti, ma tutti sotto la stessa rete profibus tale e come mostro nella figura. Non posso allegare non so quale é la loro dimensione máxima.

Iin realtà è possibile configurarlo nel Net Pro del simatic ma non mi appare l'accoppiamento di rete nella configurazione di HW. D'altra parte non voglio utilizzare il DP-DP coupler Siemens, bensì lo stesso porto DP della CPU, secondo l'aiuto dell'amministratore Simatic dice questo:

Vari sistemi maestro DP in una solo subred fisico PROFIBUS-DP si denomina anche sistema multimaestro. In questa configurazione, il maestro DP di un altro sistema maestro DP della stesso subred fisico PROFIBUS-DP può leggere direttamente i dati di entrata di schiave DP intelligenti o di schiave DP semplici. Anche questo meccanismo si denomina shared input (entrata condivisa), dato che i dati di entrata possono essere utilizzati per tutto il sistema di maestro DP.

Un schiavo DP intelligente come p. es. una CPU 315-2DP, si può fare inviare dati di entrata per schiave DP semplici e per distinti sistemi maestro DP, cioè, direttamente alla sua area di dati di entrata.

Inizialmente tutte le schiave DP semplici (a partire di una versione determinata) possono mettere dati di entrata a disposizione per la comunicazione diretta (DX) tra schiavo DP. Questi dati di entrata possono essere solo riutilizzati per schiave DP intelligenti come la CPU 315-2DP.

In sostanza questo elemento verrebbe visto dai due master come uno slave che copia gli n. byte in uscita da un master su n. byte in ingresso all'altro e viceversa.

Spero che la mia domanda é stata lo piú chiara possibile,

1000 Grazie a le risposti.

Saluti

Tony La Rocca

[LaRocca]

Questa é la imagine:

[LaRocca]

Non posso allegare non so quale é la loro dimensione máxima. (15Kb) é possibile??

mi dice: Lo spazio totale necessario per caricare tutti i files allegati è maggiore di quello che ti è consentito utilizzare per ogni singolo messaggio o di quello totale. Perfavore diminuisci il numero di allegati o la loro dimensione.

Ho riddotto la loro dimensione a 7Kb é neanche si puo allegare, cosa sucede?

Ho domandato al aministratore ma no mi ha datto risposta di cuello che ho domandato, prego dirmi cosa fare, perche nel fianco non appare???

[p.valli]

se non vuoi impostarli nel net pro, e non hai la necessità di scambiare molti dati, potresti utilizzare le funzioni da SFC65 a SFC69 che sono le funzioni di X_SEND , X_RCV, X_GET, X_PUT, X_ABORT che permettono l'interscambio di dati tra PLC (anche Master) sulla stessa rete Profbus-DP senza necessariamente averli definiti nel Net-Pro del tuo progetto.

X_SEND necessita che nel Partner di comuncazione vi sia implementato le rispettive struzioni d X_RCV.

X_GET e X_PUT invece necessitano invece solo l'nterrogazione d zone presenti nel partner di comunicazione.

Sicuramente se consulti gli . di queste funzion, saranno molto più esplicative della mia succinta spegazione.

Saluti

PAX

[LaRocca]

Ciao, Proveró quello che dice tu...

Allego comunque la imagine

[Betù]

CIAO LA ROCCA,

PENSO CHE IL CONSIGLIO CHE TI HANNO DATO DI USARE LE SFC STANDARD SENZA CONFIGURARE I COLLEGAMENTI SIA L'UNICA STRADA PERCORRIBILE INFATTI PENSO NON SIA POSSIBILE CON UNA RETE PROFIBUS DP CREARE DEI COLLEGAMENTI IN NETPRO A MENO CHE NON HAI NEI PLC MONTATA UN CP PROFIBUS...

INFATTI PROVANDO A CREARE UN PROGETTO CON DUE PLC(S7-300) E UNA RETE DP CON ANCHE DEGLI SLAVE TIPO ET200 NON VIENE PERMESSO DA NETPRO CREARE DEI COLLEGAMENTI.

IN VARI IMPIANTI HO AVVIATO RETI PROFIBUS FDL CON PLC S7-300 E S7-400 CON CP PROFIBUS...IN QUESTO CASO IN NETPRO PER OGNI PLC SI CREA UNO O PIU COLLEGAMENTI E POI SI COMUNICA CON AG_SEND E AG_RECEIVE STANDARD DI SIEMENS.

P.S. DE DONDE ERES DE MARACAY ?

MI ESPOSA ES DE ALLI Y YO HE VIVIDO Y TRABAJADO 5 ANOS A MARACAY...

[Mario Lavezzi]

Ciao a dire la verita' metterei da parte il NetPro e gestirei la comunicazione a mani libere, come dire..... non e' bello vedere meta' delle comunicazioni gestite

in un modo e meta' nell'altro. Comunque le funzioni Xget Xput funzionano benissimo a parte di gestire la sequenza delle iterazioni tra i vari Device.

occhio alle risorse anche se come vedo dal disegno non dovrebbero esserci problemi.

[p.valli]

Graze Mario per il conforto sull'uso di X_GET e X_PUT.

M confermi il fatto che se devo scambare dati con più partner devo comunque sequenzializzare tale comunicazione? o posso avviare più struzioni di X_GET e X_PUT contemporaneamente? (considera che devo pacchetti di circa 10 word a volta)

Grazie della consulenza.

Paolo

[TALPIN]

Ciao a tutti

ho utilizzato queste funzioni sena grossi problemi in reti di plc anche estese (sia in termini di distanze che in termini di numero di plc collegati fra loro).

L'unica differenza è che le informazioni le ho scambiate in rete MPI, non in rete Profibus; infatti dal manuale della funzione SFC 67 "X_GET" si legge:

"DEST_ID Parametro di indirizzamento "destination ID". Contiene l'indirizzo MPI del partner di comunicazione. Esso è stato progettato con STEP 7."

Qualcuno può spiegarmi come utilizzarle in rete Profibus?

Grazie

Valter

[p.valli]

Teoricamente nel medesimo modo n cui l'ha utilizzato per reti MPI (dove però l'ndirizzo DP sarà quello della porta DP del tuo partner di comunicazione, e che avrai definto nella configurazone hardware del partner stesso).

Mi sorge però un'altro emblematico questito:

ma se ho un PLC con 2 porte DP (e qundi due differenti reti profbus) e all'interno delle sngole reti esiste un partner con l medesimo indirizzo DP (possono coesistere in quanto su reti differenti), come faccio a specificare nella funzione X_GET con quale dei partner voglio comuncare?

Ai posteri larga sentenza....

Ciao

PAX

[Matteo Montanari]

ma se ho un PLC con 2 porte DP (e qundi due differenti reti profbus) e all'interno delle sngole reti esiste un partner con l medesimo indirizzo DP (possono coesistere in quanto su reti differenti), come faccio a specificare nella funzione X_GET con quale dei partner voglio comuncare?

comunichi con il partner presente nella rete a cui sei connesso, il numero del nodo unico solo per quella rete, in una rete diversa puoi avere lo stesso numero ma non hai accesso ai dati in quanto sei "fisicamente" scollegato dalla rete.

[p.valli]

Ciao Matteo,

non ho ben capito quanto tu mi ha specificato. nfatti nella ma applicazione ho una S7-414 2DP ed entrambe le porte sono utilizzate per comuncare su 2 differenti reti profibus-dp.. qund come faccio a defnre su quale rete stò comuncando, che le uso entrambe?

Grazie comunque de preziosi chiarimenti.

PAX

[Matteo Montanari]

non sò come è fatta la tua applicazione, io, anche se ho a disposizione due reti profubus distine, non metto mai lo stesso indirizzo, proprio per impedire questo inconveniente. Anche perchè è difficile occupare tutti gli indirizzi a disposizione.

comunque è un ottima osservazione, prova a richiedere qualcosa anche nel servizio di supporto siemens, e sentire come sbrogliano la matassa.

[TALPIN]

Ciao,

per p.valli: ma se utilizzo entrambi le reti (sia MPI che Profibus)?

Nei nostri impianti utilizziamo MPI per scambiare dati con GD e collegamento pannelli operatori, la rete Profibus per remoti e per supervisione con PC.

Ho descritto in un mio precedente post un metodo che ho utilizzato per scambiare pacchetti molto lunghi di dati con le sfc in questione, ma sempre in rete MPI. Mi farebbe molto comodo implementare la stessa cosa in rete Profibus.

Saluti

[rimonta]

scusatemi l'ignoranza, ma ad un corso siemens mi sembrava fosse stato deto che su una rete profibus non potevano coesistere più di un master, e che per farli dialogare tra loro serviva un dp-dp coupler. Forse ho capito male io???

[LaRocca]

Ciao a tutti,

Voglio pensare che se si può fare una rete multimaestro, in realtà è possibile configurarlo nella NETPro tale e come mostro nella figura, orbene, anche S7 definisce le applicazioni multimaestros e le comunicazioni come quelle ho mostrato nella figura anteriore, per ciò dice che usi le configurazioni S7, di unione non configurati.

Logicamente, per le comunicazioni tra PLC´s interesserà utilizzare Profibús FDL,

che non consuma risorse, mentre per la comunicazione tra PLC´s e computer od OP in Profibus multimaestro sarà interessante utilizzare il protocollo Funzioni S7, già sia per MPI o per Profibús, poiché gestirà tutte le comunicazioni in maniera trasparente per noi dalla squadra di visualizzazione, nonostante consumiamo una risorsa o unione.

Nelle librerie di S7 COM_FUNC esistono vari blocchi di programmi, sto valutando come di essi è il meglio per lo scambio di dati mediante comunicazione diretta DX tale e come dice l'aiuto.

Il protocollo di funzioni S7 è l'ideale per comunicare squadre Simatic S7 tra

essi, poiché essendo implementato nel sistema dei biglietti, unicamente è necessario

stabilire l'unione tra la squadra che si desidera comunicare con suo rispettivo e che

informazione è necessaria condividere.

Un'unione di funzioni S7 determina in due una relazione univoca squadre per

comunicare l'informazione tra essi. Queste unioni di S7 possono essere di due tipi:

• Unioni configurate: si stabiliscono trasferendo i dati di sistema, e sono fissi.

• Allacci non configurati: si stabiliscono richiamando la CPU ad una SFC del sistema

che realizza l'unione tra squadre. Detta unione non è fissa, per quello che un'altra chiamata

alla SFC con differente squadra destino può disfarlo e generare uno nuovo con

un'altra squadra. Il volume massimo dei dati a trasmettere mediante questo metodo è

di 76 byti. È importante emergere che benché non sia configurato, questo metodo

spende un'unione libera, nonostante suoli si usi in maniera temporanea.

Evidentemente la cosa più comoda sarebbe stabilire unioni configurate tra squadre

S7 nel momento di proiettare l'installazione, poiché non richiedono programmazione addizionale in lui

che si considera propriamente il programma di PLC (assenza di chiamate a sottopragrammi).

Se sequestro, le CPU's di S7 ha limitati il numero di unioni configurate per no

sovraccaricare con le comunicazioni il microprocessore del PLC e permettergli di realizzare quello

codice contenuto nelle differenti OB's, FC's e FB's del programma in una volta di ciclo

sufficientemente rapido. Per quello che sto vedendo come allacci non configurato si adatta meglio alla comunicazione tra maestri e schiavi di distinti ambienti sotto la stessa rete Profibus.

Ringrazio per essi molto potere valutare detta rete, poiché sarebbe interessante per ribassare costi

______________________________________

Para Betú: Soy de La Victoria, a 30 min de Maracay

[LaRocca]

La comunicazione PROFIBUS non è una rete orientata alla comunicazione di unioni coi moduli X-PUT / X-GET, bensì alla comunicazione di dati utili attraverso DP normale.

I moduli X-PUT / X-GET assolo possono utilizzarsi in una rete MPI, ma per un bonifico di dati più rapido, bisogna utilizzare una rete PROFIBUS invece di una rete MPI.

Il problema è quando si vuole fare una rete Multimaster con vari schiavi intelligenti tale e come ho commentato. Configurazione con due sistemi maestro DP (comunicazione diretto schiavo> schiavo I) o Configurazione con due sistemi maestro DP (comunicazione diretto schiavo> maestro).

Nell'aiuto del S7 appare (sistemi Multimaster), ma non dice come può effettuarsi. Ho fatto prove e non riesco a dare con la soluzione a questo punto interrogativo.

[p.valli]

Devo fare ammenda...

parlando con Hot-line Siemens, m è stato confermato che le SFC X_SEND e X_GET (scambio dati senza specificare il destinatario) è possibile utilizzarlo solo su reti MPI e non su reti profbus, nè di tipo TCP-IP.

A chi potesse essere utile, lascio detto che se la comunicazione avviene tra S7-400 verso S7-300 è possibile utilizzare le funzioni GET e PUT con "destinatario" sconosciuto (questo sgnfica che nel proprio progetto non è necessario definire i plc s7-300): devo anche precisare che nel mio caso le s7-300 sono munte di CP342-5.

Scusate le imperfezioni dei mie precedenti messaggi.

Saluti

PAX

[TALPIN]

Ciao p.valli,

grazie per le info date. Ero già a conoscenza di quanto comunicato da Siemens, ma speravo che ci fosse una possibilità, non nota, di potere utilizzare le funzioni in questione anche in Profibus, magari utilizzando codici differenti.

In profibus sono riuscito a comunicare tra cpu solo dichiarandone una master e tutte le altre slave (collegamenti progettati): nasce un problemino evidente se le cpu che devono diventare slave necessitano di unità remote in profibus...

ciao

Valter

[rimonta]

quindi serve il dp_dp coupler come avevo capito io per mettere in comunicazione due master in profibus?

[LaRocca]

Qui pubblico le conclusioni delle prove realizzate su sistemi Multimaestros, per se altri a futuro devono consultare.

Dipendendo dalle funzioni di comunicazione elette, si usano unioni configurate (comunicazione ampliata) o non configurati (comunicazione basilare).

Comunicazione Basilare Con questi servizi di comunicazione, possono trasmettersi dati per tutti i CPUs S7-300/400 per mezzo della subred MPI o dentro una squadra attraverso l'autobus K. Le funzioni del sistema (SFCs), tali come X_SEND nel lato dell'emittente, e X_RCV nel lato del recettore, sono chiamato nel programma di utente. La quantità di dati di utente che possono trasmettersi in una chiamata è di un massimo di 76 byti.

Si delinea attivamente un'unione con l'interlocutore della comunicazione quando si richiama alle funzioni del sistema e questo si stacca dopo la trasmissione. Non è necessario un'unione configurata per esto.Enlaces non configurato, Queste unioni si delineano quando si richiama alla funzione di comunicazione e sono staccati dopo essersi completato la trasmissione di dati, se è necessario.

Comunicazione Ampliata può usare questi servizi di comunicazione per tutte le CPUs S7-400 é alcuni CPU S7-300. Possono trasmettersi dati fino ad un massimo di 64KBytes per mezzo di vario subredes (MPI, Autobus K, Profibus, ed Ethernet Industriale). Per cuanto riguarda a questo, si devi vedere sul NetPro é fare clic sopra una CPU é vedere se si puó fare un link (S7, PtP, S7 +disposizione) unioni di comunicazione.

I blocchi di funzione del sistema (SFBs) si usano come l'interfase di programmazione. Questi SFBs è integrati nel sistema operativo delle CPUs S7-400 é anche questi esistono su alcuni CPU S7-300 (nuovi versioni).

Oltre alle funzioni per la trasmissione di dati, anche questi servizi di comunicazione contengono funzioni di controllo tali come START e STOP del PLC interlocutore.La comunicazione ha luogo attraverso unioni configurate (tavola di unioni). Queste unioni si delineano durante l'avviamento della squadra e continuano esistendo permanentemente.

Questo tipo di unione si delinea con STEP 7. Alla posizione finale delle unioni gli è assegnato un Andate locale che, tra le altre cose, identifica l'informazione della sua propria direzione e quella dell'interlocutore della comunicazione.

Le unioni di comunicazione, si richiedono purché nel programma di utente sia preciso scambiare dati attraverso determinati blocchi di comunicazione (SFBs, FBs o FCs). Nelle unioni S7 attraverso un'interfaccia MPI/PROFIBUS-DP integrato, nella CPU si occupa una risorsa di unione per il punto finale per ogni allacci S7. Orbene, nel mio esempio con mutimasters, devono usare i SFBs comunicazioni che ha una trasmissione di dati sicura usando unioni S7. La configurazione di queste unioni si realizza con l'aiuto dell'attrezzo NetPro (configurare reti) che sta connessa in maniera trasparente nell'Amministratore SIMATIC.

La comunicazione è solo possibile tra squadre di un progetto S7, almeno che se fa un link S7 non specificato. Le unioni S7 non specificato si usa quando il partner di comunicazione non è disponibile nello stesso progetto di STEP 7.

Gli interlocutori della comunicazione devono essere connessi in una subred MPI, PROFIBUS o Ethernet Industriale comune. Per la comunicazione devono delinearsi unioni. Il numero di unione socio (Numero di Identificazione) fa riferimento all'assegnazione del nodo ed al mezzo di trasmissione. Questi Numeri di Identificazione sono passati come il parametro di blocco Andate per una chiamata al SFB.

Il volume dei dati di utente dipende dal blocco usato e dell'interlocutore della comunicazione:

• PUT/GET 160 byti per il S7-300 e 400 byti per il S7-400/M7

• USEND/UREC fino a 440 byti

• BSEND/BRCV fino a 64KBytes

GLI SFBs per comunicazione S7 è integrati come blocchi di funzione del sistema (SFBs) nel sistema operativo della CPU S7-400. Il S7-300 non contiene SFBs per la comunicazione ampliata. Tuttavia, il sistema operativo della CPU S7-300 sopporta la funzionalità di servitore dei servizi di comunicazione S7 unilaterali. Così, per esempio, i dati di una CPU 3xx possono essere letti o scritti per una CPU 4xx con l'aiuto dei blocchi GET e PUT. In questo maniera assolo c'è comunicazione di forma Unilaterale, cioè in un assolo senso.

Di un S7-400 ad un S7-300, si stabiliscono automaticamente allaccia S7

Unilaterali per l'attrezzo di configurazione. Per le unioni unilaterali si assegna un Andate locale dell'unione per l'identificazione dell'unione, cioè, l'interlocutore della comunicazione ed il mezzo di trasmissione, solamente nel lato del S7-400 (lato del Cliente).

Nel lato del S7-300 non si assegna Andate dell'unione poiché i SFBs per indirizzare l'unione della comunicazione non si trova nel sistema operativo della CPU S7-300.

Possono chiamarsi solo servizi di comunicazione unilaterali mediante unioni unilaterali. È solo necessaria una chiamata alla SFB corrispondente nel lato del Cliente (S7-400) per i servizi di comunicazione unilaterali. Nell'altro interlocutore della comunicazione (Servitore), si destreggia completamente il servizio per il sistema operativo. Non è necessario nessun lavoro di programmazione per l'utente nel lato del servitore.

Si delineano sempre unioni S7 unilaterali per il cliente durante l'avviamento.

Con servizi di comunicazione unilaterali, il programma di utente nel lato del servitore non è informato quando si siano trasmessi nuovi dati. L'unica forma di fare unioni bidirezionali è attraverso due equipor 400 nella rete, di un altro forma assolo c'è una forma di comunicazione unidirezionale.

In caso di utilizzare i SFBs BSEND/BRCV: bonifico sicuro di dati tra squadre SIMATIC S7/M7-400; p. es. scambio del contenuto di blocchi di dati (fino a 64kbytes)

In caso di utilizzare i SFBs USEND/URCV: bonifico rapido e non assicurata di dati, indipendentemente del trattamento dell'interlocutore; p. es. per avvisi di servizio e mantenimento.

Segue....

[LaRocca]

Ciao a tutti

D'altra parte, un DP-master nel sistema multimaestro può leggere i dati di entrata di un schiavo DP non configurato per lui, per mezzo della configurazione dello scambio diretto di dati. Per ciò, entrambi i DP-master deve essere disponibili come sistema multimaestro nella stessa rete PROFIBUS-DP, cioè che deve essere presente nella NetPro del progetto.

Nello scambio diretto di dati, entrambi i DP-master deve sopportare la capacità di invio ed accoglienza di dati diretti, e lo schiavo DP deve sopportare la capacità di invio di dati diretti. Questa proprietà può vedersi nell'informazione del modulo del DP-master e lo schiavo DP, mostrata nella configurazione HW del STEP 7 (giusto nella finestra sotto il catalogo HW).

Se si apre un progetto, e si tiene un schiavo 1.1 innesto al Maestro 1 per esempio, il maestro 2 disponibile nella stessa rete PROFIBUS-DP legge i dati di entrata dei moduli di entrata di l schiavo 1.1 per mezzo dello scambio diretto di dati. Per ciò nel HW del maestro 2 deve darsi doppio clic sul DP ed aggregare questa unione come una comunicazione diretta. Apra le proprietà dell'interfase DP e scelga la registro Configurazione. Inserisca una nuova fila che Lei parametriza nel modo DX (per lo scambio diretto di dati). Realizzare la configurazione della fila DX, nella quale si indica la direzione DP dello schiavo e la direzione di entrata dei dati

rilevanti.

Aspetto questo argumento serva da aiuto ad altri, se qualcuno a unaltro di dire su questa discuzione sarebbe di molto aiuto