• Hallo TT-Modellbahner, schön, dass du zu uns gefunden hast.
    Um alle Funktionen nutzen zu können, empfehlen wir dir, dich anzumelden. Denn vieles, was das Board zu bieten hat, ist ausschließlich angemeldeten Nutzern vorbehalten. Du benötigst nur eine gültige E-Mail-Adresse und schon kannst du dich registrieren.
    Deine Mailadresse wird für nichts Anderes verwendet als zur Kommunikation zwischen uns.
    Die Crew des TT-Boardes

Bauanleitungen für XPress-Geräte

Ich habe Interesse an einer USB-Interface-Leiterplatte mit Gehäuse s. Post 373


  • Umfrageteilnehmer
    28
  • Umfrage geschlossen .
Hallo Michael,

wenn das Interface sich mit "CCS RS232 Demo" meldet, hat der Compiler die falschen LIB Dateien genommen.
Schaue mal nach, ob er die aus dem lib Verzeichnis vom USB Interface benutzt.
Melden muss sich das Interface mit "USB<->Serial Interface" oder so ähnlich.

Deswegen stimmen dann die Vendor_ID und die Product_ID nicht mit denen der USB_Interface.inf überein.
Hier ein Auszug aus der usb_desc_cdc.h
Code:
//////////////////////////////////////////////////////////////////
///
///   start device descriptors
///
//////////////////////////////////////////////////////////////////

   const char USB_DEVICE_DESC[USB_DESC_DEVICE_LEN] ={
      //starts of with device configuration. only one possible
         USB_DESC_DEVICE_LEN, //the length of this report   ==0
         0x01, //the constant DEVICE (DEVICE 0x01)  ==1
         0x10,0x01, //usb version in bcd  ==2,3
         0x02, //class code. 0x02=Communication Device Class ==4
         0x00, //subclass code ==5
         0x00, //protocol code ==6
         USB_MAX_EP0_PACKET_LENGTH, //max packet size for endpoint 0. (SLOW SPEED SPECIFIES 8) ==7
         [B][COLOR="Red"]0xD8,0x04,[/COLOR][/B] //vendor id (0x04D8 is Microchip, or is it 0x0461 ??)  ==8,9
         [B][COLOR="Red"]0x80,0xD7,[/COLOR][/B] //product id   ==10,11
         0x00,0x01, //device release number  ==12,13
         0x01, //index of string description of manufacturer. therefore we point to string_1 array (see below)  ==14
         0x02, //index of string descriptor of the product  ==15
         0x00, //index of string descriptor of serial number  ==16
         USB_NUM_CONFIGURATIONS  //number of possible configurations  ==17
   };


In der USB_Interface.inf sieht es dann wie folgt aus:

Code:
[MNF]
%MNF_CDC%=Reader, USB\VID_[COLOR="Red"][B]04D8[/B][/COLOR]&PID_[COLOR="Red"][B]D780[/B][/COLOR]

Gruß
Ronny
 
Zuletzt bearbeitet:
Hallo Ronny,

vielen Dank für Deine Antwort. Du hattest die richtige Vermutung. Die Suchpfade für die Bibliotheken standen noch auf Deinen Einträgen. Nach Umstellung auf meine lokalen Verzeichnisse wurde das Projekt mit der richtigen Kennung compiliert.

Die Installation des Interfaces unter Windsows XP mit Service Pack 3 gelang dann sofort ohne Probleme. Unter Windows 7 (64bit) gelang die Installation leider nicht. Gleicher Fehler wie vorher. Benötigte ich da einen anderen Treiber, oder mache ich immer noch Fehler bei den Compilereinstellungen?

Gruß Michael
 
Hallo Michael,

probiere es mal mit folgenden Änderungen an der USB_Interface.inf

Code:
...
[Manufacturer]
[B][COLOR="Red"]%ProviderName%=DeviceList, NTx86, NTamd64 [/COLOR][/B]

[MNF]
%MNF_CDC%=Reader, USB\VID_04D8&PID_D780

[Reader_Install.NTx86]
;Windows2000

[B][COLOR="Red"][DeviceList.NTamd64]
%MNF_CDC%=Reader, USB\VID_04D8&PID_D780[/COLOR][/B]

[DestinationDirs]
DefaultDestDir=12
Reader.NT.Copy=12

...

Gruß
Ronny
 
Hallo,

mit den Änderungen in der INF-Datei hat dann die Installation funktioniert. Vielen Dank noch einmal an Ronny.

