8-kanaliger 10-Bit-AD-Wandler von Conrad (Nr 190226) unter Windows (VB) nutzen

> ein Config Register eines 1090 zu beschreiben ist ja nicht unbedingt
> eine "Kunst" und die Daten seriel auszulesen auch nicht.

Tut mir Leid, aber es geht bei meiner Frage nicht um Kunst...


> Dieses "Bitgewackel" über RS232 oder IEE1284 hin zu bekommen schon ehr.
> Keine Ahnung, wa für Dich ein "Interface" ist.
> Der 1090 hat nur Takt und Daten.

Was willst Du mir damit sagen???


> Kurz und knapp, mit einer DLL und Excel kann mann damit so ziemlich
> alles anstellen was man will.

Welche neuen Erkenntnisse soll ich nun aus Deiner Stellungnahme 
gewinnen?

Ich mag polemisierende Stellungnahmen deshalb nicht, weil sie völlig 
überflüssig sind und meilenweit an sinnvollen Ergebnissen vorbeiführen.

Presario62 wrote:

> Da Conrad dieses Uralt-Interface nach wie vor verkauft, wäre eine
> Windowslösung doch sinnvoll. Da ich aber "das Rad nicht noch mal
> erfinden will" frage ich hier, ob die Windowslösung (dll) bereits
> existiert.

Naja, sinnvoll erscheint das nicht, denn die serielle Schnittstelle wird 
nicht wie vorgesehen benutzt, sondern ein Bit-Gewackel veranstaltet, um 
den LTC anzusprechen. Will man das unter Windows machen hat man mehrere 
Probleme:

1. man benötigt einen speziellen Treiber/DLL zur direkten Vergewaltigung 
des COM-Ports. portio wäre etwas.

2. Ab Vista ist damit sowieso Schluss, meines Wissens gehen solche 
krummen Dinger dann nicht mehr

3. Das weitaus schlimmste Problem: Man bekommt keine deterministischen 
Abtastungen hin, man kann also bestenfalls irgendwelche sich langsam 
verändernden Spannungen messen. Windows ist ohne extra Hardware nicht in 
der Lage, konstante Zeitverhältnisse an externen Shcnittstellen 
bereitzustellen.

Also: Man kann das natürlich mit Windows hinbasteln. Mehr als Gefrickel 
wäre es aber nicht. Außerdem sterben die echten COM-Ports an 
Consumer-PCs langsam aus, so dass das eh kaum zukunft hätte.

In der Anleitung von Conrad steht direkt drin, dass der COM-Port 
missbraucht wird. Gleich am Anfang der Schaltungsbeschreibung. Wenn es 
über die Win-API Funktionen funktioniert ist ja immerhin etwas.
Dann hätten sich 1. und 2. wahrscheinlich erledigt.

3. bleibt aber. Es geht nicht darum, wie schnell der Wandler ist. Es 
geht um die Äguidistanz der Abtastungen. Die Abtastung wird per Software 
von Windows aus gesteuert. Man kann bei einem nicht echtzeitfähigen 
Betriebssystem nicht vorhersehen, wann genau dann die Abtastpunkte 
kommen. Um Spannungsverläufe messen zu können, benötigt man 
Äquisitsanz.

Wenn du meinst, das ist unqualifiziert, dann halt ich mich ab hier raus. 
Ich entwickle den ganzen Tag hochwertige PC-basierte Messtechnik, da 
brauch ich mir das von dir nicht sagen zu lassen. Und so einen Schrott 
bestell ich bestimmt nicht, um es mal auszuprobieren.

Einen schönen Tag noch.

Christian hat recht. Diese "Schaltung" ist Pfusch.

Der Gedanke, "Bitbanging" mit der seriellen Schnittstelle zu betreiben, 
ist der erste Kardinalfehler, und die Hoffnung, das mit einem Programm 
--egal in welcher Programmiersprache-- mit einem reproduzierbaren 
Zeitverhalten unter einem Betriebssystem wie Windows hinzubekommen ist 
der zweite. Windows hat eine Schedulergranularität von bestenfalls 1 
msec - häufiger als im 1msec-Takt kann ein Windows-Programm keine 
Systemfunktionen aufrufen, was für das Bitbanging auf der seriellen 
Schnittstelle recht oft passieren muss.
Lösungen à la "giveio.sys" mögen mit der Parallelschnittstelle noch 
funktionieren, die serielle Schnittstelle sollte man tunlichst nicht 
damit befummeln. Das hat damit zu tun, daß die bereits vom dafür 
zuständigen Devicetreiber angesteuert wird, und im Gegensatz zum 
interruptlosen Parallelport eben auch interruptgesteuert. Da würden 
direkte Hardwarezugriffe dazwischenpfuschen, mit interessanten 
Nebenwirkungen (blaue Bildschirme o.ä.).

