Step 7 Istgeschwindigkeit aus FM-450

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn Du nicht am Anfang so falsche Informationen gestreut hättest, und die wahren Informationen erst in Beitrag #33 und #39 ans Licht kommen, dann wären wir wohl schon früher drauf gekommen, daß Dein Problem daher kommt, weil Du die Zählerstände nicht synchron zur Verarbeitungsfrequenz ausliest und insbesondere mit einer falschen/nicht eingehaltenen Meßzeit rechnest. Immer wenn die Differenzzeit (Phasenverschiebung) der nicht synchronen Zyklen (Berechnungs-Zyklus und Profibus-Zyklus) sich zu einer Zykluszeit des kürzeren Zyklus aufsummiert hat, dann bekommst Du einen Phasensprung.

Lösungen:
- die vermutlich einfachste und genaueste Lösung: schließe den Encoder an einer Zählerkarte im zentralen Rack an
- oder lies den Zählerwert synchron zum Profibus-Zyklus (taktsynchron)
- oder rechne die Schwankung des Meßintervalls heraus (ggf. runden)

Wie schnell brauchst Du denn tatsächlich die Bandgeschwindigkeit? Alle 50 ms ist doch sicher sowieso unnötig/sinnfrei?
Du müsstest das Meßintervall so lang machen, daß die Schwankung der Auslesefrequenz von 28 ms unter Deinen Genauigkeitsanforderungen liegt. Wenn der Rechenfehler durch den 28ms-Phasensprung auf unter 3% fallen soll, dann müßte Dein Meßintervall mindestens 1 s lang sein. Wenn Du tatsächlich nicht 1 Sekunde auf den nächsten Meßwert warten kannst, dann könntest Du die Meßintervalle ineinander "verschachteln": Du könntest z.B. alle 100ms den Zählerstand in einen 10-Werte-Ringpuffer legen, und die Differenz zum Zählerstand 1 s vorher bilden. Du könntest zusätzlich noch den Mittelwert zum vorhergehenden Meßwert oder über alle 10 Meßwerte bilden.

Können Deine SPS CPU und deren integrierte Profibus-Schnittstelle (kein CP!) und die ET200M-Kopfstation (153-2Bxxx?) die taktsynchrone Arbeitsweise? Der von Dir verwendete FC CNT_CTRL ist dafür jedenfalls ungeeignet...

PS: Möglicherweise kann der FC CNT_CTRL auch für FM350-1 verwendet werden. Doch wenn ich unerklärliche Probleme habe, dann halte ich mich zunächst ganz genau an die Siemens-Anleitungen. Was anderes bzw. eigene Interpretationen kann ich einbringen, wenn alles wie erwartet funktioniert.

Harald

 

[Clyde82]

@PN/DP
Hast du noch nie im laufe einer Aufgabe festgestellt, dass du an einer Stelle nen Fehler gemacht oder an anderer Stelle etwas falsch interpretiert hast? Ich habe doch geschrieben, dass ich für die FM350-1 den CNT_CTL1 verwende und ich auch CNT_CTRL getestet habe. Es war auch ungünstig am Anfang des Threads die Aufrufe für die FM350-1 mit CNT_CTRL hochzuladen, weil es zur allgemeinen Verwirrung beigetragen hat. Aber ich hab sogar ein Bild gelinkt wo drinsteht, dass CNT_CTRL nicht für taktsynchron ist sondern nur CTL1 und CLT2, wo du davor noch meintest nur CTL2 wäre für taktsynchron.

Und ja ich brauche ein schnelles Geschwindigkeitssignal. 200ms ist so ziemlich die Grenze, 50ms müssen es natürlich nicht sein.

Und ganz ehrlich, wenn du die negative Einstellung nicht lassen kannst / willst, verzichte ich SEHR GERNE in Zukunft auf deine Hilfe.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Zurück zum Thema.

Ich hab mich gerade mal von der ferne eingewählt auf die SPS und wenn ich im CPU Dialog den OB61 (hab auch OB62-63 probiert) den Masterstrang 1 zuweise und den Bus auf äquidistanz stelle bekomme ich beim Übersetzen die Meldung, dass 1024 Bytes E/A überschritten sind Ich hab schon etwas gegoogelt, bisher hab ich noch keine Info gefunden, dass man bei taktsynchronem Profibus nur 1024 bytes auf der Peripherie haben darf. Jedenfalls ich geh mal gucken, irgendwie soviele Anleitungen hab ich dazu noch nicht gefunden und wenn dann ist sie für TIA und Profinet. Wenn sich aber die 1024 Bytes nicht umgehen lassen bin ich gearscht. Wir haben zwar noch einen 2ten Profibusstrang, aber der läuft über ne CP und den kann ich für die OB6X nicht mal auswählen. Ansonsten hat die CPU aber noch Profinet, vielleicht kann ich ja ethernet in den Schaltschrank vorort legen lassen, ich red mal mit der Instandhaltung.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

