Eurolite USB-DMX512-Pro + Win7 64 - Fehlermeldung

Hallo allerseits,

Bin neu hier und auf der Suche nach einer Steuerung für meine 4er RGB LED Bar (Stairville TRI LED).

Habe mir dazu das o.g. Interface gekauft, was mit Freestyler auch gut funktioniert. Allerdings gefällt mir DMXC aus diversen Gründen wesentlich besser, so dass ich es lieber darüber steuern möchte.

Frage also: sollte das USB-DMX512 Pro in DMXC3 schon funktionieren? (Es ist ja in der Interface-Liste aufgeführt).
Screenshot von den Einstellungen habe ich angehängt. COM4 sollte auch stimmen (geht mit Freestyler auf diesem Port). Beim ersten Versuch, irgendeinen DMX-Wert zu senden, zeigt mir der Kernel dann aber leider folgende Fehlermeldung:

19:10:06 WARN PluginManager - Error when sending DMX Values to Interface (Port)
Eurolite#USBDMX512PRO#0(0): Das Quellarray ist nicht lang genug. Überprüfen Sie
srcIndex, die Länge und die Untergrenze des Arrays.
System.ArgumentException: Das Quellarray ist nicht lang genug. Überprüfen Sie sr
cIndex, die Länge und die Untergrenze des Arrays.
bei System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destination
Array, Int32 destinationIndex, Int32 length, Boolean reliable)
bei System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destination
Array, Int32 destinationIndex, Int32 length)
bei org.dmxc.lumos.Kernel.DMX.EuroliteUSBDMX512PROLib.SendDMX(UInt16 address,
Byte[] data) in D:\dmxc3\branch\Lumos\DMXPlugins\EuroliteUSBDMX512PRO\src\Eurol
iteLib.cs:Zeile 145.
bei org.dmxc.lumos.Kernel.DMX.EuroliteUSBDMX512PROInterface.SendDMXInternal(I
nt32 port, Int32 address, Byte[] values) in D:\dmxc3\branch\Lumos\DMXPlugins\Eur
oliteUSBDMX512PRO\src\Eurolite.cs:Zeile 116.
bei DMXLIB.AbstractDMXInterface.SendDMX(Int32 port, Int32 address, Byte[] val
ues) in D:\dmxc3\branch\Lumos\Lumos\DMXLIB\AbstractDMXInterface.cs:Zeile 201.
bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.SendDMXValuesToInterfa
ce(DMXInterfaceBag e, Int32 port, Int32 address, Byte[] values) in D:\dmxc3\bran
ch\Lumos\Lumos\LumosLIB\src\Kernel\Plugin\AbstractPluginManager.cs:Zeile 917.

Ich habe Win7 64bit und den "eurusbdmx.inf"-Treiber für das Interface installiert.

Mache ich was falsch, wird das Interface noch nicht unterstützt oder ist's ein Bug?

mir ist bekannt, dass ich übergangsweise DMXC2 über DMXC3 steuern könnte, nur leider stürzt DMXC2 bei mir ab wenn ich nur versuche, das Interface zu aktivieren - sowohl mit dem Enttec- als auch mit dem DMX Pro-Treiber (hier aus dem Forum)

Danke für jeden Hinweis!
(...und sowieso schon mal danke für die tolle Software!)

