Ich suche einen GPIB-Adapter bis ca. 140.- zum Anschluß an einen Laptop. Als Schnittstelle anbieten würde sich USB2, Gbit-LAN oder PCMCIA. Programmieren möchte ich vor allem mit PureBasic oder HT-Basic. Bei ebay ging ein NI GPIB-USB-HS gebraucht für 341.- weg. Neu soll der angeblich 689.- kosten. Das ist mehr Geld als manche neue Messgeräte mit USB oder RS232 heute kosten. Bei Reichelt kostet ein Tisch-Multimeter aus Fernost gerade mal um die 100.-. Muss da so ein Adapter das 2-fache bis zum 7-fachen kosten? Was gibts denn an Alternativen? Welcher Adapter passt zu PureBasic? Hat da jemand eine positive Erfahrung?
Matthias W. schrieb: > Muss da so ein Adapter das 2-fache bis zum 7-fachen kosten? Das wird an der Stückzahl liegen, und daran, daß "der Markt" es hergibt. Immerhin "nur" 214 EUR kostet das Ding hier: http://www.digitalo.de/products/147280/Rigol-USB-Gpib-Schnittstellenmodul.html
Kostet deine Arbeitszeit etwas? Wieviel Stunden kannst du in das billige Teil zusätzlich investieren, damit es nicht das Teure wird? Hat das einen Grund warum es GPIB sein muss?
DirkB schrieb: > Kostet deine Arbeitszeit etwas? ja. > Wieviel Stunden kannst du in das billige Teil zusätzlich investieren, > damit es nicht das Teure wird? es ist die Frage ob das teure Teil einem so sehr viel Zeit sparen wird. Siehst Du das so? > Hat das einen Grund warum es GPIB sein muss? Ich habe 2 Messgeräte mit GPIB. Ist die Frage ob man besser auf was anderes umsteigt. USB? Wie zukunftssicher ist das? Nun kommt ja USB3. Was geht denn wirklich stressfrei? LAN?
Matthias W. schrieb: > USB? Wie zukunftssicher ist das? Nun kommt ja USB3. Und? Funktionieren an einem USB3-Anschluss keine USB1.1-Geräte? Doch. Sie tuns. Sonst müsstest Du Mäuse und Tastaturen ersetzen.
Matthias W. schrieb: > es ist die Frage ob das teure Teil > einem so sehr viel Zeit sparen wird. > Siehst Du das so? 1.: Du bezahlst nicht die Hardware, sondern die Treiber und die Anbindung an z.B. HP VEE oder Labview oder sowas. Wenn Du Labview nehmen willst, musst Du NI-kompatible Treiber haben. Manche Hersteller verlangen dafür extra. Dito für Software von Tektronix usw. 2.: Billige Adapter können manchmal nicht alles. Manche können nur Talker sein. Da musst Du schauen, was für IB Features Du brauchst. > Was geht denn wirklich stressfrei? Labview plus die passende Hard- und Software ist einigermaßen stressfrei. fchk
Rufus Τ. Firefly schrieb: > Und? Funktionieren an einem USB3-Anschluss keine USB1.1-Geräte? Doch. > Sie tuns. Sonst müsstest Du Mäuse und Tastaturen ersetzen. Um 1984 verwendete ich HPBASIC auf einem HP9816S-Rechner. Das war ein 68000 mit 8 oder maximal 10MHz. Der hatte GPIB serienmäßig. Damit liefen Plotter, Tabletts, Festplatten, Diskettenlaufwerke, Thermometer, Messdatenerfassungssysteme, HP-Voltmeter usw. absolut stressfrei und schnell mit 1-2 Zeilen Code. Seitdem sind 36 Jahre vergangen in denen "Fortschritt" stattgefunden haben sollte. Die Taktfrequenz explodierte wie auch der Speicher und die Größe der Treiber ! Unter Fortschritt verstehe ich: + Funktioniert so problemlos wie damals, nur schneller + kostet weniger weil Hardware heute billiger GPIB eingebaut in Rechner kenne ich nicht mehr. USB-Adapter für GPIB scheinen keinesfalls problemlos ! HT-Basic empfiehlt bestimmte Adapter für ihre Sprache. Unter Windows empfehlen sie andere als unter Linux. Keithley-Adapter machen Stress unter Labview. Es ist leider keinesfalls klar, ob solche Adapter an USB3 problemloser arbeiten werden als es unter USB2 oder USB1.1 der Fall gewesen ist. Wer wird noch Updates machen für einen Alt-Adapter wenn USB3 mal da ist? Ist das Geschäft nicht recht schnell-lebig?
Frank K. schrieb: > Labview plus die passende Hard- und Software ist einigermaßen > stressfrei. gibts denn noch was anderes stressfreies? Oder ist alles außer Labview nicht stressfrei? PureBasic geht nicht stressfrei? Oder gibt es jemanden der das mal genutzt hat?
Matthias W. schrieb: > gibts denn noch was anderes stressfreies? Ist die Frage, was dir Stress macht. Mir würde schon das drunter liegende Windows Stress machen, dafür ist es für mich reichlich problemlos, einfach mal ein paar Scripte in einer Scriptsprache zu schreiben.
Die Karten von NI und Agilent kann man über die Programierschnitstellen SICL und VISA ansprechen. Ob du da mit PureBasic drankommst weiß ich nicht. Ist aber auch nur eine DLL. GPIB war schon gut, nutze ich immer noch. Sind aber auch "teure" Adapter von Agilent. (USB, LAN) Der schnellere Nachbau von TAMS hat Schwierigkeiten bei der Buffergröße gemacht. Was mittlerweile wieder geht ist die Serielle Schnittstelle dank der USB-Seriell-Umsetzer. Die gibt es auch 4-Fach. Messgeräte mit USB mag ich nicht. Da nehme ich lieber gleich LAN. USB aus einer Scriptsprache anzusprechen macht kein Spaß. Seriell und LAN gehen dagegen locker von der Hand.
Matthias W. schrieb: > Frank K. schrieb: >> Labview plus die passende Hard- und Software ist einigermaßen >> stressfrei. > > gibts denn noch was anderes stressfreies? > Oder ist alles außer Labview nicht stressfrei? > > PureBasic geht nicht stressfrei? Ist das für die Verwendung mit irgendeinem IB-Adapter zertifiziert? Bedenke: IB ist unter Windows kein Standard, d.h. es gibt keinerlei Norm, wie irgendeine spezielle GPIB-Funktion angesprochen wird. Damit ist der einzige Weg: - Programmierumgebung auswählen, die für einen bestimmten Adapter zertifiziert ist - dafür den bestimmten Adapter kaufen (egal was immer der dann auch kostet) - das ganze unter einer supporteten Betriebssystemversion fahren - unter Beachtung der sonstigen Hardwarevoraussetzungen Alles andere kann funktionieren, muss aber nicht. Du kannst natürlich auch selber einen GPIB-Adapter basteln. Das haben andere vor Dir auch schon erfolgreich geschafft. Ob das dann für Dich stressfreier ist, kann ich nicht sagen. Labview ist in der Industrie immerhin ziemlich weit verbreitet, hier kannst Du mit gutem Support für GPIB-Adapter und GPIB-Geräte rechnen. fchk PS: Mit Adaptern von National Instruments und HP/Agilent machst Du eigentlich nichts verkehrt.
Jörg Wunsch schrieb: > Ist die Frage, was dir Stress macht. Mir würde schon das drunter > liegende Windows Stress machen, ja - das kann in der Tat eine Menge Stress machen. > dafür ist es für mich reichlich > problemlos, einfach mal ein paar Scripte in einer Scriptsprache > zu schreiben. Da hast Du auch wieder recht. Wenn man fit ist mit Scriptsprachen ist das ja eine gute Lösung für manche Probleme. Die Frage ist halt wie man so eine Messaufgabe am sinnvollsten erschlagen kann. Ein Weg ist es Messgeräte zu nehmen, z.B. auch welche mit GPIB-Schnittstelle und diese anzusprechen. Dazu gab es früher dieses HPBASIC. Heute gibt es eine Portierung davon für Linux: http://www.tamsinc.com/basic/blx/blx.htm "TAMS BASIC for Linux is a direct, source code port of Agilent's (HP) BASIC/UX 700 (Rocky Mountain BASIC). Now your BASIC code can migrate to PCs running Red Hat Enterprise Linux. The current version includes CSUB support, BASIC Plus, TAMS 82091 I/O Libraries for Linux, as well as driver support for TAMS GPIB and GPIO cards and 83488 USB-GPIB Controller." BASIC for Linux License to use (LTU) $725.00 Und es gibt eine Portierung für Windows: http://www.tamsinc.com/basic/bwin/bwin.htm Es gibt GPIB-Adapter und Karten dazu wie: TAMS 63488 USB GPIB $1,773.00 TAMS 61488 PCI GPIB $1,773.00 TAMS 64488 PCIe GPIB $1,773.00 TAMS 64487 Low Profile PCIe GPIB $1,773.00 TAMS 65488 Dual Head PCIe GPIB PureBasic ist eine Sprache die sowohl unter Linux als auch unter Windows laufen kann. DLLs können verwendet werden um sich an Hardware anzubinden. Die Preise für PureBasic liegen weit unter denen der obigen Lösungen. Natürlich kann man auch selbst sein Mess-System zusammenbauen. Ein paar ADC kaufen, ein paar DAC, ein paar Optokoppler, eine uC-Platine, ein wenig Messdatenaufbereitung, einige Zeilen C-Code, viel Zeit und fertig ist die Laube . . . Vielleicht ist das stressfreier als einen GPIB- Adapter zum Laufen zu bringen für ein altes Keithley-Multimeter . . .
Matthias W. schrieb: > Es ist leider keinesfalls klar, ob solche Adapter > an USB3 problemloser arbeiten werden als es unter > USB2 oder USB1.1 der Fall gewesen ist. Es ist sogar davon auszugehen, daß sie genauso problemlos bzw. genauso problematisch funktionieren, wie sie es unter älteren USB-Versionen taten. Großartig ändern wird sich ihr Verhalten nicht. Das Problem dürfte hier in der Historie liegen; IEEE488 ist eine steinalte Schnittstelle, und entsprechend gibt es unterschiedlich alte Ansätze, damit zu kommunzieren. Ganz alte Programmiersysteme haben direkt mit irgendwelchen I/O-Schnittstellen irgendwelcher ISA-Karten kommuniziert, etwas später gab es dafür irgendwelche DLLs, die wurden dann irgendwann auf 32-Bit-Codebasis portiert, und mussten dann irgendwann (mit dem Wechsel vom Frickel-Windows 95 auf NT, was 2000, XP etc. einschließt) einer Architektur aus Devicetreiber und passender DLL weichen. Und da es unterschiedliche Softwarehersteller gibt, gibt es natürlich auch unterschiedlich "kompatible" Auslegungen der verschiedenen Schnittstellen ... Das ist also wie ein sehr dicker Schichtkuchen.
DirkB schrieb: > Die Karten von NI und Agilent kann man über die Programierschnitstellen > SICL und VISA ansprechen. Ob du da mit PureBasic drankommst weiß ich > nicht. Ist aber auch nur eine DLL. Wenn eine DLL da ist müsste es gehen. Wie gut das jedoch geht ist halt die Frage. Daher meine obige Frage. Es kann Wochen dauern für scheinbar einfache Dinge eine Lösung zu haben. > GPIB war schon gut, nutze ich immer noch. Sind aber auch "teure" Adapter > von Agilent. (USB, LAN) Leider war alles von HP reichlich teuer. Dafür aber auch stressfrei. > Der schnellere Nachbau von TAMS hat Schwierigkeiten bei der Buffergröße > gemacht. das ist schade. Ließ sich das Problem denn lösen? > Was mittlerweile wieder geht ist die Serielle Schnittstelle dank der > USB-Seriell-Umsetzer. Die gibt es auch 4-Fach. das ist gut. Du meinst diese billigen Adapter? > Messgeräte mit USB mag ich nicht. Da nehme ich lieber gleich LAN. Kann ich verstehen. > USB aus einer Scriptsprache anzusprechen macht kein Spaß. Seriell und > LAN gehen dagegen locker von der Hand. dann wäre dies also zu bevorzugen. HP führte damals ja auch eine Art "USB"-Schnittstelle ein. HIL hieß das damals. Das waren so telefonartige Stecker. Die Netzwerkstecker sehen heute ähnlich aus. GPIB-Adapter für LAN gibt es ja auch. Meines Wissens gab es auch Selbstbauprojekte für solche Adapter von GPIB an den uC. Letzlich müsste ein ATmega8 ja reichen. 2 Treiberchips dran, die GPIB-Buchse, ein FTDI-Baustein. Die Software ist vermutlich weniger trivial. Auch daran haben jedoch schon Leute gearbeitet.
Rufus Τ. Firefly schrieb: > Es ist sogar davon auszugehen, daß sie genauso problemlos bzw. genauso > problematisch funktionieren, wie sie es unter älteren USB-Versionen > taten. Großartig ändern wird sich ihr Verhalten nicht. da hast Du wohl leider recht. Es ist nicht zu erwarten daß das Chaos was da heute schon zu beobachten ist kleiner wird. > Und da es unterschiedliche Softwarehersteller gibt, gibt es natürlich > auch unterschiedlich "kompatible" Auslegungen der verschiedenen > Schnittstellen ... ja. Jeder kocht sein Süppchen . . . > Das ist also wie ein sehr dicker Schichtkuchen. also ein Wunder, wenn das ganze Kuddelmuddel überhaupt irgendwie läuft. So hatte ich das damals erlebt beim Kauf des teuren Keithley 2400 Sourcemeter zusammen mit dem Keithley-GPIB-USB-Adapter in Verbindung mit Labview. Es lief erst mal nichts. Und der eine schob die Schuld auf den anderen, so lange bis ich dann entnervt den NI-Adapter passend zu Labview kaufte . . . Am besten kauft man also für jede Programmiersprache wieder einen passenden Adapter. Sind ja nur ein paar 100 EUR. Ok. Habe verstanden. Standards eben. Schichtkuchen. Guten Appetit !
Matthias W. schrieb: > DirkB schrieb >> Der schnellere Nachbau von TAMS hat Schwierigkeiten bei der Buffergröße >> gemacht. > > das ist schade. Ließ sich das Problem denn lösen? Da ich weiß wieviel Daten ich erwarte, konnte ich den Buffer dynamisch anpassen. Hat aber Zeit gebraucht das herauszufinden. (Es ging nicht um den Preis, der TAMS hatte schon USB2) > DirkB schrieb >> Was mittlerweile wieder geht ist die Serielle Schnittstelle dank der >> USB-Seriell-Umsetzer. Die gibt es auch 4-Fach. > > das ist gut. Du meinst diese billigen Adapter? Ja. Man muß nur aufpassen das man die Dinger immer wieder in die selbe USB-Buchse steckt, sonst haben die COM-Ports andere Nummern :-( > DirkB schrieb >> Messgeräte mit USB mag ich nicht. Da nehme ich lieber gleich LAN. > > Kann ich verstehen. > ... > GPIB-Adapter für LAN gibt es ja auch. Pass aber auf. Die haben ihr eigenes Protokoll und benötigen dann auch Treiber die wieder über SICL/VISA bzw. Labview oder VEE angesprochen werden.
> Unter Fortschritt verstehe ich: > + Funktioniert so problemlos wie damals, nur schneller > + kostet weniger weil Hardware heute billiger "Industriestandard" meinte mal ein Kollege sei oft ein Euphemismus für veraltet und überteuert... zum Glück haben neue Messgeräte immer öfter RS232 oder gleich LAN.
DirkB schrieb: > Da ich weiß wieviel Daten ich erwarte, konnte ich den Buffer dynamisch > anpassen. Hat aber Zeit gebraucht das herauszufinden. > (Es ging nicht um den Preis, der TAMS hatte schon USB2) also teuer und noch Probleme . . . >>> Serielle Schnittstelle dank der >>> USB-Seriell-Umsetzer. Die gibt es auch 4-Fach. Kannst Du einen Link zu so einem 4-fach-Teil posten? >> Du meinst diese billigen Adapter? > Ja. Man muß nur aufpassen das man die Dinger immer wieder in die selbe > USB-Buchse steckt, sonst haben die COM-Ports andere Nummern :-( das ist echt blöd. Ich kenne ein paar Leute denen das passiert ist. Dann riefen sie an und fragten um Rat. Und ich wusste erst mal nicht warum es plötzlich klemmte . . . Plug and Pray. >> GPIB-Adapter für LAN gibt es ja auch. > Pass aber auf. Die haben ihr eigenes Protokoll und benötigen dann auch > Treiber die wieder über SICL/VISA bzw. Labview oder VEE angesprochen > werden. Danke für den Hinweis. Also wieder eine Hürde. PureBasic kann also vermutlich weder GPIB noch LAN brauchbar ansteuern. Es sei denn man hat Riesenglück und es funzt über eine DLL.
asd schrieb: > "Industriestandard" meinte mal ein Kollege sei oft ein Euphemismus für > veraltet und überteuert... ich kann nur sagen, daß ich damals mit dem GPIB sehr zufrieden war. Kein Stress, kein Datenverlust, schnell. Was will man mehr. Die letzten beiden Geräte die ich von Keithley hatte waren ein teures 2400 Sourcemeter und ein 2700-Messdatenerfassungssystem. Beide hatten GPIB und liefen mit einem USB- GPIB-Adapter von NI problemlos unter Labview zusammen. > zum Glück haben neue Messgeräte immer öfter > RS232 oder gleich LAN. RS232 mag nett sein, wenn man ein Gerät hat. Wenn es 5 sind ist es weniger lustig. Zudem sind die Baudraten oft ziemlich niedrig. Als vollwertige Schnittstelle würde ich das nicht sehen. Wenn ein Voltmeter beworben wird mit Sätzen wie "schafft 20000 Messungen pro Sekunde" und man dann über RS232 mit 9600bd dran geht . . . Das dürfte dann langsamer gehen als 1984 mit der uralten 68000-Kiste und GPIB. Welch Fortschritt ! LAN mag da mehr Sinn machen. Auch da gibt es jedoch manchmal langsame Schnittstellen. Messgeräte mit LAN hatte ich noch keine.
Matthias W. schrieb: >>>> Serielle Schnittstelle dank der >>>> USB-Seriell-Umsetzer. Die gibt es auch 4-Fach. > > Kannst Du einen Link zu so einem 4-fach-Teil > posten? Z.B. DELOCK 87414 http://www.reichelt.de/USB-Hubs/DELOCK-87414/index.html?ACTION=3&GROUPID=4831&ARTICLE=91453&SHOW=1&START=0&OFFSET=500&;PROVID=2402
DirkB schrieb: > Matthias W. schrieb: >>>>> Serielle Schnittstelle dank der >>>>> USB-Seriell-Umsetzer. Die gibt es auch 4-Fach. >> >> Kannst Du einen Link zu so einem 4-fach-Teil >> posten? > > Z.B. DELOCK 87414 > http://www.reichelt.de/USB-Hubs/DELOCK-87414/index.html?ACTION=3&GROUPID=4831&ARTICLE=91453&SHOW=1&START=0&OFFSET=500&;PROVID=2402 Wenn Du die Wahl hast, nimm besser einen PCMCIA-RS232-Adapter. Damit hast Du weniger Probleme. In diesen Dingern sind echte 16550-kompatible UARTs eingebaut, wie sie sonst auch auf Mainboards zu finden waren/sind, d.h. sie werden sich auch im Timing exakt so verhalten. Für USB-Seriell-Ports gilt das nicht, und es geht dort auch gar nicht anders. USB ist nicht zeichenorientiert wie RS232, sondern blockorientiert. Heißt also: ein Byte geht erst dann auf die Reise, wenn der Puffer voll ist oder das USB-Device beim Polling (genau - USB arbeitet immer mit Polling) im ms Raster eben wieder dran ist. Streaming Protokolle gehen problemlos, Ping-Pong-Protokolle im Stile von X-Modem 128 können sehr langsam werden, und manches geht halt gar nicht mehr. USB nimmst Du dann, wenn es natives USB ist ohne irgendwelche Konverter dazwischen. Dann läuft das sicher. fchk PS: DELOCK 61617 ist eine PCMCIA-4*seriell Karte mit 4 richtigen 16C950 UARTs mit 128 Byte FIFOs (wahlweise auch auf 16 Byte im 16550N UARTs herunterstufbar).
DirkB schrieb: > Z.B. DELOCK 87414 > http://www.reichelt.de/USB-Hubs/DELOCK-87414/index.html?ACTION=3&GROUPID=4831&ARTICLE=91453&SHOW=1&START=0&OFFSET=500&;PROVID=2402 Danke Dirk. Das ist ein wertvoller Hinweis.
Frank K. schrieb: > Wenn Du die Wahl hast, nimm besser einen PCMCIA-RS232-Adapter. Bisher hatte ich mit den Digitus- USB to Serial Convertern keinen Stress. Da steht etwas von maximaler Transferrate von über 1Mbps. 115kbd waren keinerlei Problem. Mit so einem Terminalprogramm konnte ich einzelne bytes schicken und auch die Leitungen toggeln. Was will man mehr? > Damit hast Du weniger Probleme. noch weniger Probleme? > In diesen Dingern sind echte 16550-kompatible > UARTs eingebaut, wie sie sonst auch auf Mainboards zu finden waren/sind, > d.h. sie werden sich auch im Timing exakt so verhalten. das hört sich gut an. Ist PCMCIA nicht eine aussterbende Gattung bei Laptops? > Für USB-Seriell-Ports gilt das nicht, und es geht dort auch gar nicht > anders. USB ist nicht zeichenorientiert wie RS232, sondern > blockorientiert. Heißt also: ein Byte geht erst dann auf die Reise, wenn > der Puffer voll ist oder das USB-Device beim Polling (genau - USB > arbeitet immer mit Polling) im ms Raster eben wieder dran ist. Streaming > Protokolle gehen problemlos, Ping-Pong-Protokolle im Stile von X-Modem > 128 können sehr langsam werden, und manches geht halt gar nicht mehr. Bisher zumindest war mir das nicht negativ aufgefallen. Ich schickte über VB5 Daten seriell an einen AVR und der bestätigte den Empfang. Eine ganze Menge Daten wurden geschickt und sie kamen auch korrekt an. Das schien mir ziemlich flott zu laufen. VB5 verwendete wohl einen Puffer. > PS: DELOCK 61617 ist eine PCMCIA-4*seriell Karte mit 4 richtigen 16C950 > UARTs mit 128 Byte FIFOs (wahlweise auch auf 16 Byte im 16550N UARTs > herunterstufbar). Danke für den Hinweis. Leider geht er nur bis 115kbps. http://www.delock.de/produkte/suche/PCMCIA_Adapter_CardBus_zu_4_x_Seriell_61617.html Seltsam, daß diese Digitus-Dinger da bis über 1Mbps gehen sollen.
hier sieht es so aus, als ob sich jemand so einen USB-GPIB selbst gebaut hat. http://guenther-fromhagen.homepage.t-online.de/USB_Messplatz_HAM_RADIO_2009.pdf So sehr aufwendig sieht das nicht aus.
Matthias W. schrieb: > hier sieht es so aus, als ob sich > jemand so einen USB-GPIB selbst gebaut hat. > http://guenther-fromhagen.homepage.t-online.de/USB_Messplatz_HAM_RADIO_2009.pdf leider steht keine mail-Adresse im Impressum.
Matthias W. schrieb: > Frank K. schrieb: >> Wenn Du die Wahl hast, nimm besser einen PCMCIA-RS232-Adapter. > > Bisher hatte ich mit den Digitus- > USB to Serial Convertern keinen Stress. > Da steht etwas von maximaler Transferrate > von über 1Mbps. 115kbd waren keinerlei Problem. > Mit so einem Terminalprogramm konnte ich einzelne > bytes schicken und auch die Leitungen toggeln. > Was will man mehr? ein korrektes Timing. >> In diesen Dingern sind echte 16550-kompatible >> UARTs eingebaut, wie sie sonst auch auf Mainboards zu finden waren/sind, >> d.h. sie werden sich auch im Timing exakt so verhalten. > > das hört sich gut an. > Ist PCMCIA nicht eine aussterbende Gattung bei Laptops? Es kommt auf die Laptops an. Du darfst natürlich nicht den erstbesten Consumer-Schrott nehmen, nur weil Aldi den gerade im Angebot hat. Bei Business-Notebooks findest Du PCMCIA/Cardbus und auch echte serielle Schnittstellen noch öfter, und auch matte Displays. Der Nachfolger ist ExpressCard. Bei ExpressCard ist eine PCIe-Lane und ein USB-Port auf dem Steckverbinder. Billige IO-Karten hängen auf dem USB. Die willst Du nicht. Es gibt auch welche, bei denen echte UARTs am Werk sind, die an der PCIe-Lane hängen. Das sind die, die man kaufen sollte, > Bisher zumindest war mir das nicht negativ > aufgefallen. Glück gehabt. Vieles geht auch zweifelsohne. Trotzdem ist Seriell über USB immer nur die zweitbeste Wahl. >> PS: DELOCK 61617 ist eine PCMCIA-4*seriell Karte mit 4 richtigen 16C950 >> UARTs mit 128 Byte FIFOs (wahlweise auch auf 16 Byte im 16550N UARTs >> herunterstufbar). > > Danke für den Hinweis. Leider geht er nur bis 115kbps. Das ist bei den echten seriellen Ports auf den Mainboards nicht anders. Es gibt aber auch schnellere Karten, wenn es unbedingt sein muss. > Seltsam, daß diese Digitus-Dinger da bis über 1Mbps gehen sollen. Klar, USB ist nominal schneller, und die USB-Bridges sind nicht mehr an die Registerbelegung der NS16450/550 UARTs aus den 80'er Jahren des letzten Jahrhunderts gebunden. Das kann Vorteile, aber auch Nachteile haben. 100% Kompatibilität gibts so natürlich nicht. PS: Notebooks finde ich für Entwicklungsarbeiten nicht wirklich optimal. Schlechtere Bildschirme, keine abgesetzte Tastatur und weniger Erweiterungsmöglichkeiten sprechen eindeutig dagegen, wenn man nicht unbedingt mobilen Service machen muss. Nach BGV sind Notebooks als alleinige Arbeitsplatzrechner deswegen auch unzulässig. fchk
Hier scheint es ein Interface zu geben von RS232 nach GPIB. http://www.call-n-deal.de/uwe/projekte/schublade/hameg-interface/hameg.gif Ich vermute stark daß die Interfacekarte in diesem Keithley zumindest ähnlich aufgebaut ist. Jedenfalls gibt es nur wenig Pins von der Hauptplatine zur GPIB-Platine. Da drauf sind dann Optokoppler und von da geht es weiter zu einem TI-Chip der GPIB macht. Dieser geht auf 2 Treiber zur GPIB-Buchse. Also wird die Basis vielleicht RS232 sein. Diese RS232 müsste ich innen abgreifen können. Nur habe ich natürlich keine Beschreibung der Befehle darauf. Die Baudrate kenne ich auch nicht. Ein Datenblatt dieses TI-Chips wird wohl schlauer machen.
Frank K. schrieb: >> Mit so einem Terminalprogramm konnte ich einzelne >> bytes schicken und auch die Leitungen toggeln. >> Was will man mehr? > ein korrektes Timing. Du meinst das Timing ist so verkehrt? > Bei Business-Notebooks findest Du PCMCIA/Cardbus und auch echte serielle > Schnittstellen noch öfter, und auch matte Displays. ja. Ich habe solche. Fragt sich trotzdem wie lange die noch so gebaut werden. > Der Nachfolger ist ExpressCard. Bei ExpressCard ist eine PCIe-Lane und > ein USB-Port auf dem Steckverbinder. Billige IO-Karten hängen auf dem > USB. Die willst Du nicht. Es gibt auch welche, bei denen echte UARTs am > Werk sind, die an der PCIe-Lane hängen. Das sind die, die man kaufen > sollte, ok. >> Seltsam, daß diese Digitus-Dinger da bis über 1Mbps gehen sollen. > Klar, USB ist nominal schneller, und die USB-Bridges sind nicht mehr an > die Registerbelegung der NS16450/550 UARTs aus den 80'er Jahren des > letzten Jahrhunderts gebunden. Das kann Vorteile, aber auch Nachteile > haben. 100% Kompatibilität gibts so natürlich nicht. schön fand ich daß ich bisher mit diesen Adaptern gut zurecht kam. Parallele Adapter machen da wohl mehr Stress. > PS: Notebooks finde ich für Entwicklungsarbeiten nicht wirklich optimal. > Schlechtere Bildschirme, keine abgesetzte Tastatur und weniger > Erweiterungsmöglichkeiten sprechen eindeutig dagegen, wenn man nicht > unbedingt mobilen Service machen muss. Nach BGV sind Notebooks als > alleinige Arbeitsplatzrechner deswegen auch unzulässig. bei BMW hatten wir solche. Externe Bildschirme waren jedoch da und externe Tastaturen auch. Und Docking-Stations. Fragt sich dann was da noch vom Laptop bleibt. Die langsamere CPU, weil man ja die Wärme nicht ableiten kann - der Kühler schafft ja nur ein Bruchteil von dem eines Desktops. Und die kleinere Festplatte. Trotzdem entwickele ich mit dem Laptop viel lieber. Den Desktop nehme ich nicht mit in den Bastelkeller. Jeder soll das so handhaben wie er möchte.
Hier hat einer was geschrieben zu Adaptern: http://www.edaboard.de/rs232-gpib-konverter-t4657.html "ein RS-232 interface von µC bedient.. Daran einen einfachen GPIP-Controller (entweder 7210 oder 9914A). Bei mir ist das der TI-Baustein." "Die große Kunst ist es, dann Treiber dafür zu schreiben, da nahezu jegliche Informationen zu IEEE 488-2 aka GPIB durch 3-4-stellige $-Summen vor Neugierigen geschützt sind. Ich empfehle die Treiber aus dem Linux-Lab Projekt zu kopieren. Das hat bei mir damals auch relativ schnell funktioniert, obwohl ich von x86 Unix auf eine komplett andere Systemarchitektur (inmos-Transputer, kein Unix) portieren mußte. Läuft seit knapp 5 Jahren problemlos in 5 Instanzen." Also gibt es da ein Linux-Lab Projekt. Offenbar will man das Wissen geheimhalten . . .
Elektor scheint auch was zu schreiben: http://www.elektor.de/elektronik-news/elektor-april-heft-am-kiosk-online-extra.1748185.lynkx "Weitere Themen sind ein GPIB/USB-Konverter" Kann jemand was dazu sagen?
Matthias W. schrieb: > Elektor scheint auch was zu schreiben: > http://www.elektor.de/elektronik-news/elektor-april-heft-am-kiosk-online-extra.1748185.lynkx > "Weitere Themen sind ein GPIB/USB-Konverter" > > Kann jemand was dazu sagen? Prolific USB: kotz Beitrag "[S] GPIB-USB Adapter" fchk
Frank K. schrieb: > Prolific USB: *kotz* ist das denn wirklich sooo schlecht? oder einfach nur langsam? > Beitrag "[S] GPIB-USB Adapter" offenbar scheint der China-Clone brauchbar. Ist halt die Frage was er kostet bis er da ist und was dann ist wenn was klemmt. Ich habe ein China LCR-Meter. Beim ersten ging die Batterie-Unterspannungsanzeige nicht und das Gehäuse löste sich auf wegen der Weichmacher in der Hülle. Das zweite läuft zwar, zeigt jedoch 100uF im 2000uF-Bereich Faktor 1.5 höher an als im 200uF-Bereich. Da scheinen mir so manche Bastelprojekte solider . . .
Wäre das vielleicht ausbaufähig? http://www.mcselec.com/index.php?option=com_content&task=view&id=67&Itemid=57
>Ich habe 2 Messgeräte mit GPIB.
Ist die Frage ob man besser auf was anderes umsteigt.
USB? Wie zukunftssicher ist das? Nun kommt ja USB3.
USB ist leider die falsche Wahl. Dass die Kabel nur 5m lang sein duerfen
ist die Eine Sache. Die Andere Sache ist die Automation. Ist ja schoen,
dass gerade die zum Instrument passende Applikation aufgeht. Jetzt. Nur
ist der lebenszyklus von Messgeraeten zu PC sehr verschieden. Ein
Messgeraet macht mindestens 20 Jahre. Und der PC ? Und USB ? Und die
Applikation auf Windows 15 ?
Ethernet waere die bessere loesung. Mit eine Webserver auf dem
Messgeraet. Und einem offenen Ethernet (TCP/IP) Commandset fuer
selbstgeschriebene Applikationen.
Banane schrieb: > Wäre das vielleicht ausbaufähig? > http://www.mcselec.com/index.php?option=com_content&task=view&id=67&Itemid=57 ist wohl mit BASCOM gemacht. Ausbaufähig ist das wohl. Statt dem winzigen AVR könnte man ja einen ATmega8 oder 88 nehmen. Fragt sich wie hoch man die serielle Datenrate aufdrehen kann bis die Software innen das nicht mehr packt. Sicher hat jemand da Erfahrung dazu und kann etwas sagen.
Hex Oschi schrieb: > USB ist leider die falsche Wahl. Dass die Kabel nur 5m lang sein duerfen > ist die Eine Sache. Die Andere Sache ist die Automation. Ist ja schoen, > dass gerade die zum Instrument passende Applikation aufgeht. Jetzt. Nur > ist der lebenszyklus von Messgeraeten zu PC sehr verschieden. Ein > Messgeraet macht mindestens 20 Jahre. Und der PC ? Und USB ? Und die > Applikation auf Windows 15 ? Ist ja klar, daß USB kein so geniales Bussystem ist. Wenn man Klimmzüge machen muss um mal ein byte zu senden und dies nicht performant klappt . . . Treiber mit Schichten - und Adapter die zu nichts anderem passen als einer einzigen Sprache? Für andere Sprachen sind dann andere Adapter empfohlen? Seriell hat auch sein Speed-Limit, so einfach es auch ist. > Ethernet waere die bessere loesung. Mit eine Webserver auf dem > Messgeraet. Und einem offenen Ethernet (TCP/IP) Commandset fuer > selbstgeschriebene Applikationen. Es gibt ja so kleine Teile mit Ethernet-Buchse die man an einen AVR hängen kann. Wenn die Software kein Monster ist sollte die ja reinpassen in einen AVR. Wenn man den Code für die Seite vom AVR zur GPIB-Buchse hat . . . Offenbar gibt es ja Source Code dafür. + in Bascom + in C? + in Linux (Linux-Lab Projekt?)
Matthias W. schrieb: > Banane schrieb: >> Wäre das vielleicht ausbaufähig? >> http://www.mcselec.com/index.php?option=com_content&task=view&id=67&Itemid=57 > > ist wohl mit BASCOM gemacht. > Ausbaufähig ist das wohl. > > Statt dem winzigen AVR könnte man ja > einen ATmega8 oder 88 nehmen. Ich würde dafür eher einen TI LM3S6911 oder einen PIC32MX695 (der TCP/IP Stack von Microchip ist besser als das uIP oder lwIP Zeugs) nehmen und Ethernet als Schnittstelle wählen. Erst in dieser Leistungsklasse haben die Controller genügen Wupp, um nicht zum Nadelöhr zu werden. Der PIC32MX695 hätte auch USB, um einen nativen USB-Clienten zu bauen, beim TI/Luminary Micro müsste es dann einer auch der LM3S8xxx Serie sein. USB-Stacks gibts von den Herstellern auch, wobei auch hier das Zeugs von Microchip eher das problemärmere ist. Wolltest Du jetzt basteln, oder wolltest Du einfach nur eine stressfreie Lösung, die einfach nur geht? fchk
Frank K. schrieb: > Ich würde dafür eher einen TI LM3S6911 oder einen PIC32MX695 (der TCP/IP > Stack von Microchip ist besser als das uIP oder lwIP Zeugs) nehmen und > Ethernet als Schnittstelle wählen. Erst in dieser Leistungsklasse haben > die Controller genügen Wupp, um nicht zum Nadelöhr zu werden. das mag so sein, kann ich schwer beurteilen. > Der PIC32MX695 hätte auch USB, um einen nativen USB-Clienten zu bauen, > beim TI/Luminary Micro müsste es dann einer auch der LM3S8xxx Serie > sein. USB-Stacks gibts von den Herstellern auch, wobei auch hier das > Zeugs von Microchip eher das problemärmere ist. dann wäre dieser zu bevorzugen. PICs sind Neuland für mich. > Wolltest Du jetzt basteln, oder wolltest Du einfach nur eine stressfreie > Lösung, die einfach nur geht? Basteln macht Sinn, wenn man was lernen möchte. Stressfreie Lösungen kaufen macht Sinn wenn man rasch arbeiten will. Letzteres ist mir momentan lieber. Wobei sich da die Frage stellt was denn wirklich gut funzt. Was harmoniert zusammen mit dem PureBasic, das ich oben erwähnt hatte - so lautete die Frage. Auch dieser chinesische Nachbau oder die Aktivitäten diesen nun hier auch verfügbar zu machen könnten interessant sein. Nur wer weiß schon welchen Stress das dann bringen wird . . .
Frank K. schrieb: > Wolltest Du jetzt basteln, oder wolltest Du einfach nur eine stressfreie > Lösung, die einfach nur geht? wenn man was Fertiges will und Ethernet, dann sind die Wahlmöglichkeiten nicht so sehr groß? Prolific hat da was. Keine Ahnung ob das besser taugt als deren oder eine andere USB-Lösung . . . Keine Ahnung wie gut PureBasic mit so einem Adapter über Ethernet dann zurechtkäme . . .
Zum Thema Linux: http://linux-gpib.sourceforge.net/ "The Linux GPIB Package is a support package for GPIB (IEEE 488) hardware. contains kernel driver modules, and a C user-space library with Guile, Perl, PHP, Python and TCL bindings. The API of the C library is intended to be compatible with National Instrument's GPIB library. The Linux GPIB Package is available as source code. Many USB-GPIB adapters and a few other boards additionally require proprietary, closed-source firmware to be uploaded to the adapter after it is powered on. All boards currently supported by the 3.2.x release are listed here. http://linux-gpib.sourceforge.net/doc_html/x259.html"; Die Liste der unterstützten Adapter ist recht lang. Agilent,CEC,CONTEC,Hameg,Ines,Iotech,Keithley,NI.. Wenig bekannte Hersteller sind eher nicht darunter.
Matthias W. schrieb: > Frank K. schrieb: >> Wolltest Du jetzt basteln, oder wolltest Du einfach nur eine stressfreie >> Lösung, die einfach nur geht? > > wenn man was Fertiges will und Ethernet, dann sind > die Wahlmöglichkeiten nicht so sehr groß? Genau. Pest&Lepra. NI und HP/Agilent. > Prolific hat da was. Keine Ahnung ob das besser > taugt als deren oder eine andere USB-Lösung . . . Die Prolific-USB-Seriell-Adapter sind dafür bekannt, öfters mal Probleme zu machen. Das allerdings zu relativ geringen Einkaufspreisen. > Keine Ahnung wie gut PureBasic mit so einem > Adapter über Ethernet dann zurechtkäme . . . Weiß ich auch nicht. PureBasic ist ziemlich exotisch. Wenn Du etwas verwenden würdest, was in der Industrie gängiger ist, dann hättest Du weniger Stress. Z.B. LabView, Visual Basic.NET oder C(pur,++,#). So wird es bei Dir als Bastelei enden. fchk
Frank K. schrieb: > Genau. Pest&Lepra. NI und HP/Agilent. Soll das heißen Ethernet für GPIB gibts auch bei NI und Agilent? > Die Prolific-USB-Seriell-Adapter sind dafür bekannt, öfters mal Probleme > zu machen. Das allerdings zu relativ geringen Einkaufspreisen. Immerhin scheint deren Support wohl ansprechbar. Die China-Variante wäre auch andenkbar. Siehe oben. Keine Ahnung wie sinnvoll der Adapter von Rigol ist. Ethernet kenne ich da nicht. >> Keine Ahnung wie gut PureBasic mit so einem >> Adapter über Ethernet dann zurechtkäme . . . > Weiß ich auch nicht. PureBasic ist ziemlich exotisch. ja, leider. Ich hoffte ja, daß hier jemand etwas dazu sagen kann. > Wenn Du etwas > verwenden würdest, was in der Industrie gängiger ist, dann hättest Du > weniger Stress. das ist die Frage. Mit eben diesem Labview und dem Keithley-Adapter hatte ich ja großen Stress. Das sind alles große Namen ! > Z.B. LabView, Visual Basic.NET oder C(pur,++,#). So wird > es bei Dir als Bastelei enden. das ist die Frage. Bastelei kann entweder auf der Softwareseite und/oder an der Hardware nötig sein. Keithley gab mir damals Hinweise an der Software hier und da zu flicken. Diese Bastelei war real da. An dieser Bastelei war auch Labview beteiligt. VB.NET läuft nur auf PCs. Dazu muss das .NET-Framework installiert werden. Damit hatte ich auch schon Stress. C pur ist ok. Nur wie komme ich dann zu einer einfachen grafischen Ausgabe, so ähnlich VB? Das Monsterpaket von MS zu C++ überzeugte mich nicht. Wenn man jeden Tag damit werkelt mag es gehen. C# braucht wohl auch wieder .NET. Für mich als Gelegenheitsprogrammierer, der Turbo C unter DOS sehr geschätzt hat wegen seiner einfachen Bedienbarkeit und dem Debugger stellt sich die Frage womit man heute einfach ohne viel Overhead und lange Lernphase zu brauchbaren Ergebnissen kommen kann. Manche nehmen Delphi. Pascal ist nicht so mein Ding. PureBasic läuft unter allen Betriebssystemen. Es erzeugt offenbar kleinen Code. DLLs kann man ansprechen. Es besteht die Chance damit rasch zu Ergebnissen zu kommen. So übel scheint mir das nicht. Bei den AVRs hat man auch über BASCOM gelacht. Manche haben damit jedoch schöne Projekte gemacht, die sie sonst wohl nicht so rasch hinbekommen hätten. Dies gilt es anzuerkennen. Für manche mag BASCOM ein Glücksfall sein. Auch für PureBasic sehe ich Potential. Auch wenn es hier leider kaum einer kennt. Reinfallen kann immer.
Für solche kleinen speziellen einmalprogramme sind Skriptsprachen wie python, ruby, perl etc. wie geschaffen. Graphische Ausgabe und guis gehen auch problemlos. Für python gibt es auch eine handliche GPIB-Bibliothek: http://pyvisa.sourceforge.net/
Luk4s K. schrieb: > Für solche kleinen speziellen einmalprogramme sind Skriptsprachen wie > python, ruby, perl etc. wie geschaffen. Graphische Ausgabe und guis > gehen auch problemlos. Für python gibt es auch eine handliche > GPIB-Bibliothek: http://pyvisa.sourceforge.net/ Vielen Dank, das Python schaue ich mal an.
Matthias W. schrieb: > Soll das heißen Ethernet für GPIB gibts auch bei NI und Agilent? mehr als 1000.- wenn ich richtig gelesen habe?
Luk4s K. schrieb: >> Für solche kleinen speziellen einmalprogramme sind Skriptsprachen wie >> python, ruby, perl etc. wie geschaffen. Graphische Ausgabe und guis >> gehen auch problemlos. Für python gibt es auch eine handliche >> GPIB-Bibliothek: http://pyvisa.sourceforge.net/ Es gibt ja auch Ruby. Wie ist das denn im Vergleich zu Python zu sehen? Genauso brauchbar für GPIB und Grafik?
'Ne GPIB für ruby scheint's auch zu geben. GTK ebenfalls. Ich würde mal sagen python und ruby sind ziemlich gleichwertig. Schau dir beide an such dir die aus, die dir besser gefällt. Meine Empfehlung: Python+GTK mit Glade+(cairo zum malen) damit bist du theoretisch Programmunabhängig. Die Erfahrung hat allerdings gezeigt, dass pyGTK unter Windows ein ziemlicher Krampf ist, Wxwidgets soll da einfacher sein, allerdings gibt es da nichts, was Glade das Wasser reichen kann.
Luk4s K. schrieb: > Meine Empfehlung: Python+GTK mit Glade+(cairo zum malen) damit bist du > theoretisch Programmunabhängig. Die Erfahrung hat allerdings gezeigt, > dass pyGTK unter Windows ein ziemlicher Krampf ist, Wxwidgets soll da > einfacher sein, allerdings gibt es da nichts, was Glade das Wasser > reichen kann. gibts ein Beispiel wo man mal sehen kann wie eine einfache Anwendung mit einer simplen Graphikausgabe aussieht und wo man auch die Codegröße sehen kann? Bei diesem PureBasic gefiel mir: + kompakter Programm-Code + kompakte exe-Datei + keine Monsterbibliotheken + Grafik rasch zusammengeklickt Wie viele Abstriche muss man denn davon hinnehmen aus Deiner Sicht? Gibts ein Beispiel dazu was ich mal ansehen kann?
Hier habe ich einen Kurs zu Python gefunden. http://wspiegel.de/pykurs/beispiel_index.htm 14 Teile. Nur scheint da keine Grafik dabei zu sein.
Matthias W. schrieb: > + kompakter Programm-Code Kann man von python behaupten > + kompakte exe-Datei von Windows-Programmierung habe ich keine Ahnung > + keine Monsterbibliotheken trifft afaik zu > + Grafik rasch zusammengeklickt GUIs klickst du dir bei GTK mit Glade zusammen, QT hat was vergleichbares Zum malen (Funktionsgraphen etc). hat sich cairo als quasi-Standard im Gtk-dunstkreis etabliert, wenn sich's auf einfache Diagramme beschränkt ist kannst du auf matplotlib bzw. gnuplot zurückgreifen Als Beispiel kannst du dir mal den Nadeldruckersimulator ansehen: Beitrag "EPSON FX-80 Simulator" verwendet serielle Schnittstelle, Datei schreiben
.exe-Dateien unter Windows zu erzeugen is nich so optimal damit. Ist halt ne Scriptsprache, d.h. Script + Interpreter und keine Standalone-Datei ist der Standard. Gibt ein Progrämmchen, dass exes erzeugt, allerdings stopft das einfach den Interpreter + komplette Standardbibliothek mit dem Quelltext in eine Datei, die sind also unnötig groß.
Luk4s K. schrieb: > Zum malen (Funktionsgraphen etc). hat sich cairo als quasi-Standard im > Gtk-dunstkreis etabliert, wenn sich's auf einfache Diagramme beschränkt > ist kannst du auf matplotlib bzw. gnuplot zurückgreifen Danke für den Hinweis. > Als Beispiel kannst du dir mal den Nadeldruckersimulator ansehen: > Beitrag "EPSON FX-80 Simulator" verwendet serielle > Schnittstelle, Datei schreiben Habe ich angesehen. So einfach ist es nicht für mich zu verstehen. Ich habe Python mal installiert und schaue ein paar Tutorials auf youtube an. Graphik kam bisher nicht darin vor.
heh schrieb: > .exe-Dateien unter Windows zu erzeugen is nich so optimal damit. Das ist natürlich schade. > Ist halt ne Scriptsprache, d.h. Script + Interpreter und keine > Standalone-Datei ist der Standard. ok. > Gibt ein Progrämmchen, dass exes > erzeugt, allerdings stopft das einfach den Interpreter + komplette > Standardbibliothek mit dem Quelltext in eine Datei, die sind also > unnötig groß. das habe ich befürchtet. Vermutlich kommt was ziemlich großes am Ende raus, denn der Treiber für VISA ist ja wohl auch ein Monster. All dies muss ja drum herum noch installiert werden wenn man was weitergeben möchte. PureBasic kann da punkten, wenn man mit dem auskommt was serienmäßig drin ist. Die Graphik ist jedenfalls voll drin. Ein Fenster aufmachen mit bestimmter Größe ist ein Befehl. Achsenbeschriftung wird es wohl auch geben, so hoffe ich. Keine Ahnung ob Glade für Python so was leistet. Sind in Python Beispiele in einer Hilfe eingebaut?
Matthias W. schrieb: > Vielleicht ist das stressfreier als einen GPIB- > Adapter zum Laufen zu bringen für ein altes > Keithley-Multimeter Nö, gewiss nicht. Ich meinte ja auch, Scriptsprache + 08/15-GPIB- Adapter. Wenn man noch einen alten Computer mit ISA-Slots hat, den man für die Messgeräte hinstellt, dann bekommt man die ziemlich preiswert. Das low-level GPIB API besteht übrigens aus weniger als 10 Funktionen, die letztlich wirklich benutzt werden, und deren Namen und Parameter haben sich faktisch seit MS-DOS-Zeiten nicht verändert. Was die Geräte dann über das GPIB sprechen, ist wieder 'ne andere Sache, aber wenn man Geräte mit SCPI-Kommandosatz hat, ist das im Wesentlichen auch alles das Gleiche, und für die Details nimmt man sich das Programmierhandbuch. Gerade für Dinge wie ein Multimeter kann man sie fast alle über einen Kamm scheren.
Angehängte Dateien:
-
gpib.png
280 KB
Jörg Wunsch schrieb: > Wenn man noch einen alten Computer mit ISA-Slots hat, > den man für die Messgeräte hinstellt, dann bekommt man die ziemlich > preiswert. ISA-PC habe ich keinen. Es ist aufwendig eine ISA-Karte mit einem AVR zu verheiraten um so die Funktion zu gewährleisten. Einfacher scheint ein GPIB-Chip von NI zu kaufen und Treiber dran, so wie Thomas das in dem anderen Beitrag zum Thema GPIB macht und die Register über einen AVR zu programmieren. > Das low-level GPIB API besteht übrigens aus weniger als 10 Funktionen, > die letztlich wirklich benutzt werden, und deren Namen und Parameter > haben sich faktisch seit MS-DOS-Zeiten nicht verändert. Das ist kein Hexenwerk sowas zu implementieren. Beispiele gibt es: http://guenther-fromhagen.homepage.t-online.de/USB_Messplatz_HAM_RADIO_2009.pdf siehe Bild ! http://www.oe5.oevsv.at/export/sites/oe5/technik/messen_dl/HPIB_GPIB_IEEE488_Schnittstelle_V02.pdf > für die Details nimmt man sich das Programmierhandbuch. ja. Wenn man es so macht ist man den Treiberstress der Hersteller mit den vielen Schichten wohl los.
Matthias W. schrieb: > Jörg Wunsch schrieb: >> Wenn man noch einen alten Computer mit ISA-Slots hat, >> den man für die Messgeräte hinstellt, dann bekommt man die ziemlich >> preiswert. > > ISA-PC habe ich keinen. Es ist aufwendig eine ISA-Karte mit einem AVR zu > verheiraten um so die Funktion zu gewährleisten. Nu ja, wenn man einen AVR mit externem Speicherbus nimmt, ist es gar nicht so schlimm. Der ISA-Bus ist ja weiter nichts als ein Standard-Speicherbus. Aufwändig ist es vor allem mechanisch, und so schön klein wie bei dir wird's natürlich nicht.
Jörg Wunsch schrieb: > Nu ja, wenn man einen AVR mit externem Speicherbus nimmt, ist es > gar nicht so schlimm. der 8515 ginge wohl. > Aufwändig ist es vor allem mechanisch, und > so schön klein wie bei dir wird's natürlich nicht. ja. Das ist schon etwas Aufwand. Schön ist es auch nicht gerade. Klein hinten auf den Stecker stecken kann man es auch nicht. Wenn da noch das wuchtige Kabel dran hängt . . . Es müsste ein Gehäuse drum herum . . .
Ist man mit so einer Bastellösung dann wirklich besser dran als wenn man den 8535 direkt an die Pins der GPIB-Buchse dranhängt? Siehe Bild oben. Mechanisch ist so was doch viel attraktiver und praktikabler. Natürlich kann man so keine zig Meter mehr treiben. Für 2-3 Geräte wirds vielleicht doch reichen.
Matthias W. schrieb: >> Nu ja, wenn man einen AVR mit externem Speicherbus nimmt, ist es >> gar nicht so schlimm. > > der 8515 ginge wohl. ATmega128, ATmega1281, ATmega2561, die haben das alle mit dran. > ja. Das ist schon etwas Aufwand. Schön ist es auch nicht gerade. Klein > hinten auf den Stecker stecken kann man es auch nicht. Wenn da noch das > wuchtige Kabel dran hängt . . . Es müsste ein Gehäuse drum herum . . . Ja. Letztlich wäre das dann eine ISA-Karte, neben der sich irgendwo ziemlich unscheinbar ein kleiner Controller befindet. ;-) Matthias W. schrieb: > Ist man mit so einer Bastellösung dann wirklich besser dran als wenn man > den 8535 direkt an die Pins der GPIB-Buchse dranhängt? Einen reinen Master bekommst du wohl auch mit einem Controller hin in der Annahme, dass du nie für jemanden anders den Bus schnell genug freigeben musst. Denn das dafür notwendige Timing schafft man meiner Erinnerung nach nicht in Software. Aber unterschätz' mal nicht die Kapazitäten in diesen fetten Kabeln, da hat ein AVR schon ganz schön was vor mit seiner CMOS-Technologie, das zu treiben. Was wohl gehen würde ist, auf das Kabel zu verzichten und den Adapter direkt an das Messinstrument anzuflanschen.
Jörg Wunsch schrieb: > Aber unterschätz' mal nicht die Kapazitäten in diesen fetten Kabeln, > da hat ein AVR schon ganz schön was vor mit seiner CMOS-Technologie, > das zu treiben. Was wohl gehen würde ist, auf das Kabel zu > verzichten und den Adapter direkt an das Messinstrument anzuflanschen. wenn 2 Geräte nahe zusammen stehen und das Kabel somit kurz ist mag es ja gehen. Normalerweise sind wohl 15 Meter oder so möglich. Dann sollte 1 Meter schon gehen mit der kleineren Treiberfähigkeit. So hoffe ich mal. Wenn das Ding extrem klein und billig ist kann man auf die dicken Kabel schlicht verzichten und kauft für den Preis des dicken Kabels die Teile für den Adapter. Ist halt wieder eine serielle Schnittstelle mehr am PC. Wo liegt das Problem. Wenn ich sehe, daß teure Agilent-Teile eine serielle Schnittstelle mit 9600bd anbieten, so kann diese Adapterlösung dann mindestens 115kbd. Das ist also klar besser als die Kommerzsachen.
Matthias W. schrieb: > Wenn ich sehe, daß teure Agilent-Teile eine > serielle Schnittstelle mit 9600bd anbieten, so kann diese Adapterlösung > dann mindestens 115kbd. Das ist also klar besser als die Kommerzsachen. Da vermasselst du was. Der GPIB hat keine "Baudrate", und ich kenne Leute, die keine GPIB-USB-Adapter (auch nicht von NI) benutzen wollen sondern nur GPIB-PCI-Karten, weil jene durch den USB nicht echtzeit- fähig sind. (Der USB überträgt Datenpakete nur im Millisekundenraster.) Aber es ist richtig, eine derartige Lösung wird für den Hobbybereich allemal ausreichend sein.
Jörg Wunsch schrieb: > Da vermasselst du was. Der GPIB hat keine "Baudrate", Die Baudrate hat der AVR, der die GPIB-Buchse dann direkt ansteuert. > und ich kenne > Leute, die keine GPIB-USB-Adapter (auch nicht von NI) benutzen wollen > sondern nur GPIB-PCI-Karten, weil jene durch den USB nicht echtzeit- > fähig sind. das kann ich verstehen. Die Alternativen haben jedoch wieder andere Haken. Eine Multiportschnittstelle ginge auch. Bei 4 oder 8 solchen Schnittstellen ist dann jedoch Schluß am Laptop. > (Der USB überträgt Datenpakete nur im Millisekundenraster.) Das mag reichen, wenn ein Relaismultiplexer mit im Spiel ist. NI bietet einen teuren Adapter an, der mehr als 1 Mio bytes pro Sekunde übertragen können soll. Vermutlich ein Burst mode? Wie rasch überträgt der dann ein einziges Kommando? Das wird es sein, wo manche dann nicht so recht zufrieden sind. > Aber es ist richtig, eine derartige Lösung wird für den Hobbybereich > allemal ausreichend sein. letztlich muss man sehen, welchen Kompromiss man sucht: Ethernet, seriell, parallel, PIO-Schnittstelle oder eben doch USB. Es ist die Frage ob bei 115kbd seriell das USB-Interface dazu der Flaschenhals ist. Welche Latenzzeiten handelt man sich da ein. Mit 1ms kann man vielleicht leben.
Matthias W. schrieb: > Es ist die > Frage ob bei 115kbd seriell das USB-Interface dazu der Flaschenhals ist. Da die üblichen USB-Seriell-Bridges auch ganz andere Baudraten beherrschen, ist das nicht das Limit.
Matthias W. schrieb: > Jörg Wunsch schrieb: >> Da vermasselst du was. Der GPIB hat keine "Baudrate", > > Die Baudrate hat der AVR, der die GPIB-Buchse dann direkt ansteuert. Kannst ja einen AT90USBxx bzw. die neueren ATmega*U2 nehmen. Aber große Bruttodatenraten sind in der Regel nicht das Problem, das es bei GPIB zu lösen gilt. Die größten Datenmengen entstehen mal bei einem Screenshot eines Messgeräts oder sowas.
Rufus Τ. Firefly schrieb: > Da die üblichen USB-Seriell-Bridges auch ganz andere Baudraten > beherrschen, ist das nicht das Limit. mein Einfachadapter kann angeblich das 10-fache. Ist die Frage, wo der AVR dann aussteigt. Schließlich muss er ja den GPIB-Bus noch abfragen und was schicken. Ein Test wird nötig sein das herauszufinden. Wer hat denn dazu schon mal einen Code geschrieben, den man testen könnte?
Jörg Wunsch schrieb: > Kannst ja einen AT90USBxx bzw. die neueren ATmega*U2 nehmen. Danke für den Hinweis auf die U2-Typen. Teensy Dev Board AVRKey Open Kubus ATmega32U2 USB-KEY: http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=170571016795 Es gibt also Platinen mit USB-Buchse die man direkt an so eine GPIB-Buchse hängen können müsste. Ein Hexenwerk ist das nicht. Teensy Dev Board AVRKey Open Kubus AT90USB Teensy USB: http://cgi.ebay.de/Teensy-Dev-Board-AVRKey-Open-Kubus-AT90USB-Teensy-USB-/170568520372 Dieser ist mit dem AT90USBxx und deutlich billiger. Von der Beschaltung des chips her sehe ich keinen Unterschied. Soll man dann zu dem billigeren Teil greifen?
Matthias W. schrieb: > Soll man > dann zu dem billigeren Teil greifen? Greif zu dem, was du bekommen kannst. ;-) Soweit ich weiß, sind die Teensies ziemliche Mangelware geworden, seit jemand veröffentlicht hat, wie man damit eine Sony Playstation "knacken" kann. Außer der Speichergröße gibt es nicht allzu viele Unterschiede zwischen einem AT90USB162 und einem ATmega32U2 (letzterer enthält lediglich nicht mehr die PS2-Keyboard-Hardwareunterstützung, die der AT90USB162 noch hatte).
Matthias W. schrieb: > Rufus Τ. Firefly schrieb: >> Da die üblichen USB-Seriell-Bridges auch ganz andere Baudraten >> beherrschen, ist das nicht das Limit. > > mein Einfachadapter kann angeblich das 10-fache. Ist die Frage, wo der > AVR dann aussteigt. Schließlich muss er ja den GPIB-Bus noch abfragen > und was schicken. Ein Test wird nötig sein das herauszufinden. Warum muss es immer AVR sein? Zum gleichen Preis gibts Alternativen, die mindestens eine Zehnerpotenz leistungsfähiger sind. Ich denke da an kleine Ärmchen von STM oder NXP oder einen kleinen PIC32. Oder ist das ein Layer 8 Problem? fchk
Frank K. schrieb: > Warum muss es immer AVR sein? Zum gleichen Preis gibts Alternativen, die > mindestens eine Zehnerpotenz leistungsfähiger sind. Ich denke da an > kleine Ärmchen von STM oder NXP oder einen kleinen PIC32. Du hast da sicher recht Frank. Ich kenne die Alternativen wenig gut und schrecke vor dem Einarbeitungsaufwand zurück. > Oder ist das ein Layer 8 Problem? keine Ahnung was Layer 8 ist.
Matthias W. schrieb: > keine Ahnung was Layer 8 ist. Ach immer diese Bildungslücken. ;-) http://de.wikipedia.org/wiki/OSI-Modell#Satirische_Erweiterung
Frank K. schrieb: > Warum muss es immer AVR sein? Weil man sich damit auskennt, er gut verfügbar ist, die Tools weit verbreitet sind, und er der Aufgabe mehr als gerecht wird? Für das bisschen GPIB-Adapter braucht man keinen 32-bit-Controller mit Highspeed-USB-PHY und mehreren MHz CPU-Takt.
noch ein Link zu GPIB http://www.ke5fx.com/gpib/readme.htm KE5FX GPIB Toolkit is a collection of free Windows utilities
Christoph Kessler (db1uq) schrieb: > noch ein Link zu GPIB > http://www.ke5fx.com/gpib/readme.htm > KE5FX GPIB Toolkit is a collection of free Windows utilities Danke Christoph. Das ist wohl ein ehemaliger Tek-Mann. "The GPIB Toolkit is provided with full C++ source code for public- and private-sector, educational and Amateur Radio / hobbyist use. Comments and feedback are always welcome."
> Das ist wohl ein ehemaliger Tek-Mann. Auf jedenfall ist er cool. ;-) http://www.ke5fx.com/cplayer.html Olaf
Olaf schrieb: > Auf jedenfall ist er cool. ;-) > http://www.ke5fx.com/cplayer.html ja. Wenn man sich überlegt, daß dies 11 Jahre her ist . . .
Thread beobachten
Seitenaufteilung abschalten
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.