wo du davor noch meintest nur CTL2 wäre für taktsynchron.

Wo habe ich behauptet, daß nur der CTL2 für taktsynchron wäre?
Ich glaube, Dein Problem ist daß Du Texte und Anleitungen nur oberflächlich liest und irgendwas hineininterpretierst was da gar nicht steht.

Und ganz ehrlich, wenn du die negative Einstellung nicht lassen kannst / willst, verzichte ich SEHR GERNE in Zukunft auf deine Hilfe.

Ich meine, die negativen "Vibrations" hast Du hier in den Thread gebracht...
Aber OK, ich halte mich hier jetzt raus. Ist ja nicht mein Problem was da gelöst werden soll

Daß die FM350-1 auch Geschwindigkeit/Drehzahl/Frequenzmessung kann, hast Du im Handbuch natürlich schon gelesen. Dann ist Dir sicher auch klar, daß dabei kein taktsynchroner Betrieb des Profibus notwendig ist...

Harald

 

[Clyde82]

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

Da hast du es geschrieben und so liest es sich auch und ja ich weiß, dass die auch Drehzahlmessung kann, aber leider brauch ich nunmal in erster Linie den Weg, der ist das wichtigste.

 

[Heinileini]

Sooo, die Wogen scheinen jetzt wieder geglättet . . . dann melde ich mich mal wieder

Habe die Tabelle aus #16 in Excel verwurstet und die TaktSynchronität nur aus den vorliegenden Daten und meiner ~28-ms-Takt-Theorie zu rekonstruieren versucht:



Die linken 3 Spalten sind die Clyde'sche Tabelle - davon wird nur die Spalte "Diff" ausgewertet.
In Spalte "Zhl" wird der Wert aus der Spalte "Diff" mit dem vorherigen Wert der Spalte "Diff" verglichen:
- unterschreitet der Wert 70% des vorherigen Wertes, so erscheint hier eine 1
- sonst wird hier 2 auf den Wert "Zhl" der vorherigen Zeile addiert.
In Spalte "Sum" erscheint der Wert aus Spalte "Diff", wenn in Spalte "Zhl" eine 1 steht, sonst wird der Wert "Diff" auf den Wert "Sum" der vorherigen Zeile addiert.
In Spalte "Sum/Zhl" steht genau das: der Wert aus Spalte "Sum" dividiert durch den Wert aus Spalte "Zhl".
In Spalte "Diff/2" steht nur dann der durch 2 geteilte Wert aus Spalte "Diff", wenn der Wert in Spalte "Zhl" nicht 1 ist, sonst der nicht veränderte Wert aus Spalte "Diff".

Im oberen Diagramm sind die Spalten "Diff" bis "Diff/2" dargestellt, Spalte "Sum" ist jedoch weggelassen.
Das untere Diagramm konzentriert sich auf die Spalten "Sum/Zhl" und "Diff/2", weil sie im Massstab des oberen Diagramms schlecht zu erkennen sind.
"Sum/Zhl" ist das Ergebnis mit MittelwertBildung und "Diff/2" das Ergebnis ohne MittelwertBildung.
Diese beiden Werte sind zur Geschwindigkeit proportional, aber, um die Geschwindigkeit zu berechnen, fehlt noch der genaue Wert für die Länge des ~28-ms-Taktes.

Das Jittern in den ErgebnisSpalten "Sum/Zhl" und "Diff/2" hält sich doch so schön in Grenzen ("Sum/Zhl": ±1,6%), dass man eine brauchbare GeschwindigkeitsAnzeige erwarten kann.

Die tatsächliche Länge des ~28-ms-Taktes lässt sich jedoch mittels der Tabelle annähern. Je länger die Tabelle von Messungen, desto besser.
Der einzige Haken dabei ist, dass über die gesamte Länge der Messungen auch tatsächlich auswertbare Werte in Spalte "Diff" vorhanden sein müssen, weil sonst der Inhalt der Spalte "Zhl" nicht gebildet werden kann.
Mit den derzeitigen Daten aus der obigen Tabelle zeichnet sich ab, dass der Wert bei etwas unter 28ms liegt (27,61 ms).

 

[Clyde82]

Zuviel Werbung?
-> Hier kostenlos registrieren

Woohoo es läuft - Ich schreib später noch genau was wir gemacht haben.

 

[Clyde82]

So,

wir haben heute natürlich etwas diskutiert und uns auf folgende Lösung geeignigt:

