Posts by Souko

Hi,

ja, die Erfahrung mache ich auch gerade. Ich habe inzwischen auch ein FX5 hier liegen.

Scheinbar sind die sogenannten Lockbits gesetzt, welche ein auslesen unmöglich machen.

ABER: das FX5 ist ein nichts anderes als eine kommerzielle Variante des USB-DMX-Interface von Digital-Enlightenment:

http://www.digital-enlightenment.de/usbdmx.htm

Dort bekommt man natürlich auch die Firmware und kann das Gerät damit neu flashen.

Solange das Gerät noch erkannt wird, sollte DMXControl auch die Seriennummer des Interface anzeigen können.

DIese unbedingt notieren und dann kann man die Firmware neu kompilieren (Die Seriennummer ist da fest eingebaut) und neu flashen.

Hi,

leider ist das FX5 nicht von unserem Verein, daher ist es schwierig da genau zu sagen wie die Pinbelegung ist.

was ich aber mit Sicherheit sagen kann, das es sich um einen 6-poligen ISP-Anschluss handelt, da in dem interface ein Atmel ATMega8515 verbaut ist.

Entsprechend sollten die Pins auch auf den Controller gehen, einfach die Traces/Leiterbahnen verfolgen.

Zwei Pins sind GND und 5V die anderen 4 sollten folgende sein:

- Reset -> Pin 4 am IC

- MOSI -> Pin 1 am IC

- MISO -> Pin 2 am IC

- SCK -> Pin 3 am IC

Damit sollte das klappen

Wenn dein Freund die Möglichkeiten zum auslesen des Flash hat, bitte einmal vor dem löschen/programmieren den Flash auslesen und die resultierende .hex-Datei hier posten.

Ich würde die gerne mal vergleichen, ob da wirklich Bits/Bytes gekippt sind.

Wobei auch defekte/alte Elkos dazu führen können, oder lockere Lötstellen...

Grüße

Hm, Ok, dann ist es in der Tat schwierig festzustellen was diesen Fehler auslösen könnte.

Kontrolliere bitte mal noch den Wert des senkrecht stehenden Widerstandes.

Das müsste der Pullup für den Empfangs-Optokoppler sein. Auch sonst nochmal alle Widerstandswerte anhand der Farbcodierung kontrollieren.

Das ist auf den Bilder leider nicht ganz einfach zuzuordnen. Nicht das da irgendwo ein 10 Ohm drin ist, wo ein 10kOhm rein sollte oder so (Hab die genauen Werte nicht im Kopf)

Denn der Startup des Interface initialisiert die ganzen I/O-Pins. Wenn da irgendwo etwas falsches drin ist, kann das auch zu massiver Stromaufnahme führen.

der Transistor ist auch der richtige ?

Was ich sonst als nächstes tun würde:

- Optokoppler und Transceiver-ICs entfernen

- transistor vor dem DC/DC auslöten

- Das Interface im Bootloader-Modus mit dem Jumper starten und die Stromaufnahme messen.

- Firmware eventuell nochmal flashen

- Interface normal starten und Stromaufnahme messen

sollte der Stromverbrauch beim start der Firmware ein bisschen hoch gehen ist das normal, denn

das Nodle läuft beim Start mit aktiviertem Taktteiler auf 2Mhz im Bootloader.

Erst wenn die Firmware startet wird dieser deaktiviert und auf 16 Mhz gebracht. Bei höherer Taktung geht natürlich der Stromverbrauch leicht hoch (aber keine 200 mA)

Ansonsten denke ich wirklich der ATMega hat einen Schaden. Vielleicht ist irgendwo an den I/Os eine der integrierten

Schutzdioden oder Pullups abgeraucht durch zu viel Hitze beim Löten oder ESD beim hantieren und macht sich erst nach dem Initialisieren Bemerkbar !?

Also die Bauteile stimmen schonmal von den Positionen und der Ausrichtung.

Auf der Rückseite kann ich an einigen Stellen Lötzinnreste erkennen. Könnten aber auch z.T. Flussmittelreste sein.

Ich hab dir die Stellen mal eingekreist.

Hi Ironstar

das ist ein Interessanter Fehler.

Könntest du zunächst einmal gut belichtete/helle und hochauflösende (Smartphone-Kamera reicht, nur halt kein 640x480 ) Fotos von Platinen-Oberseite und -unterseite machen ?