Nach den ersten Versuchen das Interface von Rocrail aus anzusprechen, musste ich feststellen, dass ich einen Fehler im Layout hatte. Die Pins für den MAX481 waren vertauscht. Also habe ich das korrigiert, den MAX481 wieder eingesteckt und noch einmal einen Versuch in Rocrail gestartet.

Leider gibt es aber immer noch Probleme mit dem Interface. Ich kann in Rocrail noch immer keine Verbindung zum Interface aufbauen. Im Moment stellt sich die Situation so dar:

* am Interface leuchten die gelbe und rote LED.
* Das Relais zur Verbindung des MAX481 und des XPressnet hat durchgeschaltet.
* In Rocrail wird ein Timeout-Fehler an COM3 gemeldet.

Ich habe dann noch einen Versuch mit der Demoversion von Traincontroller durchgeführt. Hier das gleiche Bild. Die Fehlermeldung lautet hier "Es konnte keine Verbindung zur Zentrale aufgebaut werden".

Wo liegt der Fehler? Da ich kein Elektronikexperte bin, habe ich im Moment nicht die gerinsgte Idee, woran es liegen kann.

Zur Veranschaulichung habe ich mal den Schaltplan, die Rocrail-trace-Datei und Rocrail-INI-Datei angehängt (Die Zeilenumbrüche der TXT-Dateien werden mir Wordpad korrekt dargestellt).
 

Anhänge

  • rocrail-ini.txt
    1,8 KB · Aufrufe: 29
  • rocrail.001.txt
    11,9 KB · Aufrufe: 12
  • Schaltplan.jpg
    Schaltplan.jpg
    98,4 KB · Aufrufe: 100
Hallo Michael,

hast du eine delay Zeit nach Aktivierung des Relais eingebaut? Relais brauchen so 20 ms zum Schalten.

Zu den LEDs:
Leuchten sollten die grüne (Power) und die rote (Verbindung Zentrale) LED. Die gelbe LED leuchtet, wenn Daten übertragen werden.

Kannst du einen Screenshot von den RocRail Einstellungen des Interfaces posten?

Gruß
Ronny
 
Hallo,

ich habe nochmals die ganze Prozedur wiederholt. Hier nun mein Ablauf mit Ergebnissen.

(1) Am USB-Interface ist keine Zentrale und Multimaus angesteckt.
(2) Das USB-Interface wird an den schon mehrere Stunden laufenden Laptop angesteckt. Ergebnis: Das Interface wurde nicht erkannt. Am Interfacebaustein leuchtet die grüne LED (im vorherigen Post falsch angegeben mit gelb).
(3) Der Laptop wurde mit abgezogenem Interface neu gestartet. Nach dem Start wurde das Interface angesteckt. Ergebnis: Fehlerfreie Erkennung des USB-Interface (hierzu Snapshot vom Gerätemanager). Am Interfacebaustein leuchtet die grüne LED.
(4) Das Interface wird vom laufendem Laptop abgezogen. Am Interfacebaustein werden die Zentrale (LZV100, V3.5) und die Multimaus angesteckt. Anschließend wird das Interface wieder am Laptop angesteckt. Ergebnis: Am Interface leuchten die grüne und rote LED. Windows erkennt den Baustein und startet den Treiber fehlerfrei für COM3. Die Modellbahnanlage kann mit der Multimaus ohne Probleme bedient werden.
(5) Starten von Rocrail. Ergebnis: Fehlermeldung -> timeout an COM3. In diesem Moment entstand der Snapshot von Rocrail.

