USBDMX-Interface von DE mit Autoit ansteuern

Die usbdmx.dll lässt sich mit einfachen DllCalls ansprechen. Da liegen doch sogar Beispiele bei, einfach mal ein wenig ausprobieren!

https://www.autoitscript.com/autoit3/docs/functions/DllCall.htm
https://www.autoitscript.com/forum/topic/93…all-dllstructs/
http://bug-fix.info/dll/dll_tut.html
https://www.vanstechelman.eu/content/autoit-dllcall-examples
Forensuche: DllCall

Yjug, was ist denn TSERIAL für ein Typ (Objektinstanz?). Kann man den Typ überhaupt mit AutoIt aufrufen?

Z.B. bei SetInterfaceMode(Serial: TSERIAL; Mode: byte): DWORD;

-> SetInterfaceMode ist die Methode
-> Serial ist der erste Parameter, der hat als Typ TSERIAL
-> Mode ist der zweite Parameter, Typ: byte
-> :DWORD ist wahrscheinlich der Rückgabewert der Methode

Die möglichen Typen kannst du hier einsehen: DLLCall

Lg NO1

Zitat von NO1 :-)

Yjug, was ist denn TSERIAL für ein Typ (Objektinstanz?). Kann man den Typ überhaupt mit AutoIt aufrufen?

Du musst schauen um was es sich genau handelt. Ist es ein TypeDef, so kannst du einfach den originalen Typen nehmen.
Bei Strukturen musst du die Struktur in AutoIt mit den DLL-Funktionen nachbauen und dann übergeben.

Zitat von NO1 :-)

Yjug, was ist denn TSERIAL für ein Typ (Objektinstanz?). Kann man den Typ überhaupt mit AutoIt aufrufen?

Ein "Objekt" und die daraus resultierenden "Objektinstanzen" sind auch nur Strukturen im Arbeitsspeicher. Solche lassen sich IMMER ansprechen, egal um welche Programmiersprache es sich dabei handelt. Du kannst in AutoIt auch mit Objektinstanzen arbeiten, habe dies schon getan.

Die Typedefinitionen sind in der usbdmx_example.cpp hinterlegt. Diese sehen folgendermaßen aus:

typedef unsigned char TDMXArray[512];
typedef char TSERIAL[16];
typedef TSERIAL TSERIALLIST[32];
typedef void (STDCALL* THOSTDEVICECHANGEPROC) (void);

Ich hoffe dies beantwortet deine Frage.

€dit: By the way, der letzte Buchstabe ist ein kleines "Q" - kein "G".

Aso danke alpines und Yjuq, hab die .cpp Datei gar net beachtet.
Und tschuldigung für das "G"...

Zitat von alpines

Du musst schauen um was es sich genau handelt. Ist es ein TypeDef, so kannst du einfach den originalen Typen nehmen.
Bei Strukturen musst du die Struktur in AutoIt mit den DLL-Funktionen nachbauen und dann übergeben.

Im Prinzip brauchst du das gar nicht mal. Du musst nur sichergehen dass du genug Speicher im Arbeitsspeicher reservierst und diese mit sinnvollen Werten für die Funktionen an der richtigen Stelle befüllst. Wie die Struktur letztendlich aussieht (ob es nur ein byte Array ist) ist komplett irrelevant.

Zitat von Yjuq

Du musst nur sichergehen dass du genug Speicher im Arbeitsspeicher definierst und diese mit sinnvollen Werten für die Funktionen an der richtigen Stelle befüllst. Wie die Struktur letztendlich aussieht (ob es nur ein byte Array ist) ist komplett irrelevant.

Toll, das ist wie wenn ich sage: Wenn ich alle Einzelteile von einem Auto richtig platziere habe ich ein funktionierendes Auto.
Aber meiner Meinung nach ist es sinnvoller die Teile sinnvoll zusammenzubauen indem man sie richtig beschriftet und dann übergibt.

Ich schreibe ja auch nicht den Bytecode für meine Programme mittels eines Hex-Editors in eine neue Datei sondern programmiere und lass ihn compilen.
Dafür sind diese TypeDefs und Strukturen ja auch da, damit es der Programmierer leichter hat.

Ich wollte es nur erwähnt haben, da du das Wort "musst" genannt hast.

Zitat von Norbertttt

Vielleicht schaut mal jemand darüber und bringt es zum Laufen.

Das wird so schon nicht hinhauen, weil du beim Pointer immer den String "$DMXOut" und nicht die Variable übergibst.

Hey! Das ist ja mal was - Und das ohne dich dazu aufzufordern!

Lass es mich mal erklären: Ich investiere ungern meine Zeit für ein fremdes Problem wenn der Fragestellende nicht auch daran interessiert ist und es tatsächlich selber versucht. Da du hier neu im Forum bist habe ich natürlich kein Bild über dich und dein Startpost hat mich eher vermuten lassen dass du keine Eigeninitiative an dem Problem besitzt. Daher sind die Antworten von mir auch so lieblos "mau" gewesen. Ich bin aber froh dass du uns hier zumindest ein Skript zeigst, wo du es selber einmal versucht hast. Das ist wichtig! Niemand will kostenfrei für andere arbeiten, aber jemanden wirklich Unterstützung zu bieten der es sich selber erarbeiten will ist wieder was anderes.