(habe auch noch 'ne andere Frage, gehört aber nicht in dieses Unterforum - darum gleich separater Post.)

lg,
Frank Ingermann

Hallo,

- das sind ja Reaktionszeiten, unglaublich!  

Die gute Nachricht vorweg: es gibt mit den neuen Files jetzt keine Fehlermeldung mehr.

Lampen sind allerdings noch aus, das liegt aber womöglich an meiner (selbstgebastelten) DDF. Ich arbeite daran...

P.S.: bin wie gesagt neu hier, bis zum Bugtracker war ich noch nicht vorgedrungen (schäm)... werde den dann demnächst benutzen.

Erst mal vielen Dank für die prompte Hilfe!

lg,
Frank Ingermann

Hallo Dennis,

Fehlermeldungen sind zwar weg, aber es tut's leider nach wie vor nicht. Habe sowohl im Channel View als auch im Kernel direkt versucht, Werte einzustellen um was zum leuchten zu bringen, passiert aber nichts.

Habe das jetzt mal in den Tracker eingetragen.

Frage in die Runde: gibt es andere Interfaces (in der Preisklasse ~100€), die sicher/zuverlässig mit DMXC3 und DMXC2 funktionieren?
(ich kann meines noch umtauschen...  )

lg, Frank

Hallo JP,

danke für den Tipp, und ja, löten kann ich - allerdings ist mir das etwas zu viel Bastelei. Bliebe die Kaufversion.
Für 160€ gibt's aber auch schon das Enttec DMX Pro. Das wird zwar von DMXC3 noch nicht unterstützt, aber das kommt ja hoffentlich irgendwann noch.

Nach viel Herumgesuche gestern Nacht scheint mir das wohl von der meisten Software unterstützt zu werden (inkl. DMXC2 und sogar der Martin M-PC Free-Version).

Großer Vorteil für mich wäre daran, dass gleich eine DLL zur Ansteuerung dabei ist, womit ich mir dann für meine bescheidenen Zwecke ein kleines Lauflicht-Dings selber in Delphi programmieren könnte (bis es dann in DMXC3 nutzbar wird).

Oder spricht da irgendwas dagegen, hat jemand schlechte Erfahrungen damit gemacht o.ä.?

lg, Frank

Hallo noch mal,

wenn das Enttec kein DMX-IN kann, stört mich das erst mal nicht (ich brauch's nicht). Wichtiger wäre mir die API zum Selber-Ansteuern und die Kompatibilität, wenn es ansonsten stabil und brauchbar ist.

Das neue MK2 kann ja noch einiges mehr, ist mir aber dann doch zu teuer - 'ne Bar mit 4 Lampen für 330€ mit 'nem Interface für 230€ ansteuern ist schon was schräg, oder?  

( Stefan: laut Enttec Homepage ist das MK2 angeblich voll rückwärtskompatibel zum "alten" Pro, sollte also _theoretisch_ auch mit dem vorhandenen Treiber gehen...)

Ich hatte mir das Ganze so vorgestellt, dass die Bar normalerweise per SW (klar: vorzugsweise per DMXC3 ) angesteuert Sound-To-Light-mäßig läuft, und als Plan B (Laptop schmiert ab oder so) wollte ich ein einfaches DMX-Hardwarepult als Reserve haben. Da müsste ich dann halt mal umstöpseln... irgendwann später kann man ja 'nen DMX-Merger dazwischenhängen, falls ich's doch mal parallel brauche.

lg,
Frank

Hallo,

ist ja gut - Ihr habt mich überzeugt!  

Habe das FX5 gerade bestellt, und das Eurolite geht zurück zum "T"... (mit der fehlenden galvanischen Trennung hatte ich da eh schon etwas Bauchschmerzen...)

Den Treiber zum FX5 habe ich mir angesehen, sieht soweit echt gut aus - sogar Delphi- (=ObjectPascal) Beispiele drin, wie praktisch!
...nur gibt's dazu kein Martin M-PC, aber das wär' für meinen Zweck auch echt völlig oversized  

Habe jetzt nur noch etwas Unklarheit zu den ganzen Betriebsmodi, fragen dazu stelle ich dann zu gegebener Zeit im entspr. Unterforum.

Vielen Dank Euch allen für die Infos

lg,
Frank

Hallo Uwe,

ganz ehrlich kam mir die Übermacht der Empfehlungen hier schon fast suspekt vor (so von wegen "stehen die alle bei denen auf der Gehaltsliste??") - ich glaube aber mal an die Alternative, nämlich dass das Teil einfach gut ist.

Hoffentlich haben die keine 3 Wochen Lieferzeit, sonst müsste ich das Eurolite vorher noch zurückschicken und hätte dann zwischendurch nichts mehr zum "spielen".  

Lg, Frank

Hallo Patrick,

da hast Du wohl recht. Ich hoffe auch sehr, dass das Eurolite-Dings irgendwann demnächst auch mit DMXC3 funktionieren wird - darum habe ich's ja in den Tracker eingetragen, weil: mehr unterstützte Interfaces == größere (potentielle) Benutzer-Basis, und das ist für ein solches Freeware-Projekt immer gut (auch wenn's für die "Freiwilligen" = die Entwickler meist nur noch mehr Arbeit macht).

ABER:

1.) ich selbst bin gerade (noch) in der glücklichen Lage, mir ein IF aussuchen zu können (wg. Rückgaberecht), und dann nehme ich doch lieber eines, was schon bekanntermaßen funktioniert. (ok, ist teurer, aber wenn es dann dafür FUNKTIONIERT...)

2.) (und vor allen Dingen 2.!) :

Man kann (und sollte!) als Nutzer einer Freeware nicht verlangen, oder gar einen der Entwickler dazu zwingen wollen, sich jetzt sofort "seines" Problems anzunehmen.

(Bezahlst du <x> Euronen pro Jahr/Monat für einen Wartungsvertrag bei einer Firma, wo Du vorher schon teuer Geld für die SW bezahlt hast, und die davon lebt, dann sieht das wieder anders aus - und deren Support ist meistens trotzdem _schlechter_ als z.B. hier).

Das einzige, was bei Freeware/OpenSource manchmal funktioniert, ist Bestech... NEIN, nennen wir es "Sponsoring", oder eine "kleine finanzielle Motivationshilfe". (In meinem Lieblings-OpenSource-Projekt - dem Firebird SQL-Server - haben wir dazu 2001 eine Stiftung gegründet, die die Entwickler finanziell unterstützt, einige bezahlen wir inzwischen sogar in Vollzeit. Wäre hier vlt. auch keine schlechte Idee, für die unter Euch, die DMXC professionell nutzen)

Eines noch "hintendrauf":

Man darf dabei nie, NIE vergessen, wieviel (unbezahlte Frei-)Zeit dabei drauf geht, so etwas zu entwickeln! Ganz zu schweigen davon, dass die Entwickler ja nicht mal eben alle Interfaces UND die dazugehörigen "Lampen" bei sich zu Hause rumliegen haben, um das mal eben schnell aufzubauen, zu testen und zu debuggen - man programmiert sowas meistens nach einer (eher schlechten als rechten) Spezifikation, und hofft, dass es dann bei dem, der das Problem gemeldet hat, auch "funzt" (und die Spec des Herstellers vor allem stimmt, was sie meistens nicht zu 100% tut).

Man kann deshalb - meine Meinung - den Leuten hier und anderswo, die solche Software bauen, nur auf Händen und Knien dafür danken, dass sie das tun(!)

Also entweder:
- benutzen, was da ist
- es selbst programmieren
- oder viel, viel Geld für kommerzielles Zeug ausgeben - und dann immer noch keine Garantie haben, dass es dann wirklich läuft.

...in diesem Sinne,

lg, Frank