Da wir, wie in Post #33 bereits erwähnt, auf der Karte die NICHT Signale fälschlicherweise aufgelegt hatten, haben wir diese jetzt verwendet um damit eine 2te FM350-1 zu speisen und haben diese auf Drehzahlmessung gestellt. Es schien uns die sinnvollste Lösung, da keiner Erfahrung hat mit taktsynchronem Profibus und dazu hätten wir eh etliches ändern müssen, da der entsprechende Bus wie bereits erwähnt die maximalen 1024 Byte weit überschreitet. Hätte es mit der 2ten FM nicht geklappt, hätten wir das Geberkabel in die E-Station verlängert und wären aufs Rack der CPU gegangen.

Aber jetzt tänzelt der Istwert auch in einem Bereich +/- 0,5 m/min um den Sollwert, also genau das was wir wollten.

Ich hab die FM auf 50ms Abtastzeit gestellt für die Drehzahlerfassung und denke ich werd das aber nochmal ändern und die auf 100ms erhöhen oder sogar auf 200ms.

Anbei ein Bild vom Endergebnis:


Vielen Dank nochmals an die fleißigen Helfer. Da war mal wieder ein Problem, wo ich etliches gelernt habe.

 

[Heinileini]

Moin Clyde,
das waren mir zuviele 'hätte' und 'wäre' - ich habe nicht wirklich verstanden, was jetzt Sache ist.

Ehe Du noch mehr herumprobierst . . . probier vielleicht erstmal folgendes.
WeckAlarm weiterhin 50 ms, nix TaktSynchronMimik, nix extra-FM für Geschwindigkeitsmessung - also total noch Deine ursprüngliche Konfiguration.
Ich habe versucht, meinen Excel-Ansatz in eine SCL-ähnliche Form zu giessen - Deklarationen habe ich mir erspart - ich hoffe, Du verstehst trotzdem, was ich meine.
Die Jitterei gefällt mir besser als in Deinem letzten Diagramm (ca. Faktor 3, wenn ich mich nicht "vergaloppiert" habe).
Der Aufwand hält sich für meinen Geschmack durchaus im Rahmen.

// im Anlauf der SPS (und nach Änderung eines der Parameter):   
   
    rPI     := 4.0 * Arctan(1.0);                  // Real; Berechnung von PI
    rD      := 300.0;                              // Real; Durchmesser [mm]
    rSproU  := 1000.0;                             // Real; Striche/Umdrehung
    rFproS  := 4.0;                                // Real; Flanken/Strich
    rATP    := 27.78;                              // Real; AusleseTakt(Bus) [ms]
   
    rFaktor := rPI * rD / rSproU / rFproS / rATP;  // Real; PropFaktor für Umrechnung in m/s
   
// - - - - + - - - - + - - - - + - - - - + - - - - + - - - - + - - - - + - - - - + - - - - + - - - - +   
   
// im 50ms WeckAlarm (wohl gemerkt: 50 ms !!!):   
   
    // Variablen, deren Namen mit 'd' beginnen: Dint  
    // Variablen, deren Namen mit 'r' beginnen: Real  
    // Variablen, deren Namen auf 'Alt'  enden: müssen beim nächsten Aufruf   
    //           (nach 50 ms) mit unverändertem Inhalt zur Verfügung stehen  
   
    dZähler    := "PED";                           // Zählerstand einlesen - "wie auch immer"
    dDiff      := dZähler - dZählerAlt;  
    dZählerAlt := dZähler;  
   
    If dDiff * 10 < dDiffAlt * 7 Then  
        dAnzE  := 1; 
        dAnzM  := 1; 
        dSumm  := dDiff; 
    Else  
        dAnzE  := 2; 
        dAnzM  := dAnzM + 2; 
        dSumm  := dSumm + dDiff; 
    End_If;  
    dDiffAlt   := dDiff;  
   
    rDiff      := Dint_To_Real(dDiff);  
    rSumm      := Dint_To_Real(dSumm);  
    rAnzE      := Dint_To_Real(dAnzE);  
    rAnzM      := Dint_To_Real(dAnzM);  
   
    rVM        := rSumm / rAnzM * rFaktor * 60.0;  // Geschwindigkeit [m/min] (teils gemittelt)
    rVR        := rDiff / rAnzE * rFaktor * 60.0;  // Geschwindigkeit [m/min] (nicht gemittelt)

 

[Clyde82]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey,

die Sache mit der extra FM läuft super und hat ja bis auf die Baugruppe stecken keinen Aufwand gemacht, weil wir alles ja schon da hatten. Ich hab am Donnerstag Zeit und guck mal wie es mit deinem Baustein aussehen würde.