Oder waren das die Anhänge in deinem Beitrag ? Die sind irgendwie kaputt/fehlen.

Das der Widerstand sich verändert, wenn du den AtMega erwärmst ist in einem gewissen Rahmen völlig normal. Das passiert erstmal bei jedem Silizium-Bauteil.

Hallo Sascha,

vielen Dank für dein Lob. Solche Postings liesst man sehr gerne

Viel Spass noch mit unserer Software !

HALT STOP !!!!

Das ist genau der Fix, der von Bodo-wo schonmal verwendet wurde. Der ist für die Version 3.1 !!!! NICHT NEHMEN !

EDIT: So. Bitte hier nicht wild weiter raten und zig Lösungen vorschlagen die nicht Zielführend sind. Es handelt sich hierbei nicht um ein bekanntes Problem, sondern bisher um einen speziellen Einzelfall.

Ich bin hier mit Bodo-wo per PN in Kontakt um die Ursache zu ermitteln.

Sollte es sich doch um einen Bug handeln, der die Allgemeinheit betrifft, kommt die Lösung natürlich auch hier wieder rein

Aber bis dahin, bitte erstmal Füsse still halten.

Noodle Treiber DLL - Open Beta

ACHTUNG !! Bitte sorgfältig lesen UND VERSTEHEN !

Hier in diesem Thread findet ihr eine neue Version der Nodle-DLL.

Diese DLL wurde von dem alten MinGW-Framework komplett auf Visual-C++ & Windows Driver Kit portiert. Bisher konnten mit dieser DLL bei einigen Usern die meisten der Stabilitätsprobleme mit den Nodle behoben werden.

Allerdings haben wir in den Reihen der Betatester als auch im Team zu wenig Personen die eine Möglichkeit haben die DLL auch unter "Erschwerten Bedingungen" wie "viel Kanäle, verschiedene PCs, etc." in relativ kurzer Zeitspanne zu testen.

Daher gibt es für diese DLL jetzt etwas, was bei DMXControl Projects bisher nicht in frage gekommen ist. Eine open-Beta !

DIe DLL wurde intern durch mich und einige andere in verschiedenen Situationen getestet und untersucht und es konnten bisher keine Fehler oder Einschränkungen gefunden werden.

Dennoch unterliegt die Verwendung bei einem "riesigen Event, bei dem alles passen muss" der eigenen VErantwortung ! Habt bitte auf jeden Fall ein Backup dabei, wenn ihr mit Beta-Software (oder auch teilen davon) unterwegs seid. Das gilt nicht nur für diese DLL

Also nochmal:

!!! ES HANDELT SICH DAHER AUSDRÜCKLICH UM EINE BETAVERSION, WELCHE FEHLER ENTHALTEN KANN !!!

Verwendung:

Es muss im Kernel-Verzeichniss C:\Program Files (x86)\DMXControl3\Kernel\Plugins\api-dlls folgende Datei ersetzt werden:

Bitte gebt hier gerne Feedback und packt gefundene Fehler mit Logfiles von DMXControl in den Bugtracker

Viele Grüße,

Souko / Marcel

Hi,

in der kommenden Version von DMXControl ist der EnergyFixer überarbeitet und wird automatisiert durch DMXC ausgeführt.

Zumindest habe ich diese Änderungen im Code einfliessen lassen.

Noch eine Korrektur: der Registry-Wert den der EnergyFixer ändert wird nicht pro USB-Port gespeichert sondern pro Interface.

Das Verhalten das du beschreibst liegt aber nach meinen bisherigen Erkentnissen NICHT an den Energieeinstellungen sondern an Windows/NoodleUSB.dll selbst.

Es gibt eine neue Version der Nodle DLL welche aber noch nicht ausreichend getestet wurde und daher noch nicht mit DMXControl ausgeleiefert wurde.

Da sich aber die Meldungen über Probleme mit den Nodles häufen und die Meisten davon mit der neuen dll behoben waren, werde ich gleich mal einen Post aufmachen und die DLL da als "öffentliche Beta" rein packen.

EDIT: hier der Beta-Post : [OPEN BETA] Nodle_USB.dll

Hi Bodo-wo

das sind doch mal gute Nachrichten. Dann scheint es, das bei der vielen kopiererei und verschieberei irgendwo was verrutscht ist.

