# Limit von Profibus



## michdan (28 Januar 2006)

hallo

Habe einige fragen wegen profibus am Siemens S7-400 und deren daten belastung:

1) Gibt es eine grenze/maximale datenmenge die ich auf dem profibus haben kann ??
Wenn ich zum beispiel die maximale anzhl teilnehmer (63) auf dem profibus habe, wie viele/grösse daten kann jeder teilnehmer dann das netzwerk belasten ?

2) Wie sieht es mit der responze zeit aus von telegrammen ??  Wie kann ich diese berechnen ?

gruss
michael


----------



## Rainer Hönle (28 Januar 2006)

michdan schrieb:
			
		

> 1) Gibt es eine grenze/maximale datenmenge die ich auf dem profibus haben kann ??
> Wenn ich zum beispiel die maximale anzhl teilnehmer (63) auf dem profibus habe, wie viele/grösse daten kann jeder teilnehmer dann das netzwerk belasten ?


Pro Segment sind maximal 32 Teilnehmer zulässig, danach muss ein Repeater zur Segmentierung verwendet werden. Die maximale Teilnehmerzahl an einem Bus ist 126 wobei die Adresse 126 eine spezielle Bedeutung hat (default Slave Adresse wenn uninitialisiert). Die Länge der einzelnen Segmente ist auch limitiert und hängt von der Busgeschwindigkeit ab.
Die Größe der Daten je Slave bzw. insgesamt sind in der technischen Beschreibung im Siemenskatalog (auch online verfügbar) enthalten. 
Als Beispiel für die 416-2:
Adressbereich
Eingänge max. 2 KByte
Ausgänge max. 2 KByte
Nutzdaten je Slave
Eingänge max. 244 Byte
Ausgänge max. 244 Byte
Baugruppen wie die 443-5 ext. haben einen Adressbereich von jeweils 4 KByte. Im Bedarfsfalle können bis zu 10 dieser Baugruppen in ein Zentralrack gesteckt werden.


----------



## michdan (28 Januar 2006)

hallo

Heisst das wenn ich mehr als 32 teilnehmer habe, mus ich es segmentieren und repeater benutzen ??

Kan jeder slave dann max 244 bytes telegramme verschicken und emfangen und das netzwerk maximal total 2kbyte (CPU 416-2) ?

zum beispiel ich habe 8 slaves die maximale telegramme von 244 byte verschicken das ist das netzwerk voll ?!? (8x244 =1952 bytes) 

Hast du eine genauere angabe von den online Siemenskatalog wo al das beschieben ist ??

gruss
michael


----------



## Rainer Hönle (28 Januar 2006)

michdan schrieb:
			
		

> Heisst das wenn ich mehr als 32 teilnehmer habe, mus ich es segmentieren und repeater benutzen ??


Ja, entweder Repeater (günstiger) oder zusätzlichen DP-Strang (teurer, leistungsfähiger, ggf. sowieso notwendig, s.u.).



> Kan jeder slave dann max 244 bytes telegramme verschicken und emfangen und das netzwerk maximal total 2kbyte (CPU 416-2) ?


Dies ist slaveabhängig. In der Spec schauen.



> zum beispiel ich habe 8 slaves die maximale telegramme von 244 byte verschicken das ist das netzwerk voll ?!? (8x244 =1952 bytes)


So würde ich die Siemensaussage interpretieren. Deshalb auch die Möglichkeit, weitere DP-Baugruppen zu stecken. Hat wirklich jeder Slave 244 Byte Ein-/Ausgangsdaten? Das wären z.B. über 60 DI/DO mit jeweils 32 Bit oder 15 AI/AO mit jeweils 8 Kanälen!



> Hast du eine genauere angabe von den online Siemenskatalog wo al das beschieben ist ??


ja: https://mall.automation.siemens.com/DE/guest/index.asp?aktPrim=0&lang=de


----------



## michdan (30 Januar 2006)

ich bedanke mich für die antwort...

Weiss jemand noch wie man die Buszyklus zeit berechnen kann ??


----------



## nairolf (5 Februar 2006)

Soweit ich weiß kann das in der HW-Konfig von Step7 gemacht werden:
HW-Konfig öffnen -> Doppelklick auf DP-Interface -> Eigenschaften
-> Reiter Parameter -> Eigenschaften -> Netzeinstellungen ->
dann durch Optionen und/oder Busparameter hangeln (Hilfe konsultieren 
Falls Repater o.ä. dran hängen im Reiter Leitungen alle bekannten Infos angeben !

Hatte für lichtschrankengesteuerte hochexakte Teile-Ausrichtvorgänge mit DP-Servos (Indramat) den äquidistanten Profibuszyklus aktiviert
und da konnte man alle Zeitparameter "manipulieren".
Da gabs ne Schaltfläche "berechnen" oder so. Vieleicht hilfts


----------



## JOEPRO (22 Februar 2006)

*Buszeitenberechnung*

hallo michdran,

 die Profibuszeiten werden wie folgt berechnet :


t cycle_DP = (Tsyn + TID + TSDR + Telegram overhead + I/O data time)

t cycle_DP = (( 33 + 75 + 11 + 2 * 9 * 11) * S + 11 * D) * Tbit


	t Cycle_DP = Tbit x n x 500 + 11 x Tbit x D

             Tsyn = typische Werte = 33 exakter Wert aus der  
                                                    Bedienungsanleitung entnehmen
             TID   = typische Werte = 75 exakter aus dern 
                                                    Bedienungsanleitung entnehmen

             N = Anzahl aller PROFIBUS Slaves (DP+PA)
             D = Summe aller I/O Bytes (DP+PA)
          Tbit = Bit time = 1/ transfer rate (bit/sec)

Auf der Webside von Siemens oder P&F gibt es ein Tool zur Berechnung der Zykluszeit.
see you Josefo


----------



## DieBoese0815 (20 Juni 2018)

Hallo,

ich vermisse jetzt aber hier noch eine Antwort auf die Frage wie hoch die Anzahl der Parameterdaten pro ProfiBus-Teilnehmer ist?

Mit anderen Worten, wenn ich an ein IM E/A's anbinde, dann können hier max. 244 Adressbytes vergeben werden (jeweils für E & A). Baut man aber nun eine HW-Konfiguration mit Analogomodulen auf kommt man da schon schneller an die Fehlermeldung einer inkonsistenten Kofiguration weil ja die Parameterdatengröße und nicht die Adressdatengröße gezählt wird, obwohl ich im E/A Bereich noch lange nicht die 244 Bytes erreicht habe.


----------



## Aunex (21 Juni 2018)

Hallo.
Die SPS sendet max. 244 Byte "reine zyklische Daten" an den Teilnehmer und bekommt max. 244 Byte zurück (PB Norm). Zusätzlich hat das PB-Telegramm noch einen Header für Adressierung etc. und am Ende die Prüfsumme. Für die Parametrierung und Konfiguration der Teilnehmer in der Hochlaufphase werden natürlich andere Telegramme verwendet.

  Wenn du jetzt eine Baugruppe mit Modulen bestückst, können (theoretisch) in Summe 244 Byte Ausgänge und 244 Byte Eingänge adressiert werden. Oft wir das aber in der HW-Config durch den Hersteller via GSD limitiert, so auch in der IM. Das hat dann nichts mit dem PB Telegramm zu tun, sondern der internen Datenstruktur und Verarbeitung der Baugruppe. Die HW-Config sollte es auch nicht zulassen, dass man zu viele Module o.ä. steckt.


----------