Um eventuelle Fehler im PIC-Programm aufzudecken, ist der Quelltext auch angehängt worden. Änderungen von mir wurden in Zeile 28 (#define K1) und 262 (output_bit(K1,TRUE) - Relais schalten) vorgenommen.

@Ronny: Eine Wartezeit habe ich nicht im Quelltext eingefügt. Wie müsste die Programmzeile hierfür aussehen?

Gruß Michael
 

Anhänge

  • windows-treiber.jpg
    windows-treiber.jpg
    172,9 KB · Aufrufe: 92
  • rocrail.jpg
    rocrail.jpg
    209,9 KB · Aufrufe: 89
  • USB_Interface.txt
    11,8 KB · Aufrufe: 37
Hallo Michael,

füge mal folgendes ein.
Code:
output_bit(K1,TRUE);               // Relais zuschalten
[B][COLOR="Red"]delay_ms(50);   // 50ms Pause[/COLOR][/B]
usb_cdc_init();

Du kannst auch höhere Baudraten einstellen, USB ist schnell genug.
Wenn die Software mit der Zentrale nicht kommunizieren kann, liegt das meist an der Strecke zwischen Interface<->Zentrale. Jetzt müsste man mal schauen, ob das Interface mit Fehlermeldungen antwortet oder gar nichts sagt. Das sieht man bei RocRail in dem Eingabeaufforderungsfenster. Traincontroller müsste das auch anzeigen.
Was du auch probieren kannst, ist diese Software:
http://jmri.sourceforge.net/download/

Gruß
Ronny
 
Hallo Ronny,

ich habe die Wartezeit einprogrammiert und unverändert das gleiche Ergebnis.

(1) Das Interface wird nach dem Zufallsprinzip vom Windows 7 beim Anstecken korrekt erkannt oder eben auch nicht. Beim Anstecken des Interfaces ist die Verbindung zum XPressnet noch getrennt.
(2) Beim anschließenden Einschalten der LZV100 und somit Verbindung des Interfaces zum Xpressnet erfolgt meist sofort die korrekte Erkennung durch das Windows 7.
(3) Auch wenn Windows 7 das Interface ohne Fehler verbindet, kann Traincontroller keine Verbindung aufbauen.

Die gelbe LED leuchtet niemals auf.

Ich habe dann nochmals Versuche nach dem Austausch von zwei Optokopplern durchgeführt. Hat auch keine Veränderung gebracht. Kann es sein, dass durch die falsche Verdrahtung der MAX481 oder der PIC beschädigt ist? Wenn das so ist, warum leuchtet dann die rote LED auf?

Ach so, wenn die LZV100 bereits angeschalten ist und anschließend die Verbindung zum PC hergestellt wird, bleibt die rote LED aus. Wann erfolgt die Prüfung auf Verbindung zum Xpressnet? Nur bei der Initialisierung des PIC's, zyklisch oder per Interrupt? Kann hier eventuell eine Fehlfunktion vorliegen?

Warum soll die Leitung des XPressnet zu lang sein? Laut Fa. Lenz kann dieses bis zu 1000 m Ausdehnung haben. Bei mir sind es von der LZV100 bis zum Interface ca. 7 m mit zwischengeschaltetem Verteiler LA152 von der Fa. Lenz. Immerhin geht es von dem Interface noch einmal 3 m bis zur Multimaus und die funktioniert einwandfrei.

Ich bin am Überlegen, das Relais zu brücken und Deine Version 1.5 aufzuspielen, also den Ursprungsstand. Vielleicht bringt mich das weiter.

Gruß Michael
 
Vielleicht hilft das hier ja weiter:

Ich hatte Probleme mit einem GenLiRS und Rocrail unter Windows 7. Einige Fehlermeldungen, Interface wurde mal erkannt, mal nicht, ich konnte per Hyperterminal nicht darauf zugreifen etc.
Ich habe dann testweise alles unter einem virtuellen Windows XP (gibt es kostenlos ab Windows 7 Professional) installiert und eingestellt, dort funktionierte alles wunderbar. Danach nochmal alles in Windows 7 probiert und siehe da, dort ging es dann auch.
 
Hallo Michael,

Kann es sein, dass durch die falsche Verdrahtung der MAX481 oder der PIC beschädigt ist? Wenn das so ist, warum leuchtet dann die rote LED auf?
Für die rote LED zählt Timer1, der immer wieder zurück gesetzt wird, wenn von der Zentrale etwas empfangen wird. Kommt nichts von der Zentrale, läuft Timer1 über, die rote LED geht aus und die Meldung "Zentrale adressiert LI-USB nicht mehr" geht an den PC.
Suche im Quellcode mal nach "output_bit (LED_ROT,TRUE);" und "output_bit (LED_ROT,FALSE);".


Ach so, wenn die LZV100 bereits angeschalten ist und anschließend die Verbindung zum PC hergestellt wird, bleibt die rote LED aus. Wann erfolgt die Prüfung auf Verbindung zum Xpressnet? Nur bei der Initialisierung des PIC's, zyklisch oder per Interrupt? Kann hier eventuell eine Fehlfunktion vorliegen?
Die rote LED wird ständig per Interrupt, je nach dem, ob das Interface was empfängt, an/aus geschaltet.
Gibt nur zwei Möglichkeiten, die Zentrale sendet nichts an das Interface oder das Interface hängt irgendwo fest.
Das Problem an der ganzen Sache ist, das die Zentrale ein Gerät, das unsinnige Befehle sendet, nicht mehr anspricht. Da hilft nur Zentrale aus und wieder an. Genaueres lässt sich nur mit einem XPressNet Sniffer feststellen


Ich bin am Überlegen, das Relais zu brücken und Deine Version 1.5 aufzuspielen, also den Ursprungsstand. Vielleicht bringt mich das weiter.
Das wäre ne Möglichkeit, um zu testen, ob die Hardware noch in Ordnung ist.

Gruß
Ronny
 
Hallo Ronny, Hallo Denis,

vielen Dank für die kräftige Unterstützung. Leider immer noch das gleiche Bild.

Ich habe dieses mal (entsprechend dem Rat von Denis) versucht unter Windows XP die neue Version mit Relais und danach die Version 1.5 von Ronny bei gebrücktem Relais in Betrieb zu nehmen. Immer noch der Timeout-Fehler in Rocrail. Deshalb habe ich die parallelen Versuche auf Windsows 7 mit Traincontroller erst gar nicht durchgeführt. Da nicht einmal die Version 1.5 funktioniert, sieht es also ganz so aus, als ob irgendwo in der Hardware was nicht stimmt.

Ich werde mir in den nächsten Tagen/Wochen noch einmal den Schaltplan und das Layout genauer ansehen und mit der Version 1.5 vergleichen. Je nachdem, ob ich vor Ort beim Elektronikhändler die Optokoppler 6N137 und den MAX481 bekomme, werde ich aufgrund der Mindestbestellwerte beim Versandhandel dann eventuell erst andere Projekte weiter vorantreiben.

Für welche Quarzfrequenz ist Dein Programm erstellt. Ich habe keinen Hinweis im Quelltext gefunden. Auf der Platine habe ich einen Quarz mit 20 MHz verbaut. Und irgendwo her muss ich den Wert haben. Kann mich blos nicht mehr erinnern woher.

Gruß Michael
 
Hallo Michael,

ok, also scheint was mit der Hardware nicht zu stimmen.
Der Quarz ist richtig, der Takt wird intern auf 48MHz angehoben, das sieht man in der USB_Interface.h.

Gruß
Ronny
 
Hallo,

das USB-Interface läuft! Ohne Neukauf von Bauteilen.

Wo lag der Fehler?

Ich hatte (wie bereits schon erläutert) einen Fehler im Layout. Dieser führte dazu, das der Treiber-IC MAX481 nicht arbeiten konnte, weil die Pins vertauscht waren. Also konnte keine Verbindung zwischen PIC und XPressNet hergestellt werden. Nachdem ich den Fehler entdeckt und korrigiert hatte, trat bekanntlich ein Timeout-Fehler in Rocrail auf und Traincontroller konnte keine Verbindung zur Zentrale aufbauen. Ursache hierfür ist nicht etwa wie vermutet ein Fehler in der Hardware, sondern in der falschen Auswahl der Schnittstelle in Rocrail und Traincontroller. Ich nahm an, das die Sofwareumsetzung der Signale vom USB nach COM (und umgekehrt) auch dazu führt, dass im Steuerprogramm das LI100/LI101F ausgewählt werden muss. Dem ist nicht so. Hier muss zwingend das LI-USB mit der betreffenden COM-Schnittstelle ausgewählt werden (bei meinem Computer normalerweise COM3). Das USB-Interface ist also nur mit dem LI-USB der Fa. Lenz kompatibel. Warum das so ist, ergbit sich aus der Normung des Übertragungsprotokolls für das LI-USB. Dort findet man auf den Seiten 1-2/1-3 die Information, dass entgegen der Schnittstellen LI100/LI101F immer beim Senden und Empfangen über USB die beiden Bytes "0xFF 0xFE" oder "0xFF 0xFD" dem Datensatz voran gestellt werden. Da diese Header-Bytes beim Senden vom Interface an den Computer somit auch im seriellen Puffer des Computers vorliegen, liest das Steuerprogramm auch diese Bytes mit aus. Anders herum ist auch so, dass das Interface vom Computer aus diese Header-Bytes erwartet. Wenn nun das falsche Protokoll ausgwählt wird, geht natürlich die Auswertung schief.

Was ist nun zur bisherigen Version 1.5 verändert?

Die neue Version hat mehrere XPressNet-Anschlüsse und ein Relais zur Trennung des Treiber-IC's MAX481 und der XPressNet-Anschlüsse hinzu bekommen. Das Layout wurde dahingehend verändert, das jetzt die USB-Buchse, die Status-LED's und zwei XPressNet-Buchsen auf einer Seite angeordnet sind. Dadurch kann der Baustein auch hinter einer Frontplatte montiert werden. Die Größe der Platine wurde so gewählt, dass auch statt der Frontplatte das Gehäuse LDT-01 (Fa. Littfinski-Datentechnik) verwendet werden kann. Für alle Interessierten befinden sich zur Veranschaulichung im Anhang einige Bilder vom Interface (Schaltplan, Layout,...).


Vielen Dank nochmals vor allem an Ronny, für die Freigabe der Unterlagen und die Unterstützung bei der weiterentwicklung des Interfaces.


@Ronny: Sofern Du nichts dagegen hast, vergebe ich meiner Variante die Version 1.6 und werde entsprechend Deiner bisherigen Vorgaben das USB-Interface unter der GNU-Lizenz offen legen. Die Veröffentlichung und ein Download-Link zu den Unterlagen werden in den nächsten Tagen dann auf meiner Homepage heym-family.de unter den Basteltipps bereit gestellt.


Gruß Michael
 

Anhänge

  • schaltplan.jpg
    schaltplan.jpg
    103 KB · Aufrufe: 168
  • board.jpg
    board.jpg
    230 KB · Aufrufe: 139
  • bestueckung.jpg
    bestueckung.jpg
    154,7 KB · Aufrufe: 145
  • interface-1.jpg
    interface-1.jpg
    69,2 KB · Aufrufe: 165
Hallo Michael,

an die Header Bytes habe ich gar nicht mehr gedacht. Man wird vergesslich. :)
Wenigstens funktioniert es jetzt.

