# Probleme beim Erfassen von Zählimpulsen am Profibus



## maddei (14 April 2008)

Hallo Zusammen,

Ich habe folgendes Problem:

Am Profibusstrang möchte ich an einer ET 200 M Baugruppe an einer Digitaleingangsbaugruppe die Zählimpulse eines Promass 80 von E + H zählen.
Die Zählfrequenz beträgt max. 10 Hz welche sicher erfasst werden soll. Die Zählimpulse sind im Ruhepegel positiv

Andere Daten der Teilnehmer die am Strang hängen:

4 ET 200 M unterschiedlich ausgebaut (mit Dig E/A , Analoge E/A)
7 Festo  Ventilinseln  CPX  FB 13
4 Danfoss FC 300 Umrichter
insgesamt 318 Byte E/A´s
CP 443 - 5 EXT als Master
Die Slaves verteilen sich über ein ganzes Gebäude lange Strecken werden über Siemens OLM´s überbrückt die längste "Kupferstrecke" sind 70m.
Baudrate: 1,5 MBaud
CPU 416 - 2 DP: aktuelle Zykluszeit zwischen 16 - 24 ms
Info: Es gibt noch zwei weitere DP - Stränge einen an der CPU und eine weitere CP 443 - 5 EXT

Verlangsame ich die Impulse auf unter 5 Hz dann kommen alle Impulse
 in der Steuerung an. Am Signalpegel am Eingang der Baugruppe liegt es nicht diesen habe ich schon überprüft.

Es liegt wohl an der Verarbeitungsgeschwingkeit der ET Baugruppe (Dig E - Kartenverzögerung, Rückwandbus) Busumlaufzeit, Programmverarbeitung???

Kann mir jemand helfen wie ich auf die richtigen Zeiten am DP Bus komme bzw. wie sich die größte zu erfassende Frequenz rechnerisch ergeben würde. Bringt es etwas die Baudrate zu erhöhen? Oder die Eingangsbaugruppe durch eine Zählerbaugruppe zu tauschen da würde man dann wenigstens keine Impulse verlieren.

 Leider muss ich feststellen das ich scheinbar vom Profibus DP nur begrenzte Ahnung habe  

Im Programm werden die Zählimpulse im Weckalarm OB über einen Zähler hochgezählt (OB 37 , 20ms). Im OB wird wie folgt programmiert:

U E 11.0 
ZV  30

(müsste man da nicht vorher das Eingangsabbild aktualisieren, damit diese Weckalarm Programmierung hilft) Da die Anlage von einer Fremdfirma programmiert wurde sind mir beim Eingriff im Programm die Hände gebunden bzw. nur mit Absprache der Fa.

Vielen Dank im voraus über mögliche Ansätze, ich denke das ganze wird mich wohl noch ne weile beschäftigen. 

Grüße

Maddei


----------



## marlob (14 April 2008)

Um immer die aktuellsten Eingangsdaten zu haben, muss du das Peripheriebyte/Wort einlesen. Also z.B. 

```
L PEW 10
T MW 10
U M11.0
ZV 30
```


----------



## Larry Laffer (15 April 2008)

Wie hoch ist den die Zykluszeit deines Programms ...?


----------



## marlob (15 April 2008)

Larry Laffer schrieb:


> Wie hoch ist den die Zykluszeit deines Programms ...?


siehe hier


maddei schrieb:


> ...
> CPU 416 - 2 DP: aktuelle Zykluszeit zwischen 16 - 24 ms
> ...


----------



## Larry Laffer (15 April 2008)

@Marlob:
Das hatte ich übersehen.
Dann kommt das Problem aus der Aktualisierung des PB und das wäre mit L PEW dann auch nicht zu verbessern. 318 Byte E/A wollen auch erst mal aktualisiert werden (bei 1,5 MBaud).

Gruß
LL


----------



## vierlagig (15 April 2008)

Larry Laffer schrieb:


> @Marlob:
> Das hatte ich übersehen.
> Dann kommt das Problem aus der Aktualisierung des PB und das wäre mit L PEW dann auch nicht zu verbessern. 318 Byte E/A wollen auch erst mal aktualisiert werden (bei 1,5 MBaud).
> 
> ...



ich glaub ja, es geht nur um den zählimpuls, da könnte der direkte peripherie-zugriff schon was bringen


----------



## Larry Laffer (15 April 2008)

... nicht wenn der PB schon ausgelastet ist (den Takt vorgibt) ...
Ich weiß nicht, wie ich es umschreiben soll.
Ich denke die Umlaufzeit des PB erlaubt keine höhere Abfrage-Rate mehr ...


----------



## marlob (15 April 2008)

Larry Laffer schrieb:


> ... nicht wenn der PB schon ausgelastet ist (den Takt vorgibt) ...
> Ich weiß nicht, wie ich es umschreiben soll.
> Ich denke die Umlaufzeit des PB erlaubt keine höhere Abfrage-Rate mehr ...


