Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
26.12.2020, 13:50 (Dieser Beitrag wurde zuletzt bearbeitet: 26.12.2020 20:40 von hansi9990.)
Zunächst mal wünsche ich euch allen ein schönes Weihnachtsfest.
Nun zu meiner Frage, ich habe hier die dll des Modulherstellers Deditec importiert, hier gibt es eine Funktion die sich "DapiOpenModuleEx" nennt mit der man ein Modul mit Parameter öffnen kann.
Diese Parameter sind die IP Adresse, der Port und einTimeout.
Die Beschreibung zu dieser Funktion sieht so aus:
Zitat:Beschreibung:
Diese Funktion öffnet gezielt ein Modul mit Ethernet-Schnittstelle. Dabei
können die Parameter IP-Adresse, Portnummer und die Dauer des Timeouts
bestimmt werden.
Das Öffnen des Moduls geschieht dabei unabhängig von den im DELIB
Configuration Utility getroffenen Einstellungen.
Parameter:
moduleID = Gibt das Modul an, welches geöffnet werden soll (siehe delib.h)
nr = Gibt an, welches (bei mehreren Modulen) geöffnet werden soll.
nr = 0 -> 1. Modul
nr = 1 -> 2. Modul
exbuffer = Buffer für IP-Adresse, Portnummer und Dauer des Timeouts
Return-Wert:
handle = Entsprechender Handle für das Modul
handle = 0 -> Modul wurde nicht gefunden
Bemerkung:
Der von dieser Funktion zurückgegebene Handle wird zur Identifikation des
Moduls für alle anderen Funktionen benötigt.
Dieser Befehl wird von allen Modulen mit Ethernet-Schnittstelle unterstützt.
Da jedoch der Eingang am Knoten als String (C-String-Zeiger) definiert ist (siehe Bild im Anhang), jeodch drei Parameter übergeben werden sollen und ich in Sachen C keine Erfahrung habe, frag ich mich wie die übergenenen Daten an dem String-Eingang aussehen müssten.
Kann mir hier jemand einenTipp geben, werden die eizelnen Parameter etwa mit Komma getrennt angegeben oder müssen hier irgendwelche Leeezeichen eingehalten werden?
Wenn das mit dem struct DAPI_OPENMODULEEX_STRUCT so stimmt, könntest du folgendes probieren:
Mach ein Array Of Char der Länge (256 + 8 + 8 + 8 +32). Bedenke, dass ein ulong acht Byte lang ist, also 64 Bit.
Fülle das ganze Array mit Nullen (0x00) auf.
Schreibe an die erste Stelle die IP-Adresse, z.B. "192.168.1.10" - und zwar in ASCII: String nach Array, Array ersetzen. Beachte, dass die erste Stelle den Index 0 hat.
Ab der (256+1). Stelle (die hat den Index 256) schreibst du den Timeout als 64bit-Binärzahl (= 8 Byte), und zwar beginnend mit dem höchstwertigen Teil.
Ab der (256+8+1). Stelle (die hat den Index 256+8) schreibst du den Port als 64bit-Binärzahl (= 8 Byte), und zwar beginnend mit dem höchstwertigen Teil.
Ab der (256+8+8+1). Stelle (die hat den Index 256+8+8) schreibst du den Encryption-Typ als 64bit-Binärzahl (= 8 Byte), und zwar beginnend mit dem höchstwertigen Teil. Offensichtlich ist dieser Wert 0.
Ab der (256+8+8+8+1). Stelle (die hat den Index 256+8+8+8) schreibst du das Passwort als 32 Byte langen String rein. Offensichtlich wird hier nichts benötigt. Beachte, dass dieser Bereich bereits mit Nullen gefüllt ist.
Dann einfach das Array of Char in einen String wandeln. Zur Kontrolle prüfst du, ob der String die richtige Länge hat: nämlich (256 + 8 + 8 + 8 +32). Diesen String hängst du an den DLL-Knoten, so wie in deinem Bild angegeben (oder an den entsprechenden Eingang des VIs, das den Code aus deinem Bild enthält).
Bevor du den ersten Test machst, speicherst du alles ab. Dann ist nämlich der Ärger nicht so groß, wenn infolge eines fehlerhaften Codes die LV-IDE abstürzt ...
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Danke für die Antwort.
Bist du absolut sicher das ein C ULONG in LabView als 64bit interpretiert wird?
Ich meine das wird in LV als 32bit Wert angesehen, zumindest steht das hier so https://zone.ni.com/reference/de-XX/help...pes_table/ und beim Import der dll wurden auch die ULONG als U32 umgewandelt.
(27.12.2020 15:04 )hansi9990 schrieb: Bist du absolut sicher das ein C ULONG in LabView als 64bit interpretiert wird?
Ein C ULong ist gemäß aller von mir gefundenen Beschreibungen ein 64-Bit-Wert. Folgedessen muss ja wohl LV auch 64 Bit machen. Im übrigen finde ich die LV-Bezeichnungen mit I8, I32 etc. besser als INT, LONG usw. Bei den LV-Bezeichnungen ist eindeutig I16 immer zwei Byte. Ein INT ist je nach Sprache 16 oder 32 Bit ...
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
27.12.2020, 16:55 (Dieser Beitrag wurde zuletzt bearbeitet: 27.12.2020 17:11 von hansi9990.)
(27.12.2020 15:04 )hansi9990 schrieb: Bist du absolut sicher das ein C ULONG in LabView als 64bit interpretiert wird?
Ein C ULong ist gemäß aller von mir gefundenen Beschreibungen ein 64-Bit-Wert. Folgedessen muss ja wohl LV auch 64 Bit machen. Im übrigen finde ich die LV-Bezeichnungen mit I8, I32 etc. besser als INT, LONG usw. Bei den LV-Bezeichnungen ist eindeutig I16 immer zwei Byte. Ein INT ist je nach Sprache 16 oder 32 Bit ...
Ich meine aber doch das 64bit in LabView ULONGLONG oder Unsigned double sein müsste, darum nennt sich sicher auch die Funktion zum umwandeln in ein U32 "To Unsigned Long Integer Function" https://zone.ni.com/reference/en-XX/help...g_integer/
(27.12.2020 17:23 )hansi9990 schrieb: Ich meine aber doch das 64bit in LabView ULONGLONG oder Unsigned double sein müsste, darum nennt sich sicher auch die Funktion zum umwandeln in ein U32 "To Unsigned Long Integer Function"
Probiers aus. Nimm zuerst U32. Scheint mir doch sinnvoller, weil das Modul doch schon von 2009 ist.
Das VI sollte so funktionieren, außer dem Enumerator. Der ist wie Standard u16, solltest du also auf u32 umstellen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Das mit dem falschen ENUM ist mir dann auch aufgefallen darum habe ich es in meinem Posting aktualisiert, evtl. hast du es vorher geladen.
Leider bekomme ich das I/O Modul erst noch, ich wollte nur vorher schon den Treiber anpassen.
02.01.2021, 16:36 (Dieser Beitrag wurde zuletzt bearbeitet: 02.01.2021 16:38 von rolfk.)
(27.12.2020 15:04 )hansi9990 schrieb: Bist du absolut sicher das ein C ULONG in LabView als 64bit interpretiert wird?
Ein C ULong ist gemäß aller von mir gefundenen Beschreibungen ein 64-Bit-Wert. Folgedessen muss ja wohl LV auch 64 Bit machen. Im übrigen finde ich die LV-Bezeichnungen mit I8, I32 etc. besser als INT, LONG usw. Bei den LV-Bezeichnungen ist eindeutig I16 immer zwei Byte. Ein INT ist je nach Sprache 16 oder 32 Bit ...
Nein. ULONG ist ein Windows Datentyp der als synonym für "unsigned long" dient. unsigned sagt einfach dass es ohne Vorzeichen ist und ist für die Grösse des Datentypes irrelevant. long is unter allen modernen 32-bit Systemen immer ein 32-bit Integer. In 64-bit Systemen ist es unter Unix typischerweise ein 64-bit Wert während Microsoft es als 32-bit Wert sehen will. https://docs.microsoft.com/en-us/openspe...faf985b822
Unter Windows muss man entweder "long long" oder den eindeutigeren "ïnt64_t" verwenden um einen 64-it integer zu bekommen. Und QWORD ist der Microsoft Windows spezifieke 64 Bit Datentyp. UINT64, ULONG64, und ULONGLONG sind andere mögliche Varianten die in Windows APIs als eindeutige 64-bit unsigned Integerdatentypen verwendet werden können.
Microsoft C spezifik kann man auch "__int64" verwenden, aber das ist nicht portable zu anderen C Compilern die nicht Microsoft C kompatibel zu sein versuchen. Es war in Visual C 2005 der Datentyp den man verwenden musste wenn man 64 bit Integer haben wollte.
Hallo Hansi,
die Fa. DEDITEC bietet eine ausführliche Beschreibung für die Einrichtung in LabView und wie man die VI von Ihnen über die DLL erzeugt.
Es werden da auch gewisse Änderungen bezüglich der 64 Bit in den VI Übergabe beschrieben.