Du kannst das gerne unter GNU-Lizenz stellen und veröffentlichen.

Gruß
Ronny
 
Hallo Michael,
ich habe mir deine Schaltung und Layout angeschaut:
Spannungsregler benötigen im allgemeinen je einen keramischen Kondensator am Eingang und am Ausgang und das möglichst nahe am Chip damit nichts anfängt zu Schwingen.
Genauso sollte man an jedes IC einen 100nF ganz nahe an den Versorgungsanschlüssen platzieren. Der Controller und der RS485-Transceiver haben keinen und C3 ist praktisch wirkungslos aufgrund der Induktivität der langen Leiterbahnen.
Weiterhin fehlt ein Elko der den Strom für die Leds in den Optokopplern puffert. So wird jede Flanke die von Optokopplern übertragen wird auch auf der Versorgungsleitung der Schaltung weiter übertragen und abgestrahlt.

Das hat vielleicht nicht direkt mit den Problemen um die es hier ging zu tun, aber es könnte sehr hilfreich sein zusätzliche Probleme zu vermeiden.

Das Relais hättest Du einsparen können indem du die Led in OK3 an der Anodenseite mit dem Controller verbindest und am Ausgang von OK3 noch einen Inverter in Form eines kleinen Mosfets eingefügt hättest.

