Step 7 Istgeschwindigkeit aus FM-450

Zuviel Werbung?
-> Hier kostenlos registrieren
Du verwechselt da was, aber kann ich nachvollziehen. Nochmals zur Verdeutlichung: Ich habe 2 Geber. Der eine mit 4000 auf den sich auch die Listen beziehen und einen mit 1000. Der mit 1000 hängt an der FM450 und wie gesagt, ist mit dem nach anfänglicher falscher Annahme alles i.O. Der Kanal A bei diesem Geber ist "gesplittet" und dann geht ein Kabel an die FM450 und eins an die IP241 der S5. Bei dem Geber findet auch nur die einfach Auswertung statt.

Die Listen und die Impulsdifferenzhalbierung alle 250ms bezieht sich auf den Geber an der FM350, welcher 4000 IMP pro Umdrehung hat durch 4-fach Auswertung. Sollte dir / euch noch was unklar sein, frag nach. Ich kann verstehen, dass es sehr verwirrend geworden ist.
 
Dein Problem besteht also bei der FM350-1?
Steckt die im zentralen Rack der CPU 31x? Dann hat der Profibus-Zyklus keinen Einfluß auf das Auslesen des Zählerstandes. Steckt die FM350-1 in einer dezentralen Station (z.B. ET200M)? Dann hat der Profibus-Zyklus einen gewissen Einfluß (Jitter) auf das Auslesen des Zählerstandes - der muß sich dann aber aufheben, also mal 100 Impulse zu wenig bringen dann beim nächsten Auslesen 100 Impulse mehr.

Bei der FM350-1 mußt Du den FC CNT_CTL1 aus der FMx50LIB verwenden (FC2, V3.0, Größe 894 Bytes im Arbeitspeicher). (der FC0 CNT_CTRL ist nur für die FM450-1)

Deine FM350-1 ist die 6ES7350-1AH03-0AE0?
Für diese Baugruppe gibt es ein Firmware-Update V1.0.3


