-> Hier kostenlos registrieren
Könnte man nicht aus der Differenz zwischen der gemessenen Werte zwischen Periodendauer und Mindestimpulsdauer was brauchbares zaubern?
...quasi beides messen, vergleichen und das PWM so bestimmen?
Step 7 PWM-Signal einlesen und verarbeiten
- Ersteller Manoel
- Erstellt am
-> Hier kostenlos registrieren
...quasi beides messen, vergleichen und das PWM so bestimmen?
Das Kapitel in dem es um die EINGÄNGE geht heißt:
Das impliziert mir, dass die CPU nicht nur PWM erzeugen kann...
In meinem Fall habe ich das Signal auf Kanal 2
- Beiträge
- 22.927
- Reaktionspunkte
- 7.134
-> Hier kostenlos registrieren
Die Mindestimpulsdauer von SFB49 hat nichts mit dem SFB47 zu tun.Könnte man nicht aus der Differenz zwischen der gemessenen Werte zwischen Periodendauer und Mindestimpulsdauer was brauchbares zaubern?
Die Periodendauer ist lediglich der Kehrwert der Frequenz und bei PWM daher auch immer gleichleibend.
???
PS:
Eventuell könnte man was basteln, wenn man auf einen Zählkanal eine Frequenz von vielleicht 1 kHz gibt (ggf. mit PULSE erzeugt), und mit dem PWM-Signal die Zählrichtung steuert. Da sollte sich ein vom Puls/Pause-Verhältnis abhängiger Zählwert ergeben. Das kannst Du ja mal durchrechnen. Irgendwie braucht man da auch noch ein Signal, wann man den Zählwert auslesen muß.
Harald
Zuletzt bearbeitet:
Nein, die ist fix...
- Beiträge
- 22.927
- Reaktionspunkte
- 7.134
Ist das verwendete Messgerät geheim? Oder warum nennst Du es nicht?
Wie gut kannst Du AWL programmieren?
Bei 73 Hz ~ 13 ms Periode könnte man theoretisch einmal je OB1-Zyklus in einer Schleife den Peripherieingang des PWM-Signals abfragen und die Pulslänge messen. Also auf den Beginn des Puls warten + Startzeit merken + auf das Ende des Puls warten + Zeitdifferenz ermitteln. Problem: Dafür braucht man eine Zeitauflösung mindestens im µs-Bereich, die gibt es bei der 313-5BE00 aber nicht. Man könnte auf einen schnellen Zähleingang eine Frequenz von 10 kHz ... max 30 kHz geben und den Zählerstand dieses Zählkanals als Zeitgeber mit Auflösung 100 .. 33 µs nutzen. (Die 313-5BE00 kann allerdings max 2.5 kHz erzeugen.) So könnte das PWM-Signal mit geringer Genauigkeit ausgewertet werden.
Harald
Wie gut kannst Du AWL programmieren?
Bei 73 Hz ~ 13 ms Periode könnte man theoretisch einmal je OB1-Zyklus in einer Schleife den Peripherieingang des PWM-Signals abfragen und die Pulslänge messen. Also auf den Beginn des Puls warten + Startzeit merken + auf das Ende des Puls warten + Zeitdifferenz ermitteln. Problem: Dafür braucht man eine Zeitauflösung mindestens im µs-Bereich, die gibt es bei der 313-5BE00 aber nicht. Man könnte auf einen schnellen Zähleingang eine Frequenz von 10 kHz ... max 30 kHz geben und den Zählerstand dieses Zählkanals als Zeitgeber mit Auflösung 100 .. 33 µs nutzen. (Die 313-5BE00 kann allerdings max 2.5 kHz erzeugen.) So könnte das PWM-Signal mit geringer Genauigkeit ausgewertet werden.
Harald
- Beiträge
- 6.465
- Reaktionspunkte
- 1.587
-> Hier kostenlos registrieren
Ich hatte in einer ähnlichen Richtung überlegt:
- eine feste Frequenz (professionell oder industriell erzeugt
) auf den ZählEingang geben (10 kHz könnte auch noch gehen?) und- das PWM-Signal auf den HardwareTorEingang
- evtl. zusätzlich mit dem SoftwareTor eine MessPeriode (1 Hz?) bilden und den Zähler auslesen (und ggfs rücksetzen, falls nicht endlos gezählt wird)
Was heisst "muss"? Darf man nicht jederzeit? Ist der Wert nicht in ge-"latch"-ter Form verfügbar?
PS:
Jetzt habe ich (glaube ich) verstanden, was Du meinst. Wenn man mit dem PWM-Signal die ZählRichtung steuert, müsste man wohl exakt zum Ende einer PWM-Periode auslesen?
Zuletzt bearbeitet:
- Beiträge
- 9.191
- Reaktionspunkte
- 2.942
Wenn man ein elektronisches UND-Gatter hätte, dann könnte man das PWM-Signal mit einer entsprechend der Auflösung geforderten Frequenz ver-UND-en. Dann ließe sich aus der Anzahl der Impulse das Verhältnis zurückrechnen.
- Beiträge
- 22.927
- Reaktionspunkte
- 7.134
Ich hatte in einer ähnlichen Richtung überlegt:
- eine feste Frequenz (professionell oder industriell erzeugt
- das PWM-Signal auf den HardwareTorEingang
- evtl. zusätzlich mit dem SoftwareTor eine MessPeriode (1 Hz?) bilden und den Zähler auslesen (und ggfs rücksetzen, falls nicht endlos gezählt wird)
Klar, PWM-Signal auf HardwareTor ist die viel bessere Idee als Vorwärts/Rückwärts-Zählen. Plus SoftwareTor, dann braucht man keinen Prozessalarm bei jeder Flanke als "JetztAuslesen"-Signal. Das könnte tatsächlich funktionieren. Bei Vorwärts/Rückwärts-Zählen müsste man den Zählerstand genau beim Wechsel von Rückwärts- zu Vorwärts-Zählen auslesen. Oder genau nach x Perioden.
Jetzt bin ich aber zu müde...
Harald
- Beiträge
- 22.927
- Reaktionspunkte
- 7.134
-> Hier kostenlos registrieren
- Beiträge
- 22.927
- Reaktionspunkte
- 7.134
Mit 10 kHz Signal auf 2 Zählkanäle, ein Kanal Dauer-Zählen und ein Kanal mit dem PWM-Signal als Hardwaretor, müsste die Auswertung des Verhältnis Pulsdauer zu Periodendauer relativ einfach werden. Da könnten auch die max 2.5 kHz bei längerer Mess-Periode reichen.
Harald
Harald
- Beiträge
- 6.465
- Reaktionspunkte
- 1.587
Habe (noch) nicht gefunden, ob man einen HW-Tor-Eingang auch invertieren könnte. Man könnte dann auch auf einem Kanal während der ImpulsDauer und auf einem anderen während der ImpulsPausenDauer zählen (und die Summe aus beiden selbst bilden).
Da das Verhältnis aus zwei Zahlen gefragt ist, ist auch die Stabilität der Frequenz bei 2-kanaligem Zählen nicht so kritisch.
Aber wozu muss man ein PWM-Signal, mit dem ein DatenLogger einen Ventilator ansteuert, so wahnsinnig genau auswerten?
Zuletzt bearbeitet:
-> Hier kostenlos registrieren
Also vor längerer Zeit haben wir PWM Signale für einen Prüfstand mit Beckhoff "vermessen" also Puls/Pausendauer/Frequenz ermittelt. War damals ein recht aktueller CX, wir haben den jedoch hart an seine Grenze gebracht und dann glaub ich sogar mit dem Beckhoff-Support (der war meienr Meinung damals noch besser ) Abends sogar noch einen Fehler irgendwo aufgedeckt, der dann am nächsten Morgen auch gleich gefixt wurde.
Aber das ganze war wirklich grenzwertig - eine einfache RC kombination hätte es nicht getan, es musste Puls/Pausendauer sowie Frequenz ermittelt werden.
Einen Einfachen Prüfstecker haben wir dann mit einem PIC 18F gelöst, der macht sowas ähnliches, nur mit weniger Overhead - und ohne Prüfugn der Frequenz wenn ichs noch richtig in Erinnerung habe.
Ich müsste mal schaun ob ich dazu was finden kann - aber ist schon verdammt lang her.
) Abends sogar noch einen Fehler irgendwo aufgedeckt, der dann am nächsten Morgen auch gleich gefixt wurde.Aber das ganze war wirklich grenzwertig - eine einfache RC kombination hätte es nicht getan, es musste Puls/Pausendauer sowie Frequenz ermittelt werden.
Einen Einfachen Prüfstecker haben wir dann mit einem PIC 18F gelöst, der macht sowas ähnliches, nur mit weniger Overhead - und ohne Prüfugn der Frequenz wenn ichs noch richtig in Erinnerung habe.
Ich müsste mal schaun ob ich dazu was finden kann - aber ist schon verdammt lang her.
Nein, ist es nicht, ich musste nur erst nochmal nachschauen...
DG700
-> Hier kostenlos registrieren
Ja genau, der Ausgang schafft nur 2.5 kHz. Der Eingang, also lesen ist schneller. Wenn ich das richtig verstehe 30kHz sogar.
Onkel Dagobert
Level-3
- Beiträge
- 5.926
- Reaktionspunkte
- 1.518
Die Idee, die Expertenrunde immer wieder auf das Handbuch zu verweisen, finde ich sehr clever. Hoffentlich sehen es Harald und Heinileini auch so. Wie sollen die auch helfen können, wenn sie nicht wissen, wo es geschrieben steht? Vielleicht könntest du das Handbuch zu dem misteriösen DG700 auch noch posten? Ich schätze, es ist weder ein Dieselgenerator, noch ist es ein ein Druckluftschrauber.
Ich bin auch etwas enttäuscht, dass die 300C mit ihren Zähler-Eingängen offensichtlich kein PWM-Signal auswerten kann. Eine Auswertung der Flanken im OB40 scheidet bei 73,3Hz wohl auch aus. Mit größeren Abstrichen an Genauigkeit und Dynamik wäre über diesen Weg vielleicht etwas machbar.
Was natürlich immer geht ist ein Messumformer, wie er von Harald anfangs schon erwähnt wurde. Eine nackte Platine für 5€ muss es nicht unbedingt sein. Bei Phoenix gibt es z.Bsp. Messumformer mit Frequenz/PWM-Eingangssignal, welche eventuell passen könnten.
Ich bin auch etwas enttäuscht, dass die 300C mit ihren Zähler-Eingängen offensichtlich kein PWM-Signal auswerten kann. Eine Auswertung der Flanken im OB40 scheidet bei 73,3Hz wohl auch aus. Mit größeren Abstrichen an Genauigkeit und Dynamik wäre über diesen Weg vielleicht etwas machbar.
Was natürlich immer geht ist ein Messumformer, wie er von Harald anfangs schon erwähnt wurde. Eine nackte Platine für 5€ muss es nicht unbedingt sein. Bei Phoenix gibt es z.Bsp. Messumformer mit Frequenz/PWM-Eingangssignal, welche eventuell passen könnten.
- Beiträge
- 2.522
- Reaktionspunkte
- 899
Ich hatte vor Jahren auch so Ambitionen. Ich kam dann auch auf die Hardwaregate-Lösung mit schnellem Zähler.
Allerdings fand ich die Lösung unnötig komplex und teuer, weshalb ich schlussendlich die Integratorumsetzung wählte.
Eigentlich ist genau das auch der Sinn eines PWM-Ausgangs -die einfache Auswertbarkeit mittels RC-Glied an einem Analogeingang.
Bei einer PWM-Frequenz von <100Hz würde ich auch nix hochdynamisches vermuten, wo dann die Verzögerung des Integrators stört.
Auch die Zählerlösung hinkt ja zeitlich um eine PWM-Periode nach.
Allerdings fand ich die Lösung unnötig komplex und teuer, weshalb ich schlussendlich die Integratorumsetzung wählte.
Eigentlich ist genau das auch der Sinn eines PWM-Ausgangs -die einfache Auswertbarkeit mittels RC-Glied an einem Analogeingang.
Bei einer PWM-Frequenz von <100Hz würde ich auch nix hochdynamisches vermuten, wo dann die Verzögerung des Integrators stört.
Auch die Zählerlösung hinkt ja zeitlich um eine PWM-Periode nach.
- Beiträge
- 6.465
- Reaktionspunkte
- 1.587
-> Hier kostenlos registrieren
Und ich dachte immer, es sei ein Versuch, ein analoges Signal in Form eines scheinbar digitalen 1-Bit-Signals zu übertragen."Scheinbar" deshalb, weil es ja ein digitales Signal ist, aber die eigentliche Information in den Abständen der FlankenWechsel versteckt wird.
Ob die Abstände der Flanken aber wirklich analog sind? Wen interessiert's im digitalen ZeitAlter.
Die ursprünglichen EinsatzGebiete benötigen nicht einmal ein RC-Glied zur Auswertung. Dort nutzt man direkt die Trägheit der auswertenden Instanz. Z.B. beim Anschluss eines HeizStabes oder bei der HelligkeitSteuerung eines Leuchtmittels. Im letzteren Fall liegt z.T. (je nach Art des Leuchtmittels) die Trägheit im Auge/Gehirn des Betrachters.
Hochdynamisch wohl nicht, aber die Trägheit von Auge und Gehirn haben ihre Grenzen und eine Unterschreitung wird als störend oder sogar als hypnotisierend empfunden.
Das hast Du wieder mal sooo schön gesagt, Dagobert! Dank, Dank und immer wieder Dank!
PS:
[sarchasm] Harald sieht es bestimmt so. Schliesslich hat er den Link zum Handbuch nur deshalb in diesem Thread geliefert. [/sarchasm]
Zuletzt bearbeitet:
- Beiträge
- 22.927
- Reaktionspunkte
- 7.134
Nein, kann man nicht.
Richtig, das Handbuch braucht hier nicht ellenlang zitiert werden. In meiner vorausschauenden Weisheit
hatte ich das Handbuch schon in #3 verlinkt. Die Experten hier haben ausreichend Erfahrung mit Handbüchern lesen.Harald
- Beiträge
- 22.927
- Reaktionspunkte
- 7.134
So. Etwas länger drüber nachgedacht und überschlafen, die Lösung dann erträumt
Erkenntnis: die Aufgabe ist doch lösbar.
Da die PWM-Frequenz gleich bleibt, braucht man nur die Pulslänge messen (und könnte den Rest bei Bedarf ausrechnen). Die Pulslänge alleine ist aber schon ausreichend. Der Wert ist proportional zur Pulslänge.
Eckdaten: PWM-Frequenz 73.3 Hz = 13.64 ms * 0.4 ms Zählpulse = max 34.1 Pulse je PWM-Periode
Kurzbeschreibung:
In HW Konfig einen schnellen Kanal auf Ausgabe von 2.5 kHz (T=0.4 ms) 50% Puls/Pause einstellen
Betriebsart: Pulsweitenmodulation , Periodendauer: 4 x 0.1ms, Mindestimpulsdauer: 2 x 0.1ms, (SFB49 ist dann vermutlich nicht nötig, oder muß das Softwaretor geöffnet werden?)
den Digitalausgang zurück auf Zählkanal 2 Eingang verdrahten
das PWM-Signal auf HW Tor Zählkanal 2 verdrahten
In HW Konfig den Zählkanal 2 einstellen:
- endlos zählen
- Prozessalarm bei HW Tor öffnen --> alle 13.64 ms wird dann OB40 aufgerufen
Im Prozessalarm OB40 (alle 13.64 ms) prüfen ob der Prozessalarm vom Zählkanal 2 kommt.
( siehe das Handbuch Kapitel "5.8.4 Prozessalarm projektieren", und hier Forumssuche nach "OB40_MDL_ADDR" )
Wenn ja, den Zählerstand aus der Peripherie lesen (PED776 ?? untere 16 Bit würden auch reichen), Differenz zu Zählerstand vorher bilden (max 34, auch bei Überlauf immer positiv) und in eine Variable für OB1 speichern, neuen Zählerstand speichern
Tip: Für mehr Messwert-Genauigkeit/Glättung/Beruhigung 10 Messperioden je 10*13.6 ms = 136 ms ineinander schachteln. Ringpuffer (Array) für ca. 10 Werte Start-Zählerstand für 10 Differenzen. So gibt es alle 13.6 ms einen neuen Messwert mit Messzeit 136 ms. Das Arbeiten mit dem Ringpuffer multitasking-sicher im OB40 programmieren.
Im OB1 skalieren: ungefähr 0/1..34 = 0..100%
Das sollte so funktionieren und für den Lüfter genau genug sein.
Was noch zu klären ist:
- Wie groß/kurz ist die Mindest-Pulsdauer des PWM-Signals?
- Wie verhält sich das Signal bei 100% ? Mindest-Pausendauer?
Harald
Erkenntnis: die Aufgabe ist doch lösbar.
Da die PWM-Frequenz gleich bleibt, braucht man nur die Pulslänge messen (und könnte den Rest bei Bedarf ausrechnen). Die Pulslänge alleine ist aber schon ausreichend. Der Wert ist proportional zur Pulslänge.
Eckdaten: PWM-Frequenz 73.3 Hz = 13.64 ms * 0.4 ms Zählpulse = max 34.1 Pulse je PWM-Periode
Kurzbeschreibung:
In HW Konfig einen schnellen Kanal auf Ausgabe von 2.5 kHz (T=0.4 ms) 50% Puls/Pause einstellen
Betriebsart: Pulsweitenmodulation , Periodendauer: 4 x 0.1ms, Mindestimpulsdauer: 2 x 0.1ms, (SFB49 ist dann vermutlich nicht nötig, oder muß das Softwaretor geöffnet werden?)
den Digitalausgang zurück auf Zählkanal 2 Eingang verdrahten
das PWM-Signal auf HW Tor Zählkanal 2 verdrahten
In HW Konfig den Zählkanal 2 einstellen:
- endlos zählen
- Prozessalarm bei HW Tor öffnen --> alle 13.64 ms wird dann OB40 aufgerufen
Im Prozessalarm OB40 (alle 13.64 ms) prüfen ob der Prozessalarm vom Zählkanal 2 kommt.
( siehe das Handbuch Kapitel "5.8.4 Prozessalarm projektieren", und hier Forumssuche nach "OB40_MDL_ADDR" )
Wenn ja, den Zählerstand aus der Peripherie lesen (PED776 ?? untere 16 Bit würden auch reichen), Differenz zu Zählerstand vorher bilden (max 34, auch bei Überlauf immer positiv) und in eine Variable für OB1 speichern, neuen Zählerstand speichern
Tip: Für mehr Messwert-Genauigkeit/Glättung/Beruhigung 10 Messperioden je 10*13.6 ms = 136 ms ineinander schachteln. Ringpuffer (Array) für ca. 10 Werte Start-Zählerstand für 10 Differenzen. So gibt es alle 13.6 ms einen neuen Messwert mit Messzeit 136 ms. Das Arbeiten mit dem Ringpuffer multitasking-sicher im OB40 programmieren.
Im OB1 skalieren: ungefähr 0/1..34 = 0..100%
Das sollte so funktionieren und für den Lüfter genau genug sein.
Was noch zu klären ist:
- Wie groß/kurz ist die Mindest-Pulsdauer des PWM-Signals?
- Wie verhält sich das Signal bei 100% ? Mindest-Pausendauer?
Harald