Der Ansatz ist also kaputt. Conrad hat Müll gebaut, der zu DOS-Zeiten 
noch tolerabel war (DOS selbst war ja auch so eine Art Müll), aber sich 
mit Betriebssystemen gar nicht verträgt.

Wenn mit dieser Schaltung "gemessen" werden soll, dann muss die 
Ansteuerung des ADC mit einem µC erfolgen. Der kann eine 
deterministische Zeitbasis zur Verfügung stellen, in tatsächlich 
gleichmäßigen Abständen messen und die Resultate in aufbereiteter Form 
in einer dafür geeigneten Weise über die serielle Schnittstelle 
übertragen, nämlich in Form von einzelnen Bytes über die TxD-Leitung.

Damit ließe sich die Investition in diese Müllschaltung retten.

Der Versuch aber, irgendwelche DLLs oder was auch immer für den 
Bitbanging-Betrieb zu schreiben, ist sinnlos.

Das Problem liegt darin, daß das Zeitverhalten solchen Gefrickels 
absolut nicht vorhersagbar ist. Sicher, das Timing ist unkritisch, so 
etwas wie das gelegentliche Ermitteln von Messwerten wird schon 
irgendwie gehen.

Damit kann man dann vielleicht irgendwelche Gleichspannungen messen, 
aber --wie Du vorhast-- Spannungsverläufe eben nicht, weil der 
Zeitanteil dafür weitestgehend unbrauchbar ist. Du wirst einen einzelnen 
Messvorgang zeitlich nicht sehr viel genauer als im Sekundenraster 
durchführen können, plus/minus ein paar hundert Millisekunden.

Wenn Du Dir dessen bewusst bist, bitte, nutze den Kram.

Ist ja wirklich interessant, wozu Ihr Euch berufen fühlt. Es geht hier 
nicht um die Bewertung einer Schaltung oder der Suche nach anderen 
Alternativen; - nein, es geht ausschließlich darum, ob eine 
entsprechende DLL für exakt diesen Zweck bereits existiert, oder nicht.

Die Schaltung mag Vor- oder Nachteile haben, für bestimmte Zwecke 
geeignet oder auch nicht geeignet sein; - wen interessiert das? Nun, den 
Anwender, der die Schaltung verwenden will. Davon gibt es scheinbat 
genug, denn die Schaltung wird seit Jahren unverändert verkauft.

Ach ich habe mir den Bausatz bei Conrad vor vielen Jahren gekauft. Ich 
habe damit verschiedene Temperatursensoren überwacht, über sehr lange 
Zeit.
Zum Schluß lag das Interface mehrere Monate im irgend einer Kiste.

Bei der Suche nach AD-Wandlern erinnerte ich mich an diese Schaltung und 
baute sie in das nächste Projekt ein. Dabei fiel mir auf, dass es diese 
Schaltung immer noch zu kaufen gibt, obwohl dieser Schaltung nach wie 
vor nur völlig veraltete DOS-Software beiliegt.

Kurzum, ich machte mich daran, die mitgelieferte DOS-Software auf VB5 zu 
portieren. Für mein Projekt sollte das natürlich viel eleganter sein, 
deshalb machte ich mich daran, eine DLL zu entwickeln.

Anhand der Nachfrage kann ich nun behaupten, das es immer noch viele 
Anwender dafür gibt. Allerdings wollte ich das Rad nicht nochmals 
erfinden. Deshalb habe ich hier gefragt, ob es diese DLL eventuell schon 
gibt.

Mich interessieren die Vor- und Nachteile dieser Schaltung überhaupt 
nicht. Jeder Anwender sollte für sich selbst entscheiden, ob diese 
Schaltung für sein Vorhaben geeignet ist, oder nicht. Mich interessiert 
nicht, ob die Messergebnisse 1 ms früher oder 1 ms später von Windows 
eingelesen werden oder nicht. Für meine Anwendung sind all diese Dinge 
ohne Belang.

Mich interessiert nur, dass dieses Interface jahrelang zuverlässig 
seinen Dienst geleistet hat und dies weiterhin tun wird. 
Selbstverständlich könnte ich mit einem Atmega etwas Ähnliches 
herstellen; - jedoch war dies nicht meine Absicht.

Nochmal: Es geht um eine DLL für genau diese Schaltung