Sprünge beim Zählkanal auf der FM450-1: Du kannst die Parametrierung des Zählkanals auf 4-fach-Auswertung umstellen, dann sollten die Sprünge etwas kleiner werden.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dann hat der Profibus-Zyklus einen gewissen Einfluß (Jitter) auf das Auslesen des Zählerstandes - der muß sich dann aber aufheben, also mal 100 Impulse zu wenig bringen dann beim nächsten Auslesen 100 Impulse mehr.
Das hatte ich anfangs auch gedacht und deshalb die Idee, dass es am ProfiBus liegen könnte, wieder verworfen bzw. zurückgestellt.
Die DifferenzenListen zeigen nicht: eine MessPeriode x Impulse zuwenig und dann nächste Periode x Impulse zuviel.
Sondern: n Perioden mit x Impulsen und dann 1 Periode mit x/2 Impulsen.
Daraus schliesse ich, dass das Auslesen des ZählerStandes in einem Raster von ca. 28 ms geschieht bzw. geschehen kann.
Die n Auslesungen zeigen Werte im Abstand von ca. 56 ms, dann kommt ein Wert im Abstand von 28 ms zum vorhergehenden, u.s.w. . . .
Raster.jpg
Ob der Wert von 28 ms beim ProfiBus irgendeine Relevanz hat? Keine Ahnung ;o(
 
Zuletzt bearbeitet:
Hallo,

ja sie hängt in ET200 im Feld nicht unweit vom Geber und ist über Profibus mit der S7 verbunden und wenn ich in der Bibliothek FMx50LIB gucke dann steht bei

FC0 CNT_CTRL

fc0.jpg

und bei FC2 CNT_CTL1
fc2.jpg
daher gehe ich davon aus, dass man beide FCs benutzen kann unabhängig der FM und nur wenn man isochrone brauch / will den CNT_CTL1.

Ich hab meine FM inzwischen mit beiden FCs und den zugehörigen UDTs getestet und betreibe sie aktuell auch mit CNT_CTL1 und bei beiden hab ich den Effekt. Aber jetzt kommts! Mir wurde inzwischen mitgeteilt, dass dem Elektriker (der von meinen Problemen gehört hat) wohl rausgerutscht ist, dass ihm der Geber beim Einbauen runtergefallen ist - auf Betonboden -.-. Jetzt gehe ich im Moment ganz stark davon aus, dass eventuell von der Strichcodescheibe was abgebrochen ist. Allerdings wenn das so wäre - müsste ich den Fehler alle 4000 Impulse einmal haben oder? Und nicht alle 250ms. Jedenfalls wird der Geber am Montag erstmal gewechselt nur um sicher zu gehen.

Ich habe gerade mal Taktsynchronität bei Siemens nachgeguckt und bin dabei auf das gestossen:
takt.jpg

in https://cache.industry.siemens.com/dl/files/505/14040505/att_47222/v1/ts_de.pdf

Das klingt ja fast schon als ob man das für den Fall echt bräuchte bei dezentraler Peripherie.

Ich hab mal die Eigenschaften meines Profibus aufgemacht, da ist eine Zeit bei die zumindest nahe an deinen 28ms liegt:

wbs_profibus.jpg

Ja meine FM ist eine 6ES7350-1AH03-0AE0 - Firmware 1.0.3 ist installiert.
 
Zuletzt bearbeitet:
Neben Deinem Bildchen aus der Beschreibung steht:
"Zu dem projektierten Zeitpunkt Ti werden alle Eingangssignale gleichzeitig "eingefroren". Die Daten werden an den Slave (z.B. Interfacemodul IM 153) übertragen und dem PROFIBUS zur Verfügung gestellt (In)."
Wenn dieses "Einfrieren" alle ~28 ms stattfindet, dann könnte ich mir damit das 28-ms-Phänomen erklären!

PS:
Da steht etwas von "(Systemtakt = 32 ms)" - ist ja nicht wahnsinnig weit von 28 ms entfernt!?

PPS:
Und die 29,7 ms aus Deinem ScreenShot sind noch näher dran.
Aber was soll man denn jetzt glauben???
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich werd verrückt in dem Dokument ist fast sogar mein Fall drin auf Seite 5. Da steht sogar dezentrale Drehzahlmessung über Zählerdifferenzen ohne Taktsynchro haben Abweichungen bis zu 10% und mit Taktsynchro nur 0,1 %.
 
Neben Deinem Bildchen aus der Beschreibung steht:
"Zu dem projektierten Zeitpunkt Ti werden alle Eingangssignale gleichzeitig "eingefroren". Die Daten werden an den Slave (z.B. Interfacemodul IM 153) übertragen und dem PROFIBUS zur Verfügung gestellt (In)."
Wenn dieses "Einfrieren" alle ~28 ms stattfindet, dann könnte ich mir damit das 28-ms-Phänomen erklären!

PS:
Da steht etwas von "(Systemtakt = 32 ms)" - ist ja nicht wahnsinnig weit von 28 ms entfernt!?

PPS:
Und die 29,7 ms aus Deinem ScreenShot sind noch näher dran.
Aber was soll man denn jetzt glauben???

Ich glaube mit 32ms Systemtakt meinen die einfach die Zykluszeit ihrer Test-SPS da.
 
Zähler FM 350-1 (1-kanaliger Zähler) 6ES7 350-1AH03-.... (in Vorbereitung) !?
Na ja, Stand November 2002 - also nicht hoffnungslos!
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn ich in der Bibliothek FMx50LIB gucke dann steht bei

FC0 CNT_CTRL

Anhang anzeigen 45333

und bei FC2 CNT_CTL1
Anhang anzeigen 45334
daher gehe ich davon aus, dass man beide FCs benutzen kann unabhängig der FM und nur wenn man isochrone brauch / will den CNT_CTL1.
Was Siemens da im Kommentar zu Baustein-Symbolen schreibt kann besonders schick gemeint oder auch einfach undurchdacht sein ...
Liest Du eigentlich auch die Handbücher?
In allen mir bekannten Handbüchern zur FM450-1 wird beschrieben, daß man den FC0 CNT_CTRL verwenden soll.
In allen mir bekannten Handbüchern zur FM350-1 wird beschrieben, daß man den FC2 CNT_CTL1 verwenden soll (oder den FC3 CNT_CTL2 in taktsynchronen OB).
Findest Du irgendwo eine Anleitung, daß für FM350-1 der FC0 CNT_CTRL verwendet werden soll/kann?

Also ich würde den FC0 CNT_CTRL nicht für FM350-1 verwenden solange Siemens das nicht explizit als zulässig erklärt hat.

Harald
 
Was soll denn die Unterstellung, ob ich die Handbücher lese oder nicht. Dann lass dich mal eines besseren belehren:

erstens sind CNT_CTL1 und CTL2 für Taktsynchronen Betrieb und nur CNT_CTRL ist nicht für diesen. Hier aus dem Handbuch was du gerade selber gelinkt hast:
cnt.jpg

Des Weiteren, eine Beschreibung wo Siemens draufsteht und FC CNT_CTRL für FM350? Gerne:

cnt2.jpg

Nicht das ich das unbedingt als Anleitung sehen würde. Aber zeig mir etwas wo steht dass man den dafür nicht nehmen darf. Zumal ob du nun die Bausteinbeschreibung für richtig hälst oder nicht, leite ich für mich daraus ab dass man das kann. Weil beide sagen FM450/350 und der eine explizit noch sagt taktsynchron. Und ich habe auch geschrieben, dass ich den CTL1 nutze und beide getetest hab mit dem gleichen Ergebnis.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Was soll denn die Unterstellung, ob ich die Handbücher lese oder nicht.
Das war keine Unterstellung sondern eine Frage. Bis jetzt hattest Du Dir noch nicht anmerken lassen, daß Dir die Diskrepanz zwischen Deinem Blabla-Bild und den Gerätehandbüchern mit den detaillierten Anleitungen aufgefallen ist.

Dann lass dich mal eines besseren belehren:
[...]
Des Weiteren, eine Beschreibung wo Siemens draufsteht und FC CNT_CTRL für FM350? Gerne:

Anhang anzeigen 45338
Ich lasse mich gerne "belehren" ohne gleich eingeschnappt zu sein - Hast Du mal eine Quellenangabe für Dein zweites Bild?


PS: Was sagt eigentlich der Siemens Support zu Deinem Problem?

Harald
 
Zuletzt bearbeitet:
Das war keine Unterstellung sondern eine Frage. Bis jetzt hattest Du Dir noch nicht anmerken lassen, daß Dir die Diskrepanz zwischen Deinem Blabla-Bild und den Gerätehandbüchern mit den detaillierten Anleitungen aufgefallen ist.

Harald

Meinst du z.B. diese Anleitung:
https://www.automatyka.siemens.pl/docs/docs_ia/S7-300_FM350-1_e.pdf

wo auf Seite 5-15 steht: "Processing time in the CPU 416-2 DP (FM 350-1 decentralized) 30 µs" ? Ein weiterer Indiz für mich dass man den sehr wohl für den FM 350-1 verwenden kann, da er doppelt so schnell arbeitet wie der CNT_CTL1. Obowhl man wohl bei 30 µs und 70 µs nicht von einem essentiellen Geschwindigkeitsvorteil reden kann. Interassanter Weise find ich diesen Abschnitt in der deutchen Anleitung nicht mal.

Die Frage hättest du dir ansonsten selber beantworten können, da ich schon mindestens ein Bild aus Beschreibung hier im Thread gelinkt habe. Mein BlaBla-bild findste auf Google, erste seite sogar wenn man FM350-1 CNT_CTRL erfragt. Und nur um eins klar zustellen, ich habe sehr wohl gesehen, dass in den Beispielen immer CNT_CTL1 verwendet wird. Ich habe nicht gesagt, man solle ihn icht verwenden. Ich habe auch nicht gesagt man solle ihn nicht bevorzugt verwenden. Ich verwende ihn ihm meinem Projekt auch. Meine Aussage bestand darin dass man den CNT_CTRL dafür auch nehmen kann und du hast noch nicht einen stichhaltigen Punkt vorgelegt der dem widerspricht.
 
Ich könnte stundenlang Handbücher lesen und wäre mir trotzdem nie sicher, ob ich tatsächlich die Beschreibungen so verstanden habe, wie sie auch gemeint sind :D
Manchmal habe ich verstanden, was gemeint war, obwohl ich eine Beschreibung gelesen habe.
Aber meistens hatte ich das Gefühl, dieses oder jenes hätte man verständlicher oder weniger missverständlich beschreiben können, habe nochmal nachgelesen und . . . siehe da . . . ich hätte es nicht besser formulieren können. Wenn man erstmal verstanden hat, was gemeint ist, versteht man auch die Beschreibung.
Das klingt sicher paradox und ist einfach nur der Unterschied zwischen Theorie und Praxis - glaube ich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja ich weiß was du meinst. Das gleiche ist bei mir so, wenn ich ein neues Programm lernen muss. Wenn ich vorher selber mal etwas drauf rumgeklimpert hat, versteh ich die Schulung besser bzw. bringt mir mehr als umgedreht. :D

Naja, lassen wir das ganze mal ruhen bis montag. Ich tausche erstmal den Geber mit der Instandhaltung und wenn das nicht hilft gucken wir mal weiter. Ich werd mal taktsynchron probieren für die Station und gucken ob mir dass dann weiterhilft. Und wenn nichts weiterhilft, schreite ich zum Äußersten und Ruf beim Support an.
 
Moin Clyde,

ich erlaube mir mal folgende "FernDiagnose" und Prognose:
Dein "gefallener Geber" ist voll funktionsfähig und er fliegt Dir nur um die Ohren, wenn Du bei einem Versuch, die maximale Drehzahl zu ermitteln, schamlos übertreibst :D

Ferner möchte ich diese Gelegenheit nutzen, nochmal auf mein Gemälde aus #43 zurückzukommen. Es war der Versuch, für Deine DifferenzenListen eine plausible Erklärung zu finden.
Basierend auf dem 50-ms-WeckAlarm, war ich darauf gekommen, dass wahrscheinlich die tatsächlichen AusleseZeitpunkte in einem ~28-ms-Raster erfolgen und die so aus der ZählerKarte gelesenen Werte im 50-ms-Takt des WeckAlarms an Deine Software übermittelt werden. Das führt dazu, dass Du meistens Werte zu sehen bekommst, die im 56-ms-Raster aus der Karte ausgelesen wurden und hin und wieder einen Wert, der im 28-ms-Raster aus der Karte geholt wurde und deshalb eine Differenz liefert von 50% der übrigen Differenzen.
Im Endeffekt gehen keine ZählImpulse verloren. Es besteht also kein Grund die LängenMessung anzuzweifeln!
Ein "Zuviel" einer MessPeriode führt nicht zu einem entsprechenden "Zuwenig" in der unmittelbar folgenden MessPeriode und genauso wird ein "Zuwenig" durch ein entsprechendes "Zuviel" kompensiert, weil das ZeitRaster von 50 ms zu nahe bei dem Raster von 56 ms (2 * 28 ms) liegt.
Die WeckAlarme erfolgen in ca. 10% zu kurzen Abständen.
Habe das Diagramm nun um den Fall erweitert, dass die WeckAlarme in ca. 10% zu langen Abständen (ca. 62 ms) erfolgen.

Raster2.jpg

Man sieht, dass die "AusreisserDifferenzen" in diesem Fall 50% grösser (statt 50% kleiner) sind und gleich oft auftreten.

Sooo, wenn man nun den WeckAlarmTakt auf ein ganzzahliges Vielfaches des ~28-ms-Taktes synchronisieren könnte . . .

Wenn man das nur "ziemlich gut" hinkriegt, bleiben grundsätzlich die "AusreisserDifferenzen", sie treten lediglich seltener auf.
Ob mir eine solche "Macke" lieber wäre? Sie tritt für meinen Geschmack zu selten auf, um leicht durchschaut und "bekämpft" werden zu können. Sie deswegen einfach zu ignorieren, wäre jedoch übel.
Welche "StellSchrauben" Siemens hat, um die Synchronisation "super gut" hinzukriegen, habe ich leider noch nicht so recht verstanden - darum hält sich meine Euphorie im Moment noch in Grenzen :ROFLMAO:

Ich weiss, dass mein Beitrag keine Lösung des Problems darstellt. Aber ich hoffe, dass ich das Phänomen veranschaulichen konnte - und natürlich, dass die Siemens-Lösung die Verbesserung bringt, die wir uns erhoffen!!!

Schönes WE! Gruss, Heinileini

Edit:
Kleine Erläuterung der Diagramme:
Die Impulse im 28-ms-Takt zeigen, wann die ZählerWerte aus der ZählerKarte ausgelesen werden. Die Werte, die bei Impulsen ohne "FarbKlecks" ausgelesen werden, erscheinen nicht als Wert im WeckAlarmTakt - sie werden für das Programm unsichtbar unter den Teppich gekehrt, weil beim nächsten WeckAlarmTakt bereits einer der folgenden Werte zur Verfügung steht und dieser dann weitergereicht wird. Die Impulse, deren AusleseWerte weitergereicht werden, sind farblich gekennzeichnet und die entsprechenden Impulse im WeckAlarmTakt mit derselben Farbe.
 
Zuletzt bearbeitet:
Ok,

danke erstmal. Ich denk erstmal drüber nach, denn so ganz verstanden hab ich deine Erläuterung noch nicht. Nur eine kleine Frage. Wenn ich ein 2tes Signal machen würde alle 100ms zusätzlich zu 50ms würde dir das Helfen deine Prognose zu bestätigen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ich ein 2tes Signal machen würde alle 100ms zusätzlich zu 50ms würde dir das Helfen deine Prognose zu bestätigen?
Nein, meine "Prognose" bezog sich lediglich auf das Um-die-Ohren-Fliegen des Gebers mit "AbsturzHintergrund" und war somit wenig "zweckdienlich" ;)
Ich kann Dir leider nicht helfen.
Siemens hat offensichtlich das Problem längst erkannt und bietet eine Lösung an. Probier sie aus und wenn Du Zeit dafür hast, berichte mal bei Gelegenheit darüber!
Es ist ein Thema, das viele hier im Forum interessiert bzw. interessieren sollte.

