(30.01.2014 16:14 )Klausenwirt schrieb: Zu dem "Klimbis": Ich habe Beitrag #8 umgesetzt und der DLL nur die tatsächliche Länge mitgeteilt.
In diesem SubVi bin ich immer noch am PC, die Daten werden erst viel später an ein serielles Gerät übertragen. Es erwartet auch keinen Carriage Return und/oder Linefeed am Ende.
Die Funktion berechnet einen CRC-Wert des Eingangsstrings. Sie liefert mir auch das richtige Ergebnis, das habe ich schon überprüft. Es hat der Fall, dass bei längeren Tests LabVIEW abstürzt, wenn ich diese DLL verwende.
Wenn es mit dieser Konfiguration Fehler gibt dann ist eine Überprüfung der DLL selber sicher angesagt. Da wird irgendwas in der DLL gemacht was nicht kosher ist. Also alle Arrayindexierungen, Datentypen usw in der DLL selber überprüfen. Aber wahrscheinlich ist es viel schneller um die ganze CRC Berechnung gleich mal in LabVIEW zu implementieren, so wie schon von Jens vorgeschlagen. C(++) Programmierung ist nicht einfach, erfordert sehr genaues Arbeiten und viel Mühe um überhaupt die Basisstruktur betreffend Speicherverwaltung und korrekte Handhabung einzuhalten und bietetet ungezählte Möglichkeiten um den Speicher zu zerschiessen. Die meisten dieser Problem hast Du in LabVIEW gar nicht und kannst Dich deswegen auf das Wesentliche konzentrieren.
(30.01.2014 16:35 )Klausenwirt schrieb: Ich kenne LabVIEW erst seit ein paar Monaten (das kommt jetzt nicht überraschend) und möchte DLL-Dateien gernen einbinden können. Mit dieser DLL will ichs lernen.
Dann tue das mit einer DLL die bewiesenermassen fehlerfrei ist. Ansonsten vertust Du Deine Zeit mit dem Debuggen der Call Library Node Konfiguration, derweil das Problem im C Code in der DLL ist!
Noch ein anderer Gedanke: Macht die DLL irgendwas mit dem CommandString? Denn ansonsten macht es überhaupt keinen Sinn um für einen Eingabestring auch noch einen extra Parameter mitzugeben der die Länge dieses Strings mitteilt. Den der C String wird ja durch ein NULL Byte abgeschlossen so dass eine vernünftig porgrammierte Funktion das daran schon erkennen kann. Oder hat der Programmierer eigentlich gedacht dass dieser Parameter ein Bytearray sein sollte, also gar kein String und deshalb nicht mal ein NULL Byte Terminator nötig wäre. Den char* kann in C entweder ein Singlebyte String sein, ein Bytearray, oder ein einzelner Character oder Byte das als Referenz genommen wird. C ist in dieser Hinsicht extrem doppelsinnig und das ist auch eines der Probleme der C Syntax. Sie ist in den meisten Fällen nicht genügend um eine eindeutige Bestimming der Bedeutung von Parametern zu machen. Da braucht man sehr oft extra Informationen, teils implizit aus Namenskonventionen (was aber auch schwer in die Hosen gehen kann) und weiterer Dokumentation in Form einer API Beschreibung oder zumindest Beispielcode.
