digitalwerk community: hiddenhttps://support.digitalwerk.net/https://support.digitalwerk.net/themes/digitalwerk_theme/favicon/dw.ico?16823609612020-05-05T13:29:12Zdigitalwerk community
Redmine Public Support - Support Request #11153: Rename Stream Names within ADTF2 DAT Filehttps://support.digitalwerk.net/issues/11153#change-469652020-05-05T13:29:12Zhidden
<p>Hallo Florian,</p>
<p>Danke für die Infos.<br />Wir haben diverse PostProcessing Tools die auf den DAT Dateien arbeiten und die Daten über Stream Namen identifizieren.<br />Wenn sich diese Stream Namen nun ändern, weil Themen zusammen gelegt werden o.ä., dann müssen diese Tools angepasst werden.<br />Das ist leider immer mit Aufwand verbunden und leider auch immer ein Grund für Zulieferer Projekttermine in Frage zu stellen.</p>
<p>Darum wäre es sehr hilfreich wenn man ein kleines Consolen Tool oder eine Python Lib haben könnte, die eben einfach nur einen Stream umbenennt.<br />Gut wäre hier natürlich auch, wenn in dem Zuge nicht Gigabyte-weise Daten gelesen und geschrieben werden müssen.</p>
<p>Über C++ das ganze Hex zu machen geht nur wenn der Stream Namen in der Länge unverändert ist. <br />Das geht auch mit einem Hex Editor aber eben nur wenn der String gleich lang ist.</p>
<p>Wie kann so ein Prozessor realisiert werden?<br />Mit der ADTF File Lib?<br />Das über ein ADTF Projekt mit Harddisk-Player und Recorder zu lösen wäre arg aufwändig.</p>
<p>Viele Grüße<br />Wolfgang</p> Public Support - Support Request #11153 (Closed): Rename Stream Names within ADTF2 DAT Filehttps://support.digitalwerk.net/issues/111532020-05-05T12:00:12Zhidden
<p><strong>Supportanfrage</strong></p>
<p>wie gerade besprochen sind wir gerade am Umstellen unserer ADTF2 Konfig und dabei machen uns immer wieder andere Stream Namen im PostProcessing das Leben schwer.<br />Gibt es eine einfache Möglichkeit über die DAT Tool, ADTF File Lib usw. die Stream Namen in einer ADTF2 DAT Datei umzubenennen?</p>
<p><strong>Lösung</strong></p>
<p>Das ist mit der IFHD möglich, siehe Bsp. <a class="attachment" href="https://support.digitalwerk.net/attachments/14608">dat_stream_rename.zip</a><br />Das wollen wir auch ins dat tooling integrieren -> CDIFHD-91 erstellt</p> Public Support - Support Request #7954: Multi-Cast UDP Data Cature with Ethernet_Device_UDPhttps://support.digitalwerk.net/issues/7954#change-334852019-07-26T09:04:13Zhidden
<p>Hallo Florian,<br />danke für die Rückmeldung.<br />Heißt das, dass es auch mit einer Broadcast IP funktionieren müsste, wenn der entsprechende Parameter aktiv ist?<br />Viele Grüße<br />Wolfgang</p> Public Support - Support Request #7954 (Closed): Multi-Cast UDP Data Cature with Ethernet_Device_UDPhttps://support.digitalwerk.net/issues/79542019-07-25T18:17:29Zhidden
<p><strong>Suportanfrage</strong></p>
<p>Wir möchten einen UDP Datenstrom der als MultiCast versendet wird mit dem Ethernet Device UDP aufzeichnen.<br />Der Filter ist doch von Euch oder?<br />Sollte das funktionieren, wenn wir eine MultiCast Adresse nutzen?<br />Ich frage deshalb, weil der Filter die Verwendung einer Broadcast IP Adresse als Ziel offensichtlich nicht unterstüzt.<br />Könntest Du das bitte klären ob das gehen sollte? <br />Wir haben nächste Woche einen Test im Fahrzeug damit und ich würde gerne wissen ob es prinzipiell geht oder nicht.</p>
<p><strong>Lösung</strong></p>
<p>Der Filter ist Bestandteil der Device Toolbox, hier wird auch der Source Code geliefert und kann angepasst und debugged werden, deshalb gibt es hierfür auch keinen Support mehr, siehe <a href="https://support.digitalwerk.net/adtf_addons/adtf-device-toolbox/v2/devicetoolbox.pdf" class="external">Kap 7 Ethernet ff</a>.</p>
<p>PS: Trotzdem sollte es imho anhand von Multicast IP und aktivierten Broadcast funktionieren.</p> Public Support - Support Request #5206: Export CAN-FD to ASC or MDF3 / MDF4https://support.digitalwerk.net/issues/5206#change-222552018-12-11T16:19:32Zhidden
<p>Hallo Florian,<br />kann ich den MDF4 Exporter von ADTF3 auch mit den ADTF2 DAT-files nutzen?<br />Grüße<br />Wolfgang</p> Public Support - Support Request #5181: Support for harmonized UTF-8 Supporthttps://support.digitalwerk.net/issues/5181#change-222432018-12-11T13:04:22Zhidden
<p>Das Coding in der system.xml ist als ISO8859-1 in der Datei definiert.<br />Das Coding wird doch i.d.R. vom XML Parser vorgegeben bzw. entsprechend genutzt.<br />Am Ende müssen alle beteiligten Komponenten hier eine einheitliche Linie fahren und auch die Settings in der xml Datei müssen dazu passen.<br />Würde mich wundern, wenn eine Datei die von ADTF geschrieben wird so einfach konvertiert werden kann und dann soll alles funktionieren?</p>
<p>Aber wie schon gesagt ist das kein dringliches Problem.<br />Dann müssen die Kollegen eben bis auf weiteres darauf achten keine Umlaute in den Pfaden zu nutzen.<br />Aber für ADTF3 wäre es natürlich wünschenswert dass das Zeichenhandling dort in Pfaden usw. passt.</p> Public Support - Support Request #5206 (Closed): Export CAN-FD to ASC or MDF3 / MDF4https://support.digitalwerk.net/issues/52062018-12-07T14:06:26Zhidden
<p><strong>Supportanfrage</strong></p>
<p>Gibt es in ADTF eine Möglichkeit CAN-FD Streams nach MDF3 oder MDF4 oder ASC zu exportieren?</p>
<p><strong>Lösung</strong></p>
<p>In ADTF 2.x nicht, weil es ja keinen CAN-FD Support, zumindest seitens ADTF Core / Device TB gibt.<br />In ADTF 3.x gibt es CAN-FD seitens Device Toolbox, ebenso ein entsprechend Processor, um ASC und MF4 zu extrahieren.</p> Public Support - Support Request #5182: Could not export ASC from Flexray stream without FIBEXhttps://support.digitalwerk.net/issues/5182#change-220682018-12-07T09:56:31Zhidden
<p>Hallo Florian,<br />das ASC Formt ist ein Rohdatenformat bei dem ein zwingendes Vorhandensein eine Fibex Files nicht erforderlich sein sollte.</p>
<p>Zudem werden bei Daimler nur noch ARXML Dateien bereitgestellt und Fibex kann nur noch über einen Umweg eines alten nicht mehr gepflegten Konverters erzeugt werden. Dieser Weg ist allerdings mit Autosar 4.3 auch nicht mehr möglich.</p>
<p>Wenn der Wert 64 falsch ist, weil willkürlich ausgewählt, könnte ggf, auch einfach per Parameter ein Wert einstellbar sein. So kann der Benutzer immerhin noch selber wählen was passieren soll.</p>
<p>Der jetztige Weg ist aber mit Abstand der schlechteste weil die vorherige Funktion, ein Export ohne Fibex, einfach entfallen ist.<br />Daher meine Bitte den Exporter so zu erweitern, dass das Fibex als Optional anzusehen ist.</p>
<p>Viele Grüße<br />Wolfgang</p> Public Support - Support Request #5181: Support for harmonized UTF-8 Supporthttps://support.digitalwerk.net/issues/5181#change-220492018-12-07T09:32:58Zhidden
<p>Der Workaround ist, dass der Benutzer keine Umlaute oder andere Sonderzeichen in Dateinamen nutzen darf.<br />Könnte das nicht auf ein Problem mit dem Coding hindeuten?<br />ISO8859-15 oder UT8?<br />Vielleicht liegt es ja "nur" daran dass verschiedene Komponenten ein unterschiedliches Coding nutzen?</p> Public Support - Support Request #5181 (Closed): Support for harmonized UTF-8 Supporthttps://support.digitalwerk.net/issues/51812018-12-06T18:48:11Zhidden
<p><strong>Supportanfrage</strong></p>
<p>Bei XKrug haben wir ein Problem in deren ADTF flexray signal sender gemeldet (Ticket #8542) das wiederum auf ein Fehlverhalten innerhalb von ADTF schliesen lässt. <br />Nachstehend die Aussage von Jürgen Bubeck von XKrug mit der Bitte um Bearbeitung:</p>
<p>Der vom Parser gemeldete Fehler prüft auf Existenz der Datei und verhindert einen Crash des kompletten ADTF_Programms. Dieser würde auftreten, wenn die Systembibliothek einen ungültigen Dateinamen übergeben bekommen würde.</p>
<p>Grund:<br />ADTF liefert für das Property mit dem Dateipfad einen ASCII Character Array. Die Weiterverwendung dieses Strings ist bei der Nutzung von Umlauten o.Ä. nicht möglich, d.h. die angefragte Datei ist nicht auffindbar.<br />Das Verhalten ist von unserer Seite nicht behebbar.<br />Bitte diesen Fehler beim ADTF Support melden.</p>
<p>Workaround:<br />Bis einmal eine ADTF-Version existiert, die Properties als Unicode verarbeitet, kann ASCII ohne Probleme verwendet werden.</p>
<p><strong>Lösung</strong></p>
<p>Ja genau. Der Configuration Editor verwendet kein UTF-8 sondern für die Umlaute letztendlich ASCII-Extended Codes. Die libc versteht aber nur ASCII und UTF-8. Wenn man die Konfigurationsdatei (system.xml) händisch in UTF-8 konvertiert, kriegen die Filter auch korrekte UTF-8 Strings und dann klappen auch die cFileSystem::Exists und cFile::Open Calls wie erwartet.</p>
UTF-8 Support wird in den GUI Komponenten von ADTF2 nicht mehr Einzug halten, bleiben also leider nur die zwei Workarounds:
<ul>
<li>Keine Dateinamen mit Umlauten etc. verwenden.</li>
<li>system.xml manuell nach UTF-8 konvertieren.</li>
</ul>