Das ist bitte als konstruktive Kritik zu verstehen.

Gruß
tfi
 
Hallo tfi,

vielen Dank für Deine Antwort.

Leider bin ich weitestgehend Elektronik-Laie und habe von schwingungsverhalten elektronischer Schaltungen keinerlei Ahnung. Nur in Bezug auf den Spannungsrelger-IC kann ich Dir gedanklich folgen. Durch frühere Vergleiche verschiedener Schaltungen ist mir auch aufgefallen, dass die Kondensatoren fehlen, habe mir aber nichts weiter dabei gedacht.

Kannst Du mir bitte durch eine einfache Skizze zeigen, wo die Elkos für die Optokoppler im Schaltplan eingefügt werden müssten? Was wird eigentlich in die Versorgungsspannung abgestrahlt? Neigt diese zu Schwingungen?

Das mit den MOSFET geht ebenfalls für mich zu weit in die Tiefen der Elektronik.

Die Schaltung werde ich aber vorerst so einsetzen, wie Du sie kennst. Sollten Probleme auftreten, kann ich ja die Änderungen noch einfließen lassen.

Gruß Michael
 
Hallo Michael,
was den Elko angeht: einen 10uF zwischen VDD und VSS und für die andere Seite der galvanischen Trennung einen zwischen +5V und GND.
Vor dem Spannungsregler ist es auch noch Sinnvoll einen Elko zu spendieren. Dann werden die Lastwechsel in der Schaltung (Optokoppler an/an) nicht so stark auf die Zuleitung übertragen und damit abgestrahlt. Jede Leitung ist im Grunde auch eine Antenne die abstrahlt und das sollte vermieden werden.
Mach es zur gewohnheit bei jedem digitalen IC immer einen 100nF parallel zur Versorgung zu legen. Die Position des Kondensators sollte so dicht wie irgend möglich an den Versorgungsanschlüssen liegen, also möglichst kurze und breite Verbindungen zwischen Kondensator und IC.
Anbei noch eine mögliche Schaltung um das Relais einzusparen.