Ich wollte eigentlich schauen wie lange es dauert bis du entweder:
1.: Genervt das Forum verlässt oder
2.: Ich was sagen muss damit von dir dazu was passendes kommt

Da aber gleich dein 3ter Beitrag hier schon produktiv war bin ich jetzt Feuer und Flamme für dein Problem und opfere meine Aufmerksamkeit und meine Zeit dafür!

---

Also, erst einmal kenne ich die USBDMX Dll nicht. Ich habe keine Ahnung worum es sich dabei handelt noch was sie tut. Ich habe lediglich bisher fix in die Beispielcodes geschaut um mir ein groben Überblick zu verschaffen. Da mir auch die Hardware fehlt um gescheit Skripte testen zu können. Bedeutet also für dich dass du meine Hilfestellungen für mich testen musst - Macht aber nichts, ich kann dir trotz allem dabei helfen die DllCalls korrekt aufzubauen. Ich schau mir mal dein Skript näher an und lese mich ein wenig in die DLL ein. Zudem stöber ich mal etwas genauer durch die ZIP-Datei. Brauche jedoch selber ein wenig Zeit um mir das alles genauer anzuschauen.

Bis dahin wollte ich dich nur wissen lassen dass es jemanden gibt der sich jetzt ernsthaft damit befasst.

Hey, ich hab da was. Probier mal folgendes aus:

; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


#AutoIt3Wrapper_UseX64 = N


#include <Array.au3>
#include <MsgBoxConstants.au3>


Global Const $hUSBDMX = DllOpen("usbdmxsi")
Global $tOutArray, $tInArray, $iResult


; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


$iResult = _USBDMX_OpenInterface($hUSBDMX, $tOutArray, $tInArray, 2)
MsgBox($MB_TOPMOST, "Info - Open", "Rückmeldung: " & $iResult)


For $i = 1 To 512
	$tOutArray.data(($i)) = 50
Next


$iResult = _USBDMX_CloseInterface($hUSBDMX)
MsgBox($MB_TOPMOST, "Info - Open", "Rückmeldung: " & $iResult)


; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


DllClose($hUSBDMX)


; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +


Func _USBDMX_OpenInterface($hDLL, ByRef $DMXOutArray, ByRef $DMXInArray, $Mode)
	$DMXOutArray = DllStructCreate("byte data[512]")
	$DMXInArray  = DllStructCreate("byte data[512]")


	Return DllCall($hDLL, "dword", "OpenInterface", _
		"ptr", DllStructGetPtr($DMXOutArray), _
		"ptr", DllStructGetPtr($DMXInArray), _
		"byte", $Mode)[0]
EndFunc




Func _USBDMX_CloseInterface($hDLL)
	Return DllCall($hDLL, "dword", "CloseInterface")[0]
EndFunc


; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

Das sollte zumindest die falschen DllCalls beheben. Jetzt musst du nur noch entsprechend ein wenig damit herum spielen und testen. Falls es Probleme gibt sag bescheid!
Wie gesagt, ich kann es leider nicht selber testen.

Zitat von Yjuq

Return DllCall($hDLL, "dword", "OpenInterface", _
"ptr", DllStructGetPtr($DMXOutArray), _
"ptr", DllStructGetPtr($DMXInArray), _
"byte", $Mode)[0]

Uiuiuiui Kollege, das wollen wir uns mal abgewöhnen!

Auf keinen Fall den Return vom DllCall als Array direkt ansprechen, das kann ganz schnell nach hinten losgehen.
Rückgabewert oder @error erst prüfen und dann zugreifen!

Ich hasse Error-Handling. Ich hab es schon immer gehasst, wieso kann man nicht davon ausgehen dass der Programmierer es richtig macht? Es reicht doch wenn man User-Fehlerquellen schon ausmerzt... Ich hasse das und Java ebenfalls

Aber hast ja recht, normalerweise sollte es so nicht sein. Aber ich bin nun mal ein wenig faul wenn ich ein wenig herumspiele mit AutoIt Code. Aber sollte es ein @error Code schmeißen dann gibt's kein Array und das Programm stürzt ab. Das reicht doch als Hinweis aus

Zitat von Yjuq

Aber hast ja recht, normalerweise sollte es so nicht sein. Aber ich bin nun mal ein wenig faul wenn ich ein wenig herumspiele mit AutoIt Code. Aber sollte es ein @error Code schmeißen dann gibt's kein Array und das Programm stürzt ab. Das reicht doch als Hinweis aus

Nenenene, so machen wir das hier nicht! Stell dir mal vor jeder würde so denken und der Boardcomputer in einem Flugzeug oder in einem Tower stürzt ab!
Error-Handling ist mies, ich weiß aber es gehört nun mal dazu. Zumindest so weit, dass das Programm weiterlaufen kann und man weiß was passiert ist.