Niemand will eine Bewertung, sondern einzig und allein die Information, 
ob diese DLL bereits existiert oder nicht ist hier von belang. Das kann 
doch nicht so schwer zu verstehen sein...

Wenn in diesem Forum jemand um Hilfe fragt, muss er einfach auch damit 
leben, daß sein Anliegen bzw. sein Ansatz auch inhaltlich kommentiert 
wird.

Das zeigt, daß sich die Antwortenden auch mit dem Problem und dessen 
Lösung auseinandersetzen, auch wenn das dem Fragestellenden nicht 
unbedingt weiterhilft, weil genau die Antwort, die er gerne hätte, ihm 
nicht gegeben wird.
So aber ist das Leben.

Aus den von Christian und mir angeführten Gründen ist es nicht 
sonderlich wahrscheinlich, daß sich schon mal jemand die Mühe gemacht 
hat, eine DLL oder sonstige Codeunterstützung für dieses Gerät zu 
entwickeln.

Nochmals vielen Dank für Eure interessanten Gedanken zu diesem 
Interface. Allerdings muss ich Euch sagen, dass mir all diese Dinge 
durchaus bekannt sind.

Gewöhnlich verwende ich Atmel Atmega für solche Zwecke. Jetzt habe ich 
für einen bestimmten Zweck eine schnelle Lösung gesucht und bin beim 
Durchsuchen meiner Bastelecke über diese "alte" Schaltung "gestolpert".

Zu meinem Bedauern konnte ich keine windowskonforme Software dazu 
finden; - obwohl dies sehr einfach zu programmieren ist. Nennt es wie 
Ihr wollt, aber ich habe beschlossen, dem Abhilfe zu schaffen.

Um beispielsweise eine Raumtemperaturüberwachung oder ein Ladegerät für 
NiCd - Akkus zu "basteln" genügt dieses Interface allemal. Da nur die 
Leitungen DTR, RTS und CTS verwendet werden, bietet es sich natürlich 
an, RX und TX für andere Zwecke zu nutzen.

Unbestritten, dieses Interface eignet sich nicht zur zeitkritischen 
Messwerterfassung; - aber das war doch vorher völlig klar (oder nicht?). 
Ganz offensichtlich erfreut sich dieses Interface großer Beliebtheit; - 
umso mehr wundert mich der Umstand, dass bisher noch Niemand 
Windowssoftware dafür veröffentlicht hat.

Die Sache ist es nicht wert, dass man sich darüber streitet. Es haben 
mich viele "Bastler" angemailt, ob ich denn über eine entsprechende DLL 
verfüge. Das ist nicht der Fall. Deshalb habe ich erstmal eine Lösung 
für VB5 erstellt, damit dieses Interface unter Windows nutzbar wird. 
Keiner wollte dafür extra DOS installieren...

Offensichtlich hatten nicht Wenige Probleme damit, dieses Interface 
unter Windows nutzen zu können. Eigentlich bereue ich mein 
Entgegenkommen bereits, denn es lag nicht in meiner Absicht, eine 
Wertediskussion los zu treten.

Jemand hat mich gebeten, ein Programmierbeispiel dafür zu 
veröffentlichen und vielleicht sogar eine DLL zur Verfügung zu stellen. 
Nun Erstes habe ich getan und, wenn ich Zeit dafür finden kann, werde 
ich einige nützliche Funktionen in einer DLL zusammenfassen.

Bevor ich dies aber tue, will ich sicher gehen, dass ich nicht meine 
Zeit für etwas "opfere", was es längst gibt. Dies ist nicht aus "meinem 
Mist gewachsen", sondern ich wurde darum gebeten. WEnn ich Jemand damit 
einen Gefallen tun kann, ist meine Mühe nicht vergebens.

Ja, jeder halbwegs versierte Programmierer könnte dies tun; - aber 
offensichtlich hat dies bisher noch keiner getan.
Vielleicht ist dies hier nicht der richtige Ort dafür, aber man bat mich 
das Programmierbeispiel und ggf. die DLL hier zu veröffentlichen.

Ob das Alles gerechtfertigt ist interessiert mich nur sekundär. Einer 
der Betreffenden hat jedenfalls meine Schaltung mit dem Interface 
erfolgreich nachgebaut; - ob es noch mehr werden wird sich zeigen, 
spielt letztendlich aber keine Rolle.

