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
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.
> 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.
> 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.
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.
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.
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.
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
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...
@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
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?)
@Norbert Gernand (Firma privat) (presario62) ...sei nicht so frustriert;-)
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
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-wandler/da-wandler.html
> ABACOM bietet u.a. Profilab an...
Wenn man keine Ansprüche an hohes und genaues Timing hat ist ProfiLab
sicher eine gute Alternative.
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
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-wandler/da-wandler.html http://home.arcor.de/bernd_kunze/ad_tricks.htm
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.