Public Support

Supportanfrage

aktuell implementiere ich einen Filter, der unten aufgeführten Funktionalitäten besitzt und möchte Sie über die Unterstützung bei der Umsetzungs-Vorgehensweise bitten.

Unten habe ich drei Methoden aufgelistet, die ich aktuell als geeignet für die Filterumsetzung finde. Welche von dieser Methoden würde aus Ihrer Sicht am besten passen?
Oder gibt es vielleicht eine bessere Lösung für dieses Problem?

Filterfunktionalitäten:

1. Bestimmte Ausgangssignale von festgelegten Filtern in dem Filtegraph beobachten (standardmäßig alle Signale von allen Filtern in dem Filtergraph)

2. Bei der Änderung der festgelegten Ausgangssignalen die Werte von diesen Signalen in einen File speichern.

3. Keine Verdrahtung zwischen diesem Filter und allen anderen Filtern in dem Filtergraph

4. Die Signale müssen zeitlich korrekt gespeichert werden, d.h. wenn eine Signaländerung bei allen Filtern in einem folgenden Filtergraph stattfindet: Filter1->Filter2->Filter3, müssen die Signale auch in einer gleiche Reihenfolge geschrieben werden Filter1(Signal1), Filter2(Signal2), Filter3(Signal3).

Methoden, die ich bisher als passend identifiziert habe:

1. Eine "virtuelle" SampleStream nutzen (die nicht im Filtergraph auftaucht) -> anlegen einer SampleStream im Filter/ServiceCode und Registrierung bei den ADTF-Diensten, um die Daten abgreifen zu können.

2. Substream-Konzept nutzen, in dem man die Ausgänge von den anderen Filtern als Substreams definiert und in den zu entwickelnden Filter einspeist.

3. Signal-Listener-Service (über Signal Registry) verwenden, wie es in dem Beispiel Demo_Signal_Listener gezeigt ist. -> Diese Lösung funktioniert wahrscheinlich am einfachsten, ich bin mir da aber nicht sicher wegen der Warnhinweis in der Dokumentation: "Warning: Please be aware that you must not use the Signal Registry to transmit data. You cannot rely on an accurately timed notification about incoming new values."

Vielen Dank im Voraus!

Lösung

1. Bestimmte Ausgangssignale von festgelegten Filtern in dem Filtegraph beobachten (standardmäßig alle Signale von allen Filtern in dem Filtergraph)
2. Bei der Änderung der festgelegten Ausgangssignalen die Werte von diesen Signalen in einen File speichern.

Wenn ich dich richtig verstehe, möchtest du eine Art Watchdog / Monitoring Filter schreiben richtig ?

3. Keine Verdrahtung zwischen diesem Filter und allen anderen Filtern in dem Filtergraph

Geht es dir dabei rein um den Aufwand Vebrindungen ziehen zu müssen ?
Wenn ja, dann haben wir hierzu bereits Möglichkeiten zur Automatisierung und künftig ggf. noch mehr Richtung Autoconnect.

4. Die Signale müssen zeitlich korrekt gespeichert werden, d.h. wenn eine Signaländerung bei allen Filtern in einem folgenden Filtergraph stattfindet: Filter1->Filter2->Filter3, müssen die Signale auch in einer gleiche Reihenfolge geschrieben werden Filter1(Signal1), Filter2(Signal2), Filter3(Signal3).

Das garantiert dir ADTF bei sequentieller Abarbeitung und Zeitstempelung.

1. Eine "virtuelle" SampleStream nutzen (die nicht im Filtergraph auftaucht) -> anlegen einer SampleStream im Filter/ServiceCode und Registrierung bei den ADTF-Diensten, um die Daten abgreifen zu können.

2. Substream-Konzept nutzen, in dem man die Ausgänge von den anderen Filtern als Substreams definiert und in den zu entwickelnden Filter einspeist.

3. Signal-Listener-Service (über Signal Registry) verwenden, wie es in dem Beispiel Demo_Signal_Listener gezeigt ist.

Du könntest Daten ohne "Verbinung" bewerten so wie es z.B. der Sample Stream Trace View macht, allerdings möchtest du ja Werte valdieren, deshalb bleibt dir nur die Möglichkeit deinen Filter zu verbinden (Sample) Ebene oder dich an die Signal Registry zu hängen (Signalebene, keine Verbindung).

Ich meine auch, dass du nicht alle Daten abgreifen kannst (dynamische Arrays z.B. gehen nicht in der Signal Registry).

Die Substreams sehe ich hier nicht, das ist nur eine Übertragungsmöglichkeit, ändert aber nichts daran, Verbindungen ziehen zu müssen.
Du kannst auch nicht einfach mehrere (sub)streams an einen Pin hängen, ADTF erlaub immer nur eine eingehende Verbindung, d.h. egal wie und wo du multiplexed, die Eingangsverbindungen müssen existieren.

-> Diese Lösung funktioniert wahrscheinlich am einfachsten, ich bin mir da aber nicht sicher wegen der Warnhinweis in der Dokumentation: "Warning: Please be aware that you must not use the Signal Registry to transmit data. You cannot rely on an accurately timed notification about incoming new values."

Damit ist gemeint, dass zur Übertragung von Nutzdaten ausschließlich das Data Streaming verwendet werden soll.
Die Signal Registry soll nicht dafür missbraucht werden, Daten auszutauschen.
Sie kann aber zusätzlich für Event Checks und zur Visualsierung hergenommen werden, aber nur für Daten, die ohnehin im Streaming übertragen werden.