Für mich war interessant, zu erfahren, dass anscheinend die ZählerKarte nicht - wie man erwarten würde - im Takt des WeckAlarms ausgelesen wird.
Das Auslesen geschieht in einem anderen Takt (ca. 28 ms) und die so gelesenen Werte werden lediglich im Takt des WeckAlarms an das Programm weitergereicht, so dass das Programm einen Jitter sieht, der zunächst unerklärlich erscheint, weil er rein gar nichts mit dem Jitter zu tun hat, der vielleicht bereits im GeberSignal vorhanden ist oder durch die Digitalisierung in der ZählerKarte hinzugefügt wird.

Und nein, ein zweites Signal im 100-ms-Takt, zusätzlich zum 50-ms-Takt, bringt nichts Neues. Du bräuchtest nur jeden zweiten im 50-ms-Takt erhaltenen Wert zu ignorieren und die übrigen auszuwerten - das wäre schon das, was Du im (vermeintlich) zusätzlichen Takt sehen würdest. Das grundsätzliche Problem würde bleiben, die Häufigkeit der AusreisserWerte wäre eine andere und die Abweichung der AusreisserWerte von den übrigen wäre geringer. Eine Verlängerung der WeckAlarmZeit hilft natürlich, das Problem besser zu verschleiern. Ob Dir das schon als Lösung genügen würde, musst Du selbst entscheiden.
 