Letzten Endes wollte ich damit nur beweisen, dass völlig veraltete 
Technik auch heute noch auch unter Windows "sinnvoll verwendbar" ist, 
sofern man das will. Damit ist es dem weniger versierten Bastler auch 
möglich selbst etwas anspruchvollere Anwendungen (z.B. 4-fach AkkuLader 
mit DeltaPeak-Abschaltung mit Temperaturüberwachung) zu erstellen.

Der Modellbaufreund ist darüber höchst erfreut. Langfristig ist geplant, 
ein Ladegerät für Lipos, NiCd, NiMH, Bleiakkus, etc. mit Hilfe eines 
oder mehrer Atmels und einem Colordisplay zu entwerfen. Es soll sowohl 
eigenständig als auch PC-gebunden folgende Möglichkeiten bieten:

Reflex-Ladeverfahren, Temperaturüberwachung, Normalladen, beschleunigtes 
Laden, Schnelladen, Erhaltungsladen, Entladen (Messen), Auffrischen, 
Analysefunktion und eine Verwaltungsfunktion für die Zustandsdaten der 
einzelnen Akkupacks. Dabei sollen gleichzeitig und unabhängig 
voneinander 8 Akkupacks "bearbeitet" werden können. Berücksichtigt man 
die mögliche Zellenzahl und Kapazitäten der Modellbauakkus im 
Zusammenhang mit der Vielfalt möglicher AkkuTypen, erkennt man sehr 
schnell, dass dies eine größere Herausforderung (auch an das Material) 
darstellt.

Selbstverständlich wird dieses Projekt dann auch hier "zerrissen" 
werden. Ich freue mich schon auf die "Resonanz".

Das "Kraftwerk" sollte natürlich auch "nachbausicher" und erweiterbar 
sein. Modellbauvereine warten schon sehnsüchtig darauf, dass dieses 
Projekt endlich begonnen wird (...denn bekannlich sind die Wintermonate 
"Bastelmonate").

Da nun der Stellenwert dieser Kleinigkeit geklärt ist, hoffe ich, dass 
ich mir die Arbeit mit der leidigen DLL nicht vergeblich mache. Wäre 
doch schade um die Zeit, oder?

In der Zeit, die ich für das Verfassen dieser Stellungnahme benötigt 
habe, hätte ich womöglich die gesamte DLL fertig stellen können...

Also nochmals meine Bitte: "Wenn Jemand eine solche DLL bereits erstellt 
hat, bitte ich um Nachricht". -> Danke!

Für die Hardware-Fetischisten:

Für die gegebene Anwendung sind keine zeitkritischen Abläufe notwendig. 
Das Laden eines Akkus ist eine "langfristige" Angelgenheit. Unabhängig 
davon, ob schnell, beschleunigt oder normal geladen wird, die Abtastung 
erfolgt im Sekundenbereich. Dabei ist es völlig unerheblich, ob 
Verzögerungen im Mikro- oder Millisekundenbereich auftreten.

Ebenso verhält es sich bei der Temperaturüberwachung. Alle diese 
Vorgänge finden viel langsamer statt. Wenn ich nun beispielsweise 980 ms 
lade, 10 ms entlade und in weiteren 10 ms die Spannung messe, dann werde 
ich wohl auf eine andere Lösung zurückgreifen.

Hier geht es ausschliesslich um Langzeitverhalten. Wen interessiert es, 
wenn die Delta-U-Peak-Erkennung um 100 ms verzögert erfolgt, wenn der 
Ladevorgang 1 Stunde dauert?

Im gegebenen Fall beträgt der Messzyklus 700 ms und könnte problemlos 
auf beispielsweise 10 Sekunden erhöht werden. Selbst wenn erst nach 100 
Sekunden der Ladevorgang unterbrochen wird, würde der Akku vermutlich 
keinen Schaden nehmen. Die Erwärmung wäre dann von Außen noch nicht 
messbar.

In diesen Fällen genügt diese "Hardware" durchaus dem Zweck. Wir wollen 
damit keinen "Spektrumanalyser" (oder Ähnliches) realisieren, wobei 
hierbei auch das zu analysierende "Spektrum" ausschlaggebend wäre...

Um die "Ladekurve" eines NiCd-Akkus zu analysieren genügt dieser Aufbau 
völlig und bedarf keiner weiteren Erklärung, oder? Da der betreffende PC 
nicht zur Berechnung von zahllosen Grafiken (oder Ähnlichem) 
herangezogen wird, kann man auch von tadelloser Funktion ausgehen...

Sollten die Kids im Verein diesen PC zum Rendern von Videos benutzen, 
wird wohl Niemand gleichzeitig Akkus damit laden... grins!(...die 
Hoffnung ist berechtigt, oder?)