www.mikrocontroller.net

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


Autor: Presario62 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es bereits eine dll, die die Funktionen dieses Interface 
unterstützt, oder macht es Sinn eine solche zu entwickeln? Das 
Anwendungsspektrum sehe ich eher mäßig, aber, da ich nun schon dabei 
bin...

Diese Schaltung basiert auf einem LTC 1090 und wird über die serielle 
Schnittstelle des Computers betrieben. Eine sehr einfache und preiswerte 
Methode um Messergebnisse zu erfassen. Allerdings lag keine 
Windows-komforme Software bei. Deshalb habe ich das TurboBasic-Script an 
VB angepasst.

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.

Danke

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nun,
ein Config Register eines 1090 zu beschreiben ist ja nicht unbedingt 
eine "Kunst" und die Daten seriel auszulesen auch nicht.
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.
Kurz und knapp, mit einer DLL und Excel kann mann damit so ziemlich 
alles anstellen was man will.

Ja,
 es exitiert zB. eine Lösung für den Max186.
Die muß "nur" an den 1090 angepasst werden.
Aber wozu ???
Mit Excel hast Du alles was Du brauchst.

Autor: Norbert Gernand (Firma: privat) (presario62)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Presario62 (Gast)
Datum:

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

Weiß nicht, was Du hast, funktioniert problemlos mit Standardfunktionen 
des MSCOMM-Steuerelements

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

Das musst Du mir näher erklären; - offensichtlich weisst Du etwas, was 
ich nicht weiss... ;-) ...übrigens, welche "krummen Dinger"???

> 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.

Nun dieses Interface benötigt exakt 175 Mikrosekunden für die Wandlung. 
Mir ist nicht bekannt, dass andere Bausteine keine Zeit für die Wandlung 
benötigen... Wo siehst Du da ein Problem? Welche Hardware sollte Windows 
für den Betrieb dieses Interface benötigen???

Du hast das Thema verfehlt! Es geht um die Frage, ob die DLL, die ich 
derzeit entwickle, eventuell schon existiert oder eben nicht. Wenn sie 
bereits existiert, dann muss ich sie ja nicht nochmals entwickeln. 
Verstehst Du das jetzt?

Die Hard- und Software funktioniert problemlos und zuverlässig. Probiers 
doch einfach aus, anstatt völlig unqualifizierte Bemerkungen von Dir zu 
geben.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bobby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir mal das C-Datenblatt angesehen.

Obwohl es nicht direkt dokumentiert ist:
Für mich sieht es so aus als wäre das Timing
unkritisch, da immer die CLK-Leitung das nächste Bit
einliest oder ausgibt. Das kenne ich auch von TTL-Schieberegistern.
Ich frage also: WO ist das Problem, wenn die Ansteuerung
mit Windows Standardfunktionen erledigt werden kann?
Sowas dürfte auch unter Linux leicht zu implementieren sein.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
@Christian R. (supachris)


>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.

Das ist nicht immer ausschlaggebend, das gestandene Fachleute
oft einen eingefahrenen Tunnelblick haben...Und nicht so schnell 
beleidigt sein.
;-)


Ansonsten hast Du und Rufus recht.

@Norbert Gernand (Firma privat) (presario62
Ich verstehe dein Anliegen.
Wenn du von deinem Projekt Überzeugt bist, dann mache es .

"Der Weg ist das Ziel"


Ich verunstalte schon über 15 Jahre  gerne die Serielle...aber immer 
weniger.
In Professionellen und Semiprofessionellen Produkten sollte Exakt 
gearbeitet werden

Grüße

Autor: Norbert Gernand (Firma: privat) (presario62)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Norbert Gernand (Firma privat) (presario62)

Ich glaube das alle dein Anliegen verstanden haben.

Wenn deine DLL fertig ist ,stelle sie hier zur Verfügung.

MfG

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Norbert Gernand (Firma: privat) (presario62)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Norbert Gernand (Firma: privat) (presario62)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?)

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Norbert Gernand (Firma privat) (presario62)

...sei nicht so frustriert;-)

Autor: Starbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es war nach einer Dll gefragt ...

Damit kann ich nicht dienen, aber es gibt durchaus professionelle 
Software unter WINDOOS, die diese Art Adapter unterstützt. Die Firma 
ABACOM bietet u.a. Profilab an, dass den 8-Kanaladapter an der seriellen 
Schnittstelle bedient. (siehe in der Hardwareliste unter "Voltcraft"). 
Die unterstützen auch die Module von der Fa. MODULBUS, die als SERAI-xxx 
ähnliche Schaltungen, auch mit dem MAX186, aufweisen. Ohne Werbung für 
ABACOM machen zu wollen: die haben das "Bit-Gewackel" am seriellen Port 
ganz gut im Griff.

Und die Preise sind auch vertretbar, zumal man eine kpl. 
Areitsobergläche mit Arithmetik pp. für seine Messaufgabe nett 
"zusammenklicken" kann. Anschließend hat man eine .EXE-Datei.

Gruß
Starbär

Autor: Starbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so ganz allein scheinen die Bastler dieses Bausatzes doch noch nicht zu 
sein.
Bei J.Plate gibt es eine schöne kurze Ansteuerung in C.
Link: 
http://www.netzmafia.de/skripten/hardware/da-wandl...

Autor: Messknecht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ABACOM bietet u.a. Profilab an...

Wenn man keine Ansprüche an hohes und genaues Timing hat ist ProfiLab 
sicher eine gute Alternative.

Autor: Sucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ich habe den Thread nur überflogen. Ich habe vor ca. 1 Jahr mal so ein 
Board mit C# unter Windows getestet und es ist "prinzipiell" gelaufen. 
Ich habe ein vohandenes Testprogramm umgestrickt und so ein Board mit 
dem LTC1290ADC  betrieben. Das Programm ist "katastrofal 
zusammengestrickt" aber es läuft. Ich habe es jedoch nicht weiter 
verfolgt. Ich bin jedoch damals zu dem Ergebnis gekommen, dass man einen 
Atmega zwischenschaltet und dann das Ganze über die ser. Schnittstelle 
anspricht.
Falls Interesse an dem schlechten Programm besteht, kann ich das ja mal 
raussuchen.

MfG
Achim

Autor: TigersClaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
ich habe den Thread mal durchgelesen.
Und kann den negativen Aussagen nicht zustimmen.
Das RS232 / COM Port am PC aussterben soll/wird ist möglich, scheint
aber aktuell nicht das Problem zu sein.

Vor kurzem habe ich unter LabView eine VI für den Bausatz von Conrad (Nr 
190226) geschrieben.
Unter Windows XP! null Timingprobleme!
Und solange VISA-Standarts für RS232 gibt, wird auch Windows Vista (und 
Nachfolger ) hier mitzeihen müssen.

Mit LabView eine DLL zu erzeugen ist kein Problem für mich.
Fragt sich nur ob diese DLL, auch für deine zwecke verwendbar ist.

Schau mal bei folgende Web-Seiten vorbei, dort gibs Infos zu dem
8-kanaliger 10-Bit-AD-Wandler von Conrad (Nr 190226)

http://www.netzmafia.de/skripten/hardware/da-wandl...
http://home.arcor.de/bernd_kunze/ad_tricks.htm

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.