das könnte sein, aber ich würde es trotzdem mal mit dem Peripheriewort probieren. Ist auf jeden Fall schneller getestet, als Hardware zu tauschen oder den Bus schneller zu machen.


----------



## crash (15 April 2008)

maddei schrieb:


> Hallo Zusammen,
> 
> Ich habe folgendes Problem:
> 
> ...



Vlt kannst du die ET200M an einen anderen DP-Strang hängen der nicht so "belastet" ist.( weniger Teilnehmer bzw. weniger Datenlast)


----------



## Fritze (15 April 2008)

Hallo.
Ich hatte mal eine ähnliche Aplikation. Sollte etwas dosieren. Ich bin am Ende nicht um eine Zählerbaugruppe herumgekommen, was sich für die Dosierung dann auch als sehr hilfreich erwiesen hat.
MfG Fritze.


----------



## Hoyt (15 April 2008)

Hallo

Ich würde auch als estes den Eingang mit L PEW ... einlesen, und dann nocheinmal testen.

Ich bin mir aber nicht sicher ob das hier bei dieser Situation etwas bring.

Meine ersten Gedanken waren: 
- Bei 10Hz ergibt eine positive Flanke von 50mSek.
- max. Zykluszeit ist 24mSek.
- Das Prozessabbild wird meiner Meinung nach alle 24mSek. aktuallisiert. Dies sollte doch eigentlich ausreichen.

Kann es sein, dass der Profibus mehr Zeit benötigt um alle 318 Bytes zu aktualisieren als ein ganzer SPS Zyklus dauert?
Kann mann die Profibus-DP Aktualisierungszeit irgendwie messen?

Ich frage hier, weil wir die Zählerimpulse auch immer so einlesen. Bis jetzt hatten wir noch keine Probleme, aber es wäre schon gut zu wissen, ob man das irgendwie messen könnte.

Gruss Hoyt


----------



## Gebs (15 April 2008)

Hallo!

Es kann sein, dass die Aktualisierungszeit des PB zu langsam ist, um alle Zählimpulse sehen zu können. 
Da nützt dann leider auch kein L PEW oder eine schnelle Zählbaugruppe.

Die Aktualisierungszeit des PB kann man in der HW-Config sehen:

Doppelclick auf den Profibusstrang
Tablasche "Allgemein" -> Button "Eigenschaften"
Tablasche "Netzeinstellungen" -> Button "Busparameter"

*Ttr_Typisch* ist die Zeit, die benötigt wird um alle Teilnehmer des PB genau einmal anzusprechen. 
Gilt nur, wenn alle TN ok sind, heisst keine Diagnose vorhanden, und wenn kein weiterer TN (z.BSP.: PG) am Bus hängt.

Laut Siemens muss Ttr_Typisch < 1/3 Zykluszeit sein um die Peripherie sicher ansprechen zu können. 
Ich vermute, dass das bei maddei nicht der Fall ist. Mögliche Lösungsansetze:
Baudrate auf dem PB erhöhen, aber dabei die max. erlaubten Längen des PB beachten (sonst Repeater einbauen)
Die ET 200 an einen anderen/neuen PB-Strang hängen, der weniger Last hat.

Grüße
Gebs


----------



## swisscrane (21 April 2009)

Ein counter Modul könnte helfen. 
Dieses erfasst alle Zählimpulse selbständig und legt den wert zum abrufen bereit. 
Dies geht ohne Weckalarm so das der Wert zyklisch gelesen werden kann.
Er geht bis 100 Hz.
Konnte ähnliches Problem mit Profibus und Weckalarm damit lösen. 
Es war jedoch eine ET200 und nicht M bin mir nicht sicher ob es ihn für die M auch gibt. Denke schon.


----------



## knausnice (14 Mai 2009)

Das kannst du so wie es sich anhört nur mit einem Hi Speed Counter lösen. Für diesen anwendungsfall gibt es extra Baugruppen. Deine Zeit mit der dein Busläuft kannst du mit entsprechenden Messgeräten messen. Der Bus sollte ca. 3mal so schnell wie die Zykluszeit deines Masters sein. 
Hast du denn nicht möglichkeit deinen Durchflussmesser am Profibus direkt anzuschließen??

Gruß knausnice


----------



## crash (14 Mai 2009)

Schon mal aufs Datum gesehen?
Der Thread ist ein Jahr alt.


----------



## knausnice (15 Mai 2009)

crash schrieb:


> Schon mal aufs Datum gesehen?
> Der Thread ist ein Jahr alt.


 
Das ist doch egal!! Evtl. gibt es immer mal wieder jemanden der das gleiche Problem hat und ist dann froh das er was nachlesen kann... oder??


----------