Gruß
tfi
 

Anhänge

  • DIR-Optokoppler.jpg
    DIR-Optokoppler.jpg
    84,3 KB · Aufrufe: 126
Hallo tfi,

vielen Dank für die Info's. Allerdings ergibt Dein Schaltungsvorschlag gleich die nächste Frage.

Wie wirkt der MOSFET in Deiner Schaltung? Wird hier nicht das Signal negiert? Und wenn ja, wie verhält sich dann das XPressNet?

Gruß Michael
 
Hallo mheym,
Hallo tfi,

vielen Dank für die Info's. Allerdings ergibt Dein Schaltungsvorschlag gleich die nächste Frage.

Wie wirkt der MOSFET in Deiner Schaltung? Wird hier nicht das Signal negiert? Und wenn ja, wie verhält sich dann das XPressNet?

Gruß Michael

Ja, das Signal wird invertiert und am Eingang des Optokopplers wird das Signal nochmals invertiert indem die Led auf der Anondenseite geschaltet wird. Damit stimmt das Signal wieder und wenn der Controller keine Stromversorgung hat liefert diese Schaltung nun ein Low was zur Folge hat das der RS485-Transceiver auf Empfang geschaltet ist und damit den Bus nicht mehr blockiert.
Gruß
tfi
 
Hallo Ronny,

Hallo Tfi815,

also kommt der MOSFET zwischen OK3 und RS485?
Gute Idee. Muss man in der Software dann auch negieren.

Gruß
Ronny

Genau, der Optokoppler gibt sein Signal auf den Mosfet, der invertiert das Signal und geht dann zum RS485-Transceiver auf \RE / DE Eingang.
In der Software muß man nichts ändern wenn man das Signal vom Contoller an die Anode der Led anschließt. Dadurch wird das Signal auch noch mal invertiert und eine zweifache Invertierung sorgt wieder für das Original Signal. Siehe Schaltung in Beitrag #342.
Gruß
tfi
 
Hallo tfi,

ja, wenn man die Hardware einmal ändert, kann man die LED auch gleich invertieren. Braucht man die Software nicht anfassen.

Gruß
Ronny
 
Hallo zusammen,

ich bin neu im Thema und beabsichtige das USB-Interface nach zu bauen. Nachdem was ich hier gelesen habe stellt sich mir die Frage ob es in naher Zukunft eine Version 1.7 geben wird. Die Platinen für die Version 1.6 habe ich gerade bei den Platinenbelichtern angefragt.

Gruss

Roman
 
Ich habe mich auch an einen Nachbau des USB-Interfaces gemacht. Da mir die Lösung mit dem Relais und den Optokopplern nicht so recht gefallen hat, habe ich einen ADUM1401 zur Potenzialtrennung eingesetzt und mit einem 74HC00 realisiert, dass bei ausgeschaltetem PC das Expressnet nicht blockiert wird. Außerdem sollte das Ganze in ein Pactec-CNL-Gehäuse passen. Deshalb wurde die Schaltung und die Leiterplatte neu entwickelt (Target 3001). Dank Bereitstellung der Quellen durch xemax (großes Dankeschön!) war die Softwareanpassung auch kein Problem.
Anbei ein Bild von meiner Lösung. Die Lichtleiter im Gehäusedeckel (links) ermöglichen die Sichtbarkeit der SMD-Leds von außen.

Die Frage ist jetzt, wie ich am Besten die Daten zur Verfügung stellen kann; eigenen Webspace habe ich nicht.

Thomas
 

Anhänge

  • DSC07690_klein.jpg
    DSC07690_klein.jpg
    74,8 KB · Aufrufe: 336
  • XBUS-USB-Interface_1.7.zip
    164,2 KB · Aufrufe: 187
Zurück
Oben