Im Anhang findest du auch die letze Version des EnergyFixer. Bei der 3.1 ist das R4S in diesem noch nicht drin. (Genau wie bei den dll's)

Den brauchst du aber nur einmal ausführen, damit die Registry angepasst wird. Muss also auch nicht irgendwo ins DMXControl-Verzeichniss.

Hallo Bodo-wo

ich habe die Logs mal an unsere Entwickler weiter gereicht. Der Fehler scheint irgendwo tiefer zu stecken und nicht offensichtlich zu sein.

Kannst du bitte mal Alle .dlls aus dem Plugin-ordner löschen (oder in einen backup-Ordner irgendwo anders als im programmverzeichniss verschieben) im Kernel-Verzeichniss, ausser die beiden DMXControlProjectsEVNodleU-Dateien (.dll und .pdb)

Dann starte bitte DMXControl und schau ob es wieder abschmiert.

Wenn ja, bitte die Logs erneut anhängen. Wenn nicht, versuche bitte das Interface nach der Anleitung oben einzurichten.

Oh... dann musst du die bitte manuell einsammeln. Bitte einfach diese beiden Ordner zippen:

C:\Users\Benutzername\AppData\Roaming\DMXControl Projects e.V\DMXControl\Kernel\Log

C:\Users\Benutzername\AppData\Roaming\DMXControl Projects e.V\DMXControl\GUI\Log

Ok. Das kann viele Ursachen haben.

Kannst du bitte mal DMXC neu starten und dann die Lofgiles von DMXControl anhängen ? Diese findest du hier

einfach das generierte .zip hier anhängen.

AH, na prima.. das Erklärt vieles.

Dann lag es also an den falschen Dateien.

So.. nun sollte es relativ einfach weiter gehen.

DAs Interface auswählen und auf OK (ich habe hier das U1, ist beim R4S aber genau so, nur das da dann die SN etwas anders aussieht mit R4S vorne dran)

Dann auf OK und dann erscheint dieses fensterchen

Dort wird eine andere FW-Version stehen, aber ansonsten alles so lassen und auf OK

Und jetzt sollte im hauptfenster das so aussehen:

jetzt sollte am Interface eine DMX-Ausgabe sein.

Was mir gerade auffällt:

Die Dateigrößen stimmen nicht. Das sind nicht die .dll's aus diesem Thread aus Beitrag #6

Entsprechend sind das nicht die gepatchten Files extra für die Version 3.1.x !

Wie ich in Beitrag #22 hier in diesem Thread schrieb, brauchst du die gepatchten aus Beitrag #6 aus diesem Thread !

Ok, das ist sehr seltsam.

Fakt ist schonmal, es liegt momentan NICHT am R4S Interface sondern harkt schon vorher irgendwo am laden der .dll's

Denn der Eintrag mit dem "DMXControl Projects e.V." sollte immer unter der Interface-Auflistung stehen, auch wenn gar kein IF angeschlossen ist.

Könntest du bitte mal DMXControl als Administrator starten ? Eventuell hängt hier irgendwas an der Rechtesteuerung von Windows ?

Nein, das meinte ich nicht. Nach der Anleitung aus meinem Posting vom August sind in dem Zip-FIle 2 dlls drin.

die eine ist die Nodle_USB.dll welche in das Kernelverzeichniss muss.

die 2. befindet sich in dem ZipFIle im Unterordner "Plugins" und heisst DMXControlProjectsEVNodleU.dll

Diese muss im Kernelverzeichniss auch in den Ordner "Plugins" rein.

Ist diese Datei vorhanden und rechtsklick->Zulassen wurde erledigt ?

Hi Bodo-wo

das sieht schonmal richtig aus.

Hast du das selbe auch mit der 2. .dll gemacht, welche nach Plugins kopiert wurde ?

Denn in der Interface-Auflistung fehlt der Eintrag "DMXControl Projects e.V."

Das spricht dafür das diese DLL entweder fehlt ODER nicht zugegriffen werden kann.

Es sollte dann so aussehen:

DIe 3.1.3 benötigt die gepatchten dlls oben aus dem Beitrag: Nodle R4S lässt sich nicht in DMXC 3 anlegen

ab der 3.2 wird die R4S-kompatible .dll mitgeliefert.

Freestyler unterstützt das Nodle offiziell nicht.

IP Symcon ist mir zwar ein Begriff, aber wohl für Gebäudeautomation gedacht !? Auch hier ist von unserer Seite offiziell bisher keine Unterstützung des Nodle vorhanden.