Public Support

Hallo Florian,

vielen Dank für die Infos und das Beispiel. Wir werden probieren, ob wir damit zurecht kommen.
Eine schnelle Lösung seitens dSpace ist hier leider auch nicht zu erwarten. Kannst du uns deshalb vielleicht ein paar mehr Informationen über IPC UDP zukommen lassen kannst. Vielleicht ist es ja mit verhältnismäßigem Aufwand implementierbar. Wenn nicht, brauchen wir langfristig ohnehin eine Lösung seitens dSpace.
Von der Verbindung her werden wir wohl erst mal bei UDP bleiben, da es für allgemeine UDP-Verbindungen definitiv ein Blockset von dSpace gibt.

Viele Grüße
Franz

Hi Frank,

die ADTF3 Message Bus Implementierung ist genau aus der Anforderung entstanden die "alte" ADTF2 dSpace Autobox Anbindung wieder einsetzen zu können. Ich kenne dSpace VEOS jetzt selbst nicht, denke aber das sollte klappen.

Wenn es eine allgemeine UDP Verbindung von seitens dSpace gibt, solltet Ihr das auf jeden Fall auch mit unseren "Demo UDP Sender To Non-ADTF Application" und "Demo UDP Receiver From Non-ADTF Application" Filtern bedienen können: https://support.digitalwerk.net/adtf/v3/adtf_html/page_demo_non_adtf_application_udp_sender_receiver.html

Bzgl. ADTF ICP Sinks und Sourcen: Die Kommunikation darin werden wir aus verschiedenen Gründen nicht offenlegen, wir bieten aber eine C++Library zu Integration in nicht-ADTF Applikationen an. Diese basiert aber auf einem gekapselten ADTF3 Subsystem, sodass sie nur auf den von ADTF3 direkt unterstützen Platformen lauffähig ist: https://support.digitalwerk.net/adtf/v3/adtf_html/page_demo_adtf_ipc_integration.html

Grüße,

Martin

Hallo,

vielen Dank für die Infos. Wenn es mit der Autobox klappt, sollte es mit VEOS auch gehen. Wir werden diesen Ansatz als erstes probieren.
Dazu haben wir uns auch schon die Demo angeschaut, die ihr uns gesagt habt:
https://www.cip.audi.de/bitbucket/projects/OPENDEV/repos/adtf_community/browse

Dazu hätten wir noch eine Frage: Wir haben in dem Beispiel die Plugin-Datei nicht gefunden. Muss man sich das selbst kompilieren? Oder liegt das wo anders schon fertig ab? Wir warten leider immer noch auf unsere Visual-Studio Installation. :-/

Außerdem habe ich in der Demo jetzt nur den Fall gefunden, dass ADTF etwas empfängt. Gibt es auch ein Beispiel zum Senden von Daten?

Viele Grüße
Franz

Hallo Franz,

Wir haben in dem Beispiel die Plugin-Datei nicht gefunden. Muss man sich das selbst kompilieren? Oder liegt das wo anders schon fertig ab? Wir warten leider immer noch auf unsere Visual-Studio Installation.

Richtig, dass ist ein reines Git Repo, Source Code, keine Binaries.
Wir können sie euch gerne kompilieren, wenn ihr derzeit keine Build Umgebung habt.
Ich nehme an es geht um Windows ?

Außerdem habe ich in der Demo jetzt nur den Fall gefunden, dass ADTF etwas empfängt. Gibt es auch ein Beispiel zum Senden von Daten?

• Source zum Empfang der Daten
• Sink für die Senderichtung

Hi,

das wäre super, wenn ihr uns die einmal kompilieren könntet!
Ja genau, wir nutzen momentan Windows. Danke!

Ok, dann schau ich mir das nochmal genauer an.

Viele Grüße
Franz

Hi Franz,

ich kanns nicht ganz nachvollziehen, bzw. bei mir klappts. Hier mein Vorgehen:

• Ich hab das Beispiel ADTF3 Projekt geöffnet.
• Beim Media Description Service in den Properties euer .description File angegeben (anstatt des bisherigen)
• Bei der Source dann unter "struct_name" "tmy_adtf_message" eingetragen und das ganze laufen gelassen.

Dann läuft es bei mir, aber mangels Gegenstelle sehe ich natürlich keine Daten.

Kannst Du euren Absturz und euer Vorgehen noch genauer beschreiben?

Grüße,

Maritn

Hallo Martin,

Ok, das wundert mich. Wir werden es nochmal probieren und es dir dann genauer beschreiben, wenn es wieder nicht geht. Die Kollegin ist nur heute leider krank.
Hast du beim stream_name auch etwas angepasst?

Viele Grüße
Franz

Hast du beim stream_name auch etwas angepasst?

nein habe ich nicht. Das bestimmt "nur" den Namen der Messages auf dem Bus. Der sollte für jede Source/Sink eindeutig sein. Da weiß ich leider nicht genau, was die Autobox da schickt bzw was sie erwartet. Da muss man letztendlich den Namen das Ports des Subgraphen aus der entsprechenden ADTF2 Config eintragen.

Grüße,

Martin

Hallo Martin,

danke für den Tipp. Damit läuft es jetzt endlich und wir können sogar auch senden. ☺
Ich hätte nun noch 3 Fragen zur best practise:
Muss man jetzt je Stream ein eigenes Decode-Plugin einbauen oder kann der auch mehrere Streams? Gilt das gleiche für die Sink?
Wie werden die Descripton-Files der Sink erstellt. In ADTF2 gab es da einen Editor. Gibt es hier auch etwas ähnliches, oder muss man sich die Dateien selbst schreiben?

Viele Grüße
Franz

Muss man jetzt je Stream ein eigenes Decode-Plugin einbauen oder kann der auch mehrere Streams? Gilt das gleiche für die Sink?

Meinst Du mit Decode Plugin die Source?

Ja da braucht's für jeden Stream eine eigene. Dadurch gibts ein 1:1 mapping zwischen den Properties und den Datenströmen.
Channel können sich aber alle Sinks und Sources ein und dieselbe Instanz teilen.

Wie werden die Descripton-Files der Sink erstellt. In ADTF2 gab es da einen Editor. Gibt es hier auch etwas ähnliches, oder muss man sich die Dateien selbst schreiben?

in <adtf_dir>/3rdparty/ddl_editor/bin gibts wieder so einen Editor. Ihr könnt aber auch den von ADTF2 weiterverwenden.

Es gibt aber eigentlich keine Grund da neue Description Dateien zu erstellen. Die aus eurer ADTF2 Konfiguration könnt ihr unverändert übernehmen.

Grüße,

Martin