Zuletzt bearbeitet:
Ich glaube, es hat grad Klick gemacht.

Wenn man das unterlagerte Problem mal betrachtet: Man möchte immer die gleiche Impulsdifferenz zum gleichen Zeitpunkt haben bei konstanter Fahrt der Anlage. Der 0815 Trick ist dann normalerweise ein Weckalarm zu nutzen und mit dem PED zu arbeiten. Dann hat man vllt. ein wenig Jitter (0.3 % nach Siemens) - man ist jedoch fertig.

ABER
das ganze funktioniert nur wenn deine Karte auch im Rack der CPU steckt, nur dann ist es auch möglich den Wert übers PED direkt abzuholen. Ganz anders sieht das aus, wenn man mit dezentraler Peripherie arbeitet, dort hat nämlich der Profibus seinen eigenen Zyklus (bei mir wohl 28ms), der erstmal total unabhängig von der CPU ist. Des Wegen funktioniert es bei mir auch nicht, selbst wenn ich mit dem PED arbeite - weil das PED den Profibus nicht dazu veranlasst mir den aktuellen Wert zu geben, sondern ich krieg den aus dem letzten Zyklus des Busses.

Wenn ich also alle 50ms gucke müssen da 2 Profibuszyklen drin liegen. Da sie aber 28ms dauern hab ich nach 250ms nicht 10 Profibuszyklen sondern 9 und genau dann bekomm ich dann eine Impulshalbiering für einen Zyklus. Bezogen auf meine Liste die ich hier mal gepostet hab, hab ich alle 50ms 460 Impulse, der Profibus gibt mir aber alle 28ms 230 Impulse bei konstanter fahrt. Wenn es dann passiert dass der 50ms Weckalarm nur einen neuen Profibuszyklus abdeckt und nicht wie gewollt zwei sehe ich nur 230 Impulse für einen 50ms Zyklus.

Das heißt aber auch, wenn mein Geber heile ist und nicht beschädigt wurde beim Einbau, bringt mir A ein Wechsel mal rein gar nichts. Weiterhin müsste das Umstellen für diese Baugruppe auf Taktsynchronität (sie kann es übrigens hab schon geguckt) und das Wegschreiben des Wertes im Takt-OB in einen DB dazu führen, dass das Phänomen verschwindet.

Krasser Typ du!, dass du das durchblickt hat. Danke dir! Ich bau das Montag oder Dienstag vorort mal um und melde mich.
 
Zuletzt bearbeitet:
>>>>====> :s12:

. . . und melde mich.
Immer gerne!
Viele der Threads hier im Forum enden leider so, dass der TE freudestrahlend berichtet "Es funktioniert jetzt!".
Und wir erfahren einfach nicht, welcher der oft vielschichtigen Tipps derjenige war, der wirklich weitergeholfen hat!

In diesem Thread war es sicherlich der SiemensTipp mit der TaktSynchronität, den Du selbst beigetragen hast.
 
Zuletzt bearbeitet:
Zurück
Oben