C# und DE Interface

Hallo,

ich habe gerade mal sharpdevelop angeworfen. Über die vorhandenen Infos konnte ich problemlos mal alle ConnectedInterfaces abholen.

Ich bastle gerade eine kleine Klasse, welche die Verbindung zum Interface kapselt....
Allerdings verwende ich die usbdmx.dll und nicht die usbdmxsi.dll

Die structs habe ich von deinem verlinkten Formthread. Das ganze kurz zusammen gesetzt gibt etwa folgendes (das ist jetzt weder schön verpackt, noch so zu verwenden. Normalerweise sollten die external calls sauber gewrappt werden).

Die restlichen Funktionen sehen auch nicht sonderlich kompliziert aus. Werde sie morgen wohl mal kurz in einer klasse schön verpacken. Ich denke, dass ich das in sehr kurzer Zeit funktionsfähig habe. Die Klasse erhaltet ihr natürlich hier als fertiges assembly inkl. code

[StructLayout(LayoutKind.Sequential, Pack = 0, CharSet = CharSet.Ansi)]
public struct Serial
{
   [MarshalAs(UnmanagedType.ByValArray, SizeConst = 16)]
   public char[] SerialNumber;
}


[StructLayout(LayoutKind.Sequential, Pack = 0, CharSet = CharSet.Ansi)]
public struct SerialList
{
   [MarshalAs(UnmanagedType.ByValArray, SizeConst = 32)]
   public Serial[] Serials;
}
	public static class DigitalEnlightmentInterface
	{
        [DllImport("usbdmx.dll", CharSet=CharSet.Ansi)]
        public static extern bool GetAllConnectedInterfaces(ref SerialList list);
}

ich habs damit ansprechen können:

using System.Runtime.InteropServices; // !!!


public delegate void HostDeviceChangeProc();


    public partial class Form1 : Form
    {
        [DllImport("usbdmx.dll")]
        public static extern uint RegisterInterfaceChangeNotification(HostDeviceChangeProc Proc);
        [DllImport("usbdmx.dll", CharSet = CharSet.Ansi)]    
        public static extern uint SetInterfaceMode(string serial, byte mode);
        [DllImport("usbdmx.dll", CharSet = CharSet.Ansi)]
        public static extern void GetAllConnectedInterfaces(StringBuilder SerialList);
        [DllImport("usbdmx.dll")]
        public static extern uint OpenLink(string Serial,byte[] DMXoutArray, byte[] DMXinArray);        
        [DllImport("usbdmx.dll")]
        public  static extern int CloseLink(string Serial);
        [DllImport("usbdmx.dll")]
        public static extern int GetDeviceVersion(string Serial);
}

reihenfolge ist: GetAllConnectedInterface, SetInterfaceMode,OpenLink. Und dann nurnoch CloseLink beim beenden.

Mangels Zeit und Terminen gestern, bin ich noch nicht so weit, wie ich sein wollte...
Hoffe, dass ich das ganze schön verpackt heute Abend fertig kriege

Hallo zusammen,

Die Ansteuerung des DE-Interfaces ist beinahe fertig gecoded. Es fehlt lediglich noch der Konfigurationsteil um eine erste Version fertig zu haben.
Dabei bin ich jedoch noch auf einige Probleme gestossen, welche meiner Meinung nach aus dem Treiber des DE-Interface hervorgehen. Das Verhalten lässt sich auch im offiziellen Testprogramm reproduzieren. Da ich davon ausgehe, dass die Entwickler von DE hier auch mitlesen, poste ich das hier.

Folgendes Problem taucht reproduzierbar auf:
Im Betriebsmodus 6 (PCOut->DMXOut,DMXIn->PCIn) werden die Inputchangenotifications gefeuert.
Im .Net habe ich einen Handler dafür registriert, welcher die Events auch erhält. Gemäss Beschreibung sollte dieser Callback nicht mehr als 1ms dauern. Daher habe ich das Eventing intern async gebaut. Der Callback setzt lediglich ein Flag, damit der NotificationThread weiss, dass er ein Event auslösen muss.
Das Klapp auch so weit so gut. Das einzige Problem ist, dass der Treiber einen Stackoverflow erzeugt, wenn der UIThread (welcher für das Abfüllen der Kanalübersicht zwischenzeitlich belegt ist), nicht antwortet. Dabei geht die gesamte Applikation hops.

Nein, ich habe keine Rekursion im .Net code, welche den Stackoverflow erzeugen würde! Auch erhalte ich keinen Stacktrace mehr und gehe daher davon aus, dass das ausserhalb von .Net geschieht.

Das Problem lässt sich zwar über fixe Scanintervalle reduzieren, aber ganz vermeiden lässt es sich nicht. Treffen viele Updates ein, kann das schon reichen, wenn der UIThread 100ms belegt ist. Auch die Test.exe schmiert willkürlich mit einem Fehler ab, wenn man am Fader für alle Channels dreht. Manchmal dauert es länger, manchmal geht es schneller. Hängt wohl ganz davon ab, wann das Update-Processing im UI läuft.

Meine letzten Tests mit Debug.WriteLine() der ersten 12 Kanäle (ohne UI-Update) haben gezeigt, dass es auch da auftritt. Scanintervall war 1 Sekunde und mit vielen updates am Fader schafft man es dennoch.

Ist das Phänomen bereits bekannt?

Grüsse aus der Schweiz

Phips

Edit: noch einen passend Post im DE Forum erstellt: http://matthias.dempe.de/eforum25/show.…10508194017&u=1

Hiho

bitte entschuldigt mein Schweigen. Ich ziehe in einer Woche um und momentan geht es gerade chaotisch zu und her.
Mein Code hat noch nicht die Stabilität erreicht, dass ich ihn schon freigeben würde. Ich habe seit der ersten Version nochmals einiges umgestellt und werde wohl noch das eine oder andere Umstellen und etwas anders machen.

Das Problem konnte ich mehrheitlich lösen. Es war ein klassischer Eigen-DAU und ich hätte am liebsten die Tischkannte abgebissen, weil ich ja auch selbst drauf hätte kommen müssen.

Der Punkt ist relativ einfach gewesen. Ich über gebe Callbackdelegates an die usbdmx.dll. Diese dll läuft nicht als managed Code und liegt somit ausserhalb des .Net Garbage Collectors. Wenn ich nun die Delegates einfach mit New übergebe und keine Referenz auf die Callback-Delegates halte, dann werden die irgendwann vom GC weggeräumt. Folglich kann der Callback dann nur noch abrauchen, da er in einen ungültigen Bereich zeigt. Nachdem ich das gelöst habe, waren die Callbacks stabil. (Danke an Soon5 )

Dafür bin ich in ein nächstes Problem gelaufen. Die Input-Array verhält sich hin und wieder merkwürdig. Wenn ich im Modus 6 bin und den output an den input angeschlossen habe, kann es vorkommen, dass die input byte[] einfach mit "false" überschrieben wird. Aus dem .Net dürfte es kaum möglich sein der array einen ungütligen Wert zuzuweisen. Woher das Verhalten kommt und wie es sich vermeiden lässt versuche ich noch heraus zu finden. Was ich jetzt schon sagen kann ist, dass die Arrays vom GC nicht weggeräumt und auch nicht umhergeschoben werden. Ich kriege ne Exception an den Kopf geworfen und wenn ich mich im Debugger etwas durchhangle, dann sehe ich, dass anstelle von byte[] der String (nicht bool wert) "false" drin steht.

Sobald ich in der neuen Wohnung eingerichtet bin, werde ich mich wieder daran setzen das noch zu lösen.

hope this helps

Phips

Ups, da war ja noch was..

Jup, der Umzug und die Flitterwochen waren richtig klasse
Mein Homeoffice steht wieder und ich denke, dass ich den Code rausgeben kann.
Das DMX-In ist im Loopbackmodus noch nicht ganz stabil, aber daran arbeite ich noch. DMX-Out sollte problemlos laufen.

Wenn ich @home bin, packe ich den Code mal zusammen.

LG

Phips

Den Code habe ich stabilisiert und nochmals etwas überarbeitet. Es steht noch ein Test auf meiner Maschine an, um auch sicher zu gehen, dass der DMX-In nun auch stabil läuft.
Weiter warte ich noch auf eine Antwort von den DE-Entwicklern auf meine Mail und hoffe, dass diese in den nächsten zwei Tagen eintrifft.

Ich denke, dass einem Release der aktuellen Version nächste Woche nichts mehr im Weg stehen sollte. Vorausgesetzt, dass ich am WE wirklich mal 1-2h Zeit für den Test finde.

Update und guckst du hier: http://www.dmxcontrol.de/forum/index.ph…ight=#post56833