Hi, ich bin auf der Suche nach einem günstigen GPIB-USB Interface. Falls jemand etwas hat, bitte anbieten, am Besten mit Preisvorstellung. Grüße, Christoph
Ja, das ist aber auch wirklich sehr günstig.. vielen Dank für die Hilfe! 1) Ich weiß, was die Dinger von NI, Agilent, Prologix usw. neu kosten 2) Ich weiß, was bei eBay verlangt wird 3) Ich weiß, dass es durchaus auch mal günstiger geht, z.B. Beitrag "[V] GPIB-USB Adapter von National Instruments" 4) Siehe Topic ;-)
etwas schnell abgeschickt ;-) hier ist der link: http://www.elektor.de/jahrgang/2011/april/gpib-usb-konverter.1743494.lynkx
Hi, danke für den Tipp, aber kenne ich schon ;-) Allerdings wäre mir ein fertiges Teil, "handlich" verpackt und einigermaßen zuverlässig (der Elektor traue ich da nicht immer) am liebsten. Sollte ich hier nicht fündig werden, werde ich mir wohl das Prologix-Interface oder den USBpicplot holen. Aber vielleicht hat ja jemand eines rumfliegen, dass er nicht mehr benötigt ;-) Link zu picplot, da es wohl mehr Interessenten gibt; http://www.webalice.it/hotwater/USBpicplot.htm Grüße
es gibt günstige china clones von dem "Agilent 82357B USB GPIB", den habe ich auch nachgebaut, soweit funktioniert alles. Leider ist es ein Agilent und kein NI clone, der wäre mir auch lieber.
Michael H. schrieb: > http://lsd.fe.uni-lj.si/gpib/ ? ja, der geht - manchmal und nur die neuste version. Der Elektro teil darf man als spielzeug bezeichnen. Pic-Plot2 , ja noch so eine soft lösung wie der Elektor teil. Prologix geht angeblich auch, nie ausprobiert gehabt, ich mag keine soft-dinger. Der china clone ist gut - nur eben clone, kostet auch nicht viel weniger als Prologix - http://www.bmjd.biz/index_eng.html
Thomas R. schrieb: > Prologix geht angeblich auch, nie ausprobiert gehabt, ich mag > keine soft-dinger. Ja, das wäre ansonsten auch meine Empfehlung: http://www.sparkfun.com/products/549 Wir haben den Ethernet-Adapter im Einsatz und für unsere gelegentlichen Einsätze am Spektrumsanalyzer reicht das allemal.
Thomas R. schrieb: > Pic-Plot2 , ja noch so eine soft lösung wie der Elektor teil. Wäre mir auch die unliebste Lösung ;-) Aber eben auch die günstigste (von Elektor mal abgesehen) und ich habe bisher eig. nur positives gelesen. > Prologix geht angeblich auch, nie ausprobiert gehabt, ich mag > keine soft-dinger. Habe davon bisher auch nur gutes gelesen, immerhin gibt es das Ding inzwischen schon in der x-ten Version (3., 5.?), so schlecht wird es also nicht sein. Ob die Performance nun besser sein könnte, ist mir nicht so wichtig, es geht mir erst mal nur darum, Messdaten für Dokumentationszwecke auf den PC zu bekommen, eventuell irgendwann mal mehr.. Daher sollte das Ding einigermaßen zuverlässig sein, also nicht rumzicken, etc. Aber wenn es doch mal Probleme geben sollte, entstehen mir keine Kosten im k€-Bereich ;-) Das es bei einem Testsystem in einer Produktionsstraße anders aussehen würde ist mir klar ;-) > Der china clone ist gut - nur eben clone, kostet auch nicht viel weniger > als Prologix - http://www.bmjd.biz/index_eng.html Joa, etwa gleich viel. Wobei sich mir die Frage stellt, ob das wirklich ein 1:1 Clone ist? Hat da jemand Erfahrung? Immerhin versenden sie in einer ESD-Verpackung, dass der Adapter keinen Schaden nimmt (nach Beschreibung). Ich kann mir kaum vorstellen, dass das bei dem Original nötig wäre. Also übertriebene Vorsicht oder wurde bei dem Ding zu stark gespart? Grüße, Christoph
Wenn es auch eine PCI-GPIB-Karte von NI tut, da hätte ich eine zu verkaufen: http://cgi.ebay.de/PCI-GPIB-Karte-National-Instruments-/130505800897?pt=Wissenschaftliche_Ger%C3%A4te&hash=item1e62c07cc1
ja die china clones sind, abgesehen vom reset ic, LDOs und LEDs, wirklich 1:1, sonst würden die auch gar nicht funktionieren (die firmware ist Agilent original). Man kann es selber nachbauen, wie ich es machen werde da mich langsam die GPIB kabeln stören, mehrere GPIB-USB adapter sind viel einfacher in der benutzung(sammelbestellung? mal sehen), das teuerste dabei ist die 100% passende GPIB Buchse (habe schon 5 sorten hier und keine davon ist gut, schrauben sowieso nirgendwo zu finden), Cypress FX2 und natürlich die NAT9914 ICs, http://sine.ni.com/nips/cds/view/p/lang/en/nid/11153 und zielland "Germany" wählen. Die soft-dinger funktionieren eigentlich alle "irgendwie", mal mit mehr mal mit weniger herumfummeln, nur ehrlich gesagt jede stunde die ich mich damit beschäftige kostet schon zu viel. Lediglich ProLogix hat guten support (bzw. nur gutes gehört) und dürfte mittlerweile ausgerefit sein. Nochmal zu dem china-clone, der "entwickler" gibt auch eine geld-zurück garantie falls das teil mit deinen geräten nicht funktioniert, daher ist er auch übervorsichtig, abgesehen davon muss nicht alles aus china mit zeitungspapier verpackt sein :) Sonstiges support gibts nicht, ist auch logisch weil die firmware Agilent gehört, ist auch nicht so wild da Agilent hilft auch so gerne.
Hi, sorry, dass ich mich so spät zurückmelde. Thomas R. schrieb: > Man kann es selber nachbauen, wie ich es machen werde da mich langsam > die GPIB kabeln stören, mehrere GPIB-USB adapter sind viel einfacher in > der benutzung(sammelbestellung? mal sehen), das teuerste dabei ist die > 100% passende GPIB Buchse (habe schon 5 sorten hier und keine davon ist > gut, schrauben sowieso nirgendwo zu finden), Cypress FX2 und natürlich > die NAT9914 ICs.. Klingt schon mal gut, aber gibt es hier schon einen funktionierenden Nachbau? Da ich in den nächsten ~2 Monaten eine funktionierende Lösung benötige, wird es für mich wohl leider zu spät kommen,sollte das jedoch wirklich früher machbar sein, wäre ich dabei, sofern sich vorher nichts anderes anbietet. Alternativ bin ich natürlich immer noch auf der Suche :-) Grüße
Angehängte Dateien:
-
gpib.jpg
150 KB
Christoph B. schrieb: > > Klingt schon mal gut, aber gibt es hier schon einen funktionierenden > Nachbau? Da ich in den nächsten ~2 Monaten eine funktionierende Lösung > benötige, wird es für mich wohl leider zu spät kommen,sollte das jedoch > wirklich früher machbar sein, wäre ich dabei, sofern sich vorher nichts > anderes anbietet. > > Alternativ bin ich natürlich immer noch auf der Suche :-) > > Grüße ja, ich bin mittlerweile fertig mit den proto tests, soweit alles ok. Es wird also eine Sammelbestellung geben. Ich werde die Tage bei NI eine Stange (27stk) von den NAT9914 bestellen. Was noch offen ist (abgesehen von gehäuse und schrauben) sind die Treiber ICs typen - DIP oder SOIC sind möglich, DIP ist günstiger nimmt aber etwas platz weg und verbraucht mehr strom, was kritisch sein kann beim mehreren Geräten am Bus. Ich tendiere allerdings zur SOIC. Auf dem Bild - links meine version mit DIP treibern, rechts china clone mit SOIC. Wichtig sind aber die Schrauben (immer noch keinen Lieferanten gefunden) und evt. passende gehäuse.
Hi,
super, hört sich klasse an! Ich würde auch SOIC bevorzugen, ich denke
mal, das wird auch nicht soo viel an den Kosten ausmachen? Das mit den
Schrauben ist blöd, aber vielleicht findet man jemanden, der die (gegen
ein entsprechendes Entgeld) drehen kann, falls man wirklich keine
bekommt. Oder vielleicht gibt es Abstandsbolzen mit dem Gewinde, so dass
man sich mit einer Rändelschraube, Abstandsbolzen und Beilagscheiben die
Schrauben "zusammenbauen" kann. Wenn das Ganze in ein Gehäuse kommt,
sieht man es ja eh nicht mehr. Dan müsste man nur das
zusammengeschraubte sicher befestigen (Schraubensicherung, schweißen),
so das es nicht auseinander geht, wenn man den Adapter abschraubt. Was
sind denn die derzeitigen Platinenabmessungen? Ist es eventuell geplant,
die USB-Buchse weiter nach hinten ("in die Platine") zu schieben? Das
könnte beim Gehäuseeinbau von Vorteil sein. Was wären die derzeitigen
Kosten (ohne PCB und Gehäuse)? Gibt es Unterschiede zwischen den Clones
und dem originalen NI-Adapter bei den verwendeten Bauteilen (abgesehen
von Spannungsregler, etc)?
Ich hoffe, die Fragen erschlagen dich nicht zu sehr ;-) Eventuell kannst
du ja schon mal einen Thread im Elektronikforum starten, vielleicht
findet sich dann auch noch was wegen den Schrauben ;-)
Grüße
Hallo, lebt dieser Thread noch oder seid Ihr bereits zu einem anderen Thread gewechselt? Ich bin prinzipiell auch daran interessiert eine GPIB-USB Adapter zu bauen. Bei mir ist es jedoch nicht sehr eilig. Thomas R. schrieb: > Ich werde die Tage bei NI eine Stange (27stk) von den NAT9914 bestellen. Hast Du schon bestellt? Wenn ja würdest Du welche abgeben? Wie teuere sind die Bausteine? Mit freundlichen Grüßen Guido
Hallo, noch eine kurze Frage. Was ist denn von dem folgenden Angeboten zu halten? NI NAT9914BPL replacement for TI TMS9914A PLCC/New! http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=260631167523 Hat bei diesem Händler bereits einer von Euch eingekauft? Mit freundlichen Grüßen Guido
Guido C. schrieb: > > Thomas R. schrieb: >> Ich werde die Tage bei NI eine Stange (27stk) von den NAT9914 bestellen. > > Hast Du schon bestellt? Wenn ja würdest Du welche abgeben? Wie teuere > sind die Bausteine? > zu teuer, NI hat wiohl nen knall, deren dollarkurs ist ein Traum. 779EUr + Versand + Mwst für 27stk, also um die 35-36eur/stk. Den china händler habe auch schon angeschrieben, der hat wohl ein paar mehr davon. Montag dürften meine 5stk. von den chinesen kommen, mal sehen was drin steckt. Sollten die gut sein, mache ich weiter mit sammelbestellung, an sonsten wird dann uninteressant.
Hallo, danke für die Antwort. Thomas R. schrieb: > Den china händler habe auch schon angeschrieben, der hat wohl ein paar > mehr davon. Montag dürften meine 5stk. von den chinesen kommen, > mal sehen was drin steckt. Kannst uns ja berichten. Mit freundlichen Grüßen Guido
Guido C. schrieb: > Hallo, > > danke für die Antwort. > > Thomas R. schrieb: >> Den china händler habe auch schon angeschrieben, der hat wohl ein paar >> mehr davon. Montag dürften meine 5stk. von den chinesen kommen, >> mal sehen was drin steckt. > > Kannst uns ja berichten. > > Mit freundlichen Grüßen > Guido die ICs sind gut, sehen unter dem mikroskop tatsächlich neu aus und funkionieren auch alle. Gut, dann werde ich die tage einen separaten thread aufmachen, mit schaltplänen und details zur hardware und firmware.
Hallo, danke für die Rückmeldung. Thomas R. schrieb: > die ICs sind gut, sehen unter dem mikroskop tatsächlich neu aus und > funkionieren auch alle. Gut, dann werde ich die tage einen separaten > thread aufmachen, mit schaltplänen und details zur hardware und > firmware. Kannst Du dann in diesem Thread auf Deinen separaten Thread verweisen? Mit freundlichen Grüßen Guido
Thomas R. schrieb: > ja, ich bin mittlerweile fertig mit den proto tests, soweit alles ok. > Es wird also eine Sammelbestellung geben. das ist eine gute Idee. > Auf dem Bild - links meine version mit DIP treibern, rechts china clone > mit SOIC. Wichtig sind aber die Schrauben (immer noch keinen Lieferanten > gefunden) und evt. passende gehäuse. mir gefallen beide gut. Hübsch klein.
Zuckerle schrieb im Beitrag #2182681: > Ich baue gerade an einem IEEE488->Ethernet Gateway. > Das funktioniert auch schon z.T. Kannst Du was dazu sagen?
Das Affentheater mit den Steck-Adaptern sind die Treiber fuer den PC. Irgendwann wechselt man das Betriebssystem und dann hat man keinen Treiber mehr. Wir installierten kuerzlich noch ein Win95 wegen Treibern von IO Karten. Deshalb bin ich grad an einem RS232-IEEE488 Konverter als IEEE488-Mastercontroller.
Oktal Oschi schrieb: > Das Affentheater mit den Steck-Adaptern sind die Treiber fuer den PC. ja. > Irgendwann wechselt man das Betriebssystem und dann hat man keinen > Treiber mehr. Wir installierten kuerzlich noch ein Win95 wegen Treibern > von IO Karten. das ist ekelig. > Deshalb bin ich grad an einem RS232-IEEE488 Konverter als > IEEE488-Mastercontroller. Du baust also so ein Ding? Lohnt das? Wenn ich schaue wie lange diese Uni Ljubljana da dran gearbeitet hat . . Die Prologix-Leute haben auch viel Zeit verbracht. Der China-Nachbau scheint um die 100.- zu kosten. Wäre das eine brauchbare Alternative? Mit Python soll das angeblich ansprechbar sein. Hier hat jemand für sich eine einfache Lösung realisiert: http://www.oe5.oevsv.at/export/sites/oe5/technik/messen_dl/HPIB_GPIB_IEEE488_Schnittstelle_V02.pdf Für ihn hat das so gepasst. Einige Zeit steckt wohl auch darin. Einen Software-Treiber braucht er jedenfalls gar nicht !
Ich habe mal in China angefragt ob diese Agilent-Nachbauten mit einem Keithley 197 und 199 zurechtkommen, wenn man Python benutzt oder PureBasic um das anzusprechen. Der eine Händler (viele zufriedene Kunden) sagt: "Hi, Pls use Keithley GPIB interface with Keihtley device. Agilent 82357A/B or S82357 can not support Keithely software and device directly. Or, you may try NI GPIB interface. BR" Der andere Händler (bisher 0 Verkäufe) sagt: "I'm glad you pay attention to my device, my device with your device without any problem." Keine Ahnung ob der Zoll da auch wieder was will . . . Der Neuling schreibt dazu: "Freight transport in Germany is 20 dollars. No other additional costs." Vielleicht weiß er es halt einfach nicht, wenn er noch nichts verkauft hat.
Thomas R. schrieb: > Gut, dann werde ich die tage einen separaten > thread aufmachen, mit schaltplänen und details zur hardware und > firmware. Gibts dazu was Neues?
ja, in noch dabei. Ich habe zwei fehler beim china clone gefunden: - FX2 und NAT sind viel wärmer als bei meinen nachbau Der grund ist simple, der nette chinese hat versucht den logic level vom NAT (5V versogrung) anzupassen auf FX2 level. Er hat es gemacht mit 2.2k pulldowns auf jedem port pin. Eigentlich ist das nciht notwendig, der FX2 komtm auch mit 5V input klar. Agilent hat es anders gemacht, da sind pullups auf 3.3V (so wie auch in meinen aufbau). - 75ALS162 pin SC ist nirgens angeschlossen. Mein test aufbau benutzt den 75161 wo SC intern nicht vorhanden ist. Eigentlich sollte dieses pin entweder auf high liegen (damit REN/IFC auf transmit stehen) oder noch besser vom firmware gesteuert sein damit auch multicontroller auf dem bus laufen können. Der chinese hat es mal auf GND beschaltet gehabt (ich sehe es in seinen postings im chinesischen forum), dann auf HIGH und am ende hat er als NC gelassen - keine gute idee weil das ein eingangspin ist. Man kann es auch über ein inverter mit DC signal verbinden (wie bei dem 75161 intern gemacht wird), das funktioniert genau so gut wie forced transmit mit SC auf HIGH, kolidiert aber nicht mit multicontrollern. Ich werde beide möglichkeiten auf dem layout machen, kann jeder für eigene zwecke umschalten mit 0R löt(?)jumper. Der china clone hat mehr oder weniger eigene firmware, chinesisch sparen. Der FX2 schaltet beim org. Agilent adapter den CLKOUT aus sobald die firmware geladen wird, der NAT wird getaktet mit separaten 12MHz osc. Chinese hat gesparrt und firmware "angepasst" (die ist auch fest im eeprom, nix mit original Agilent firmware) damit der CLKOUT ein 12Mhz generiert. Ich habe die Agilent firmware genommen, decompiliert und angepasst damit der clock auch so generiert wird. Denoch werde auf dem layout beide varianten lassen, für separaten 12Mhz osc. und mit FX2 CLKOUT. Das ergmöglicht drei möglichkeiten: - mit chinesischer firmware - mit meiner firmware - mit Agilent org. firmware damit dürfte die "legal" frage geklärt sein. Die bestückung mit günstigen DIP treibern friss zu viel strom, es müssen schon die ALS SOIC treiber sein. Soweit alles getestet (muss ncoh überlegen ob ich die status LED einbaue, so wichtig ist die auch nicht) jetzt muss ich nur noch routen (und ein thread starten ...) Übrigens, der chinese konnte nicht erklären warum er floating pin gelassen hat ... das wäre mir gar nicht aufgefallen hätte ich nciht angefangen einen schaltplan von seinen aufbau zu zeichnen. Da ich es jetzt weiss, kann ich auch verstehen warum sein clone probleme hatte ein Xantrex netzteil vom local auf remote umzuschalten wenn die einschaltreihenfloge nciht gestimmt hat.
Thomas R. schrieb: > ja, in noch dabei. prima. > Ich habe zwei fehler beim china clone gefunden: Du meinst die Bilder oben mit dem NI chip und den Treibern? Was ist denn da der Unterschied zu den Agilent-Nachbauten? Werden diese NI chips programmiert? Ich dachte die sind hardware-orientiert. > Ich werde beide möglichkeiten auf dem layout machen, kann jeder für > eigene zwecke umschalten mit 0R löt(?)jumper. prima. > Der china clone hat mehr oder weniger eigene firmware, chinesisch > sparen. Ist die Firmware dann im NI chip abgelegt? Ist es wirklich so problematisch Keithley-Geräte von Python oder PureBasic aus anzusprechen? > Das ergmöglicht drei möglichkeiten: > - mit chinesischer firmware > - mit meiner firmware > - mit Agilent org. firmware also gibt es 3 Nöglichkeiten. Kann man das Teil auch NI-kompatibel machen? > Die bestückung mit günstigen DIP treibern friss zu viel strom, es müssen > schon die ALS SOIC treiber sein. die sollten zu bekommen sein. In DIP sind die nicht verfügbar? > Soweit alles getestet (muss ncoh > überlegen ob ich die status LED einbaue, so wichtig ist die auch nicht) > jetzt muss ich nur noch routen (und ein thread starten ...) viel Erfolg ! > Übrigens, der chinese konnte nicht erklären warum er floating pin > gelassen hat ... komisch . . . > das wäre mir gar nicht aufgefallen hätte ich nciht > angefangen einen schaltplan von seinen aufbau zu zeichnen. > Da ich es jetzt weiss, kann ich auch verstehen warum sein clone > probleme hatte ein Xantrex netzteil vom local auf remote umzuschalten > wenn die einschaltreihenfloge nciht gestimmt hat. Sachen gibts . . . Mich wundert nur, daß ja viele Käufer scheinbar zufrieden waren mit dem Cloneteil. http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=170637988180 29 wurden angeblich verkauft und bis auf einen schienen alle zufrieden. http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=260799467757 hat noch keines verkauft. Das Gehäuse sieht da viel robuster aus. Ist die Frage ob man da auch Deine Firmware nutzen könnte. Mechanisch wird man das schwer so gut hinbekommen.
Angehängte Dateien:
-
Capture.JPG
37 KB
Matthias W. schrieb: > Thomas R. schrieb: >> ja, in noch dabei. > > prima. > >> Ich habe zwei fehler beim china clone gefunden: > > Du meinst die Bilder oben mit dem NI chip und den Treibern? > Was ist denn da der Unterschied zu den Agilent-Nachbauten? > Werden diese NI chips programmiert? Ich dachte die sind > hardware-orientiert. ja die bilder. Ein USB GPIB adapter hat zwei sachen - NI chip und firmware die den GPIB auf USB umsetzt. Der NI chip NAT9914 steuert alle signale bis auf SC, das wird wie ich beschrieben habe entweder fest gelegt (je nach dem ob der chip als master oder slave arbeiten soll) oder per firmware um evt. konflikte mit anderen potentielen mastern auf den bus zu vermeiden. Für die meisten anwender reicht wenn SC pin auf high (oder invertiert mit DC signal verbunden wird). Wie gesagt, chinese hat gesparrt (oder nicht besser gewusst) daher ist der pin bei seinem nachbau (und das sind die beiden ebay angebotte die du gepostest hast) nirgens verbunden. Wenn man also erst den GPIB gerät und dann den USB GPIB enischaltet (bzw. usb kabel anschliesst) kommen manche geräte (je nach gerät konfig) damit nicht klar und der controller findet nix. An sich nix schlimmes, man stöpselt erst USB und dann schaltet das GPIB gerät an. Perfekt ist es aber nciht. > >> Der china clone hat mehr oder weniger eigene firmware, chinesisch >> sparen. > > Ist die Firmware dann im NI chip abgelegt? nein, die firmware ist in dem EEPROM von dem USB controller (cy7c68013a, abgekürzt FX2) > Ist es wirklich so problematisch Keithley-Geräte von Python oder > PureBasic aus anzusprechen? kann ihc dir nicht sagen, R&S, Yokogawa, EIP, HP, Xantrex/Sorensen, Philips/Fluke geräte funktionieren (abgesehen von dem bus master bug) ohne probleme. Zu beachten ist, was allerdings auch bekannt sein sollte, das manche geräte entsprechend angepasste konfiguration benötigen. > >> Das ergmöglicht drei möglichkeiten: >> - mit chinesischer firmware >> - mit meiner firmware >> - mit Agilent org. firmware > > also gibt es 3 Nöglichkeiten. > Kann man das Teil auch NI-kompatibel machen? > nein, nur eine da alle sich gleich (bis auf hardware bezogene kleinigkeiten wie status LED, SC pin steuerung, clock ausgang pin vom FX2) und das macht man per Agilent treiber einstellung, siehe bild. Sobald meine geräte richtig konfiguriert sind und ansprechbar im Agilent IO Controll habe weder probleme mit LabView noch mit VCC oder VB > >> Übrigens, der chinese konnte nicht erklären warum er floating pin >> gelassen hat ... > > komisch . . . > erst wollte er noch "sofort" nachgucken, dann als ich den ton etwas geändert habe konnte er nciht mehr erklären. > > Mich wundert nur, daß ja viele Käufer scheinbar zufrieden waren mit dem > Cloneteil. > http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=170637988180 > 29 wurden angeblich verkauft und bis auf einen schienen alle zufrieden. weil es beim 99% der benutzer funktioniert da die meisten nur daten lesen oder es remote steuern. > > http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=260799467757 > hat noch keines verkauft. Das Gehäuse sieht da viel robuster aus. Ist > die Frage ob man da auch Deine Firmware nutzen könnte. Mechanisch wird > man das schwer so gut hinbekommen. und er wird auch keins verkaufen. Standard Alu gehäuse, 10cm lang, dazu ohne schrauben, das will niemmand haben. Der andere clone hat 7cm, kunstoff, leicht, mit schrauben. Agilent org. ist 6.3cm lang. Ahja, noch eins. Beide china clones haben ein LDO für 3.3V und nix für 5V, also VUSB wird direkt für GPIB ICs benutzt. Das mag ich nciht, nach 2m USB kabel ist bei mir ende. Daher ist in meiner version ein LTC3538 verbaut, das dürfte für 4-5m kabel reichen. Ich werde beim routen gucken wie viel platz da ist, evt. mache ich den LTC3538 als options und nur jumper für 5V und ein simples LDO für 3.3V (wie die chinesen).
Danke Thomas für die Infos. Einen Plan hast Du ja zu diesen China-Dingern. Weißt Du warum die Chinesen nichts NI-kompatibles anbieten? Als ich nach Betrieb am Keithley fragte sagte der eine ich soll schauen, daß ich was von NI bekomme. Ist das von NI denn wirklich so anders? Von NI gibt es offenbar mehrere Varianten. GPIB-USB HS ist wohl eine schnelle Variante. GPIB-USB B scheint billiger zu sein. Und von GPIB-USB A habe ich auch gehört. Wenn die Unterschiede nur im USB-Controller liegen sollten die Unterschiede doch nicht so gross sein? Im Schaltbild der Uni Ljubljana sah ich einen FTDI mit paralleler Schnittstelle zu einem AVR 8515. Das geht natürlich flotter als ein FTDI mit nur TXD und RXD. So gesehen scheint dieses Design auch interessant zu sein. Es ist jedoch softwaregetrieben. Das erfordert Hirnschmalz in der Software. Dafür ist es anpassungsfähig. Dieses Teil kostet fertig wohl so um die 160.- EUR. Die China-Dinger sind also wohl billiger - auch nach dem Zoll noch?
Thomas R. schrieb: > Ahja, noch eins. Beide china clones haben ein LDO für 3.3V und nix für > 5V, also VUSB wird direkt für GPIB ICs benutzt. Das mag ich nciht, > nach 2m USB kabel ist bei mir ende. das verstehe ich. Die Spannung sollte schon so stabil sein, daß man den Bus auch treiben kann. Theoretisch könnten da ja ein paar Meter Kabel dranhängen und bis 14 Geräte. All diese muss das Teil ja treiben können ! Wie macht das denn NI? Ist das da auch so windig gelöst? Haben die größere Glättkondensatoren verbaut? > Daher ist in meiner version ein LTC3538 verbaut, das dürfte > für 4-5m kabel reichen. Ein Buck-Boost also. 800mA. > Ich werde beim routen gucken wie viel platz da ist, > evt. mache ich den LTC3538 als options und nur jumper für 5V und ein > simples LDO für 3.3V (wie die chinesen). Dann kann der Sparsame überlegen. Wenn man nur ein Gerät nutzt wird es wohl manchmal reichen. Das kommt auch auf den Querschnitt des USB-Kabels an.
Thomas R. schrieb: > Wenn man also erst den GPIB gerät und dann den USB GPIB enischaltet > (bzw. usb kabel anschliesst) kommen manche geräte (je nach gerät konfig) > damit nicht klar und der controller findet nix. An sich nix schlimmes, > man stöpselt erst USB und dann schaltet das GPIB gerät an. > Perfekt ist es aber nciht. bei dem Keithley-Adapter den ich damals hatte schien es mir so ein Problem zu geben. Entnervt kaufte ich am Ende von NI so ein Teil. > nein, die firmware ist in dem EEPROM von dem USB controller (cy7c68013a, > abgekürzt FX2) ok. Willst Du auch diesen Baustein nehmen oder eher einen FTDI? Fragt denn die Treiber-Software dieses EEPROM ab? Letztlich geht es doch wohl nur darum den 12MHz-Takt aktiv zu schalten und vielleicht die Bus-Treiber. Dazu offenbar den SC-Pin. Die Status-LED ist wohl weniger wichtig. > kann ihc dir nicht sagen, R&S, Yokogawa, EIP, HP, Xantrex/Sorensen, > Philips/Fluke geräte funktionieren (abgesehen von dem bus master bug) > ohne probleme. Zu beachten ist, was allerdings auch bekannt sein sollte, > das manche geräte entsprechend angepasste konfiguration benötigen. Du meinst Keithley spielt da eine Sonderrolle? > weil es beim 99% der benutzer funktioniert da die meisten nur daten > lesen oder es remote steuern. was will man mehr. Mir würde es wohl auch reichen das Gerät anzusprechen und dann die Daten einzulesen. Mit Interrupts brauche ich das ja nicht zu betreiben. > und er wird auch keins verkaufen. Standard Alu gehäuse, 10cm lang, > dazu ohne schrauben, das will niemmand haben. Du hast also beide näher angesehen? > Der andere clone hat 7cm, kunstoff, leicht, mit schrauben. das hört sich ja gut an. Willst Du auch die 7cm schaffen?
Matthias W. schrieb: > > Weißt Du warum die Chinesen nichts NI-kompatibles anbieten? > > Als ich nach Betrieb am Keithley fragte sagte der eine ich soll schauen, > daß ich was von NI bekomme. Ist das von NI denn wirklich so anders? > > Von NI gibt es offenbar mehrere Varianten. GPIB-USB HS ist wohl eine > schnelle Variante. GPIB-USB B scheint billiger zu sein. Und von GPIB-USB > A habe ich auch gehört. ein NI GPIB USB (nicht HS) ist auch Cypress µC basierend, allerdings ist drin der alte FX (EZ-USB) eingebaut. Die firmware ist damit nicht binär kompatibel zu den FX2 und NI hat keinen grund das zu ändern weil die den GPIB-USB-HS verkaufen möchten. Ein weiterer unterschied zum Agilent ist das da drin ein NAT4882 statt wie beim Agilent NAT9914 verbaut ist. Übrigens, der NAT4882 steuert vom haus auch den SC pin. Nachbauen geht natürlich schon, nur treiber für FX chip sind so eine sache. Ich habe mit mühe es zum laufen gebracht unter Vista 32bit, Win7 oder 64bit OSs sind nicht drin. Man kann auch die FX nirgens kaufen, ausser NOS, daher macht ein nachbau wenig sinn, vor allem weil der Agilent GPIB-USB auch funktioniert. Den HS habe nie von innen gesehen, keine ahnung was drin steckt. > > Wenn die Unterschiede nur im USB-Controller liegen sollten die > Unterschiede doch nicht so gross sein? > > Im Schaltbild der Uni Ljubljana sah ich einen FTDI mit paralleler > Schnittstelle zu einem AVR 8515. Das geht natürlich flotter als ein FTDI > mit nur TXD und RXD. > > So gesehen scheint dieses Design auch interessant zu sein. Es ist jedoch > softwaregetrieben. Das erfordert Hirnschmalz in der Software. Dafür ist > es anpassungsfähig. Dieses Teil kostet fertig wohl so um die 160.- EUR. > > Die China-Dinger sind also wohl billiger - auch nach dem Zoll noch? 19% einführumsatzsteuer tut nicht wirklich weh, dafür aber ist die hardware/treiber vom Agilent/NI. Ich halte nix von DIY GPIB controllern (ich meine software lösung). Das geht eigentlich gut für geräte, das habe ich schon gemacht, aber als controller will ich kein schmu haben. Es gibt eigentlich genug appnotes und beispiele um ein NAT9914 oder NAT4882 einzusetzen, auch welche für Cypress FX2+NAT9914 oder CPLD+NAT4882. Daher verstehe ich nciht warum manche rad neu erfinden müssen und alles per software machen möchten. Gut, beide NAT controller sind "schwer" beschafbar, weil nur NI die verkauft und nciht jeder fritz laden. Matthias W. schrieb: > das verstehe ich. Die Spannung sollte schon so stabil sein, daß man den > Bus auch treiben kann. Theoretisch könnten da ja ein paar Meter Kabel > dranhängen und bis 14 Geräte. All diese muss das Teil ja treiben können > ! ja genau, da hat chinese nicht dran gedacht. Für einzelnes gerät der am 1.5m USB kabel hängt ist das alles ok, will man mehr wird schon eng. > > Wie macht das denn NI? Ist das da auch so windig gelöst? > Haben die größere Glättkondensatoren verbaut? > NI und Agilent haben natürlich auch richtig gemacht, keine billig LDOs sondern step-up/down drin. >> Daher ist in meiner version ein LTC3538 verbaut, das dürfte >> für 4-5m kabel reichen. > > Ein Buck-Boost also. 800mA. ja, wobei ich mache 5V/500mA am ausgang wie in der appnote.
Matthias W. schrieb: > ok. Willst Du auch diesen Baustein nehmen oder eher einen FTDI? > Fragt denn die Treiber-Software dieses EEPROM ab? > ehm natürlich, es soll (ist schon) auch Agilent clone, FX2+NAT9914. Nur natürlich ohne sparmassnahmen wie bei den chinesischen clone. > Du meinst Keithley spielt da eine Sonderrolle? > kann ich nciht sagen, oft sind es einfach gerät einstellungen die nciht passen, ein EIP counter wollte auch nciht sofort funktionieren. >> und er wird auch keins verkaufen. Standard Alu gehäuse, 10cm lang, >> dazu ohne schrauben, das will niemmand haben. > > Du hast also beide näher angesehen? > >> Der andere clone hat 7cm, kunstoff, leicht, mit schrauben. > > das hört sich ja gut an. Willst Du auch die 7cm schaffen? ich erkenne die 10cm gehäuse auch so, weil ich auch solche gehäuse für andere sachen genommen habe. Den anderen (kleineren) china clone habe da. Ja, die 7cm auf jeden fall, mal sehen wie viel mehr noch geht. Der chinese hat nciht mal von hand geroutet, das sieht wirlich wild autorouter aus.
Der Witz eines Selbstbaus eines GPIB Master Controllers ist natuerlich nicht NI Kompatibilitaet, sondern die Funktionalitaet. NationalInstruments kann mir gestohlen bleiben, ich werd sicher nicht LabView verwenden, sondern moechte von einem Controller einen Mikrowellenzaehler oder sonstwas auslesen. Die dazu noetigen Commands werden gleich im GPIB Master Controllers implementiert, die Daten sind dann ueber das andere Interface erhaeltlich.
Oktal Oschi schrieb: > Der Witz eines Selbstbaus eines GPIB Master Controllers ist natuerlich > nicht NI Kompatibilitaet, sondern die Funktionalitaet. > NationalInstruments kann mir gestohlen bleiben, ich werd sicher nicht > LabView verwenden, sondern moechte von einem Controller einen > Mikrowellenzaehler oder sonstwas auslesen. Die dazu noetigen Commands > werden gleich im GPIB Master Controllers implementiert, die Daten sind > dann ueber das andere Interface erhaeltlich. bin nicht sicher wie dein posting zu verstehen ist. Ob mit oder ohne NI(LabView), mit dem Agilent GPIB-USB kann ich alle meine geräte (ob selbstgebaut oder gekauft) lesen/schreiben/steuern. Das kann ich auch mit einem umgebauten Philips RS232/GPIB, oder mit C64 nur weniger komfortabel.
Oktal Oschi schrieb: > Der Witz eines Selbstbaus eines GPIB Master Controllers ist natuerlich > nicht NI Kompatibilitaet, sondern die Funktionalitaet. grundsätzlich bin ich damit einverstanden ! Der Autor dieses Beitrags sah das wohl genauso: http://www.oe5.oevsv.at/export/sites/oe5/technik/messen_dl/HPIB_GPIB_IEEE488_Schnittstelle_V02.pdf Wenn man viel Zeit hat kann man so vorgehen. Vielleicht hat das sogar Vorteile an der einen oder anderen Stelle. Man versteht immerhin was man da macht. Das Protokoll hat der Mann ja schön herausgearbeitet. Sieht schon umsetzbar aus. > NationalInstruments kann mir gestohlen bleiben, ich werd sicher nicht > LabView verwenden, sondern moechte von einem Controller einen > Mikrowellenzaehler oder sonstwas auslesen. ok. Mit irgendeinem Programm muss man halt dran. Manche nehmen eben Labview, andere was anderes. Wenn man einen Auftrag hat mit Labview was machen zu müssen kann man schlecht ausbüchsen. Dann muss es auch damit gehen. Auch Python setzt auf etwas auf. Meist sind es Treiber oder DLL für bekannte Adapter von Herstellern wie NI oder Agilent. Mit Exoten hat man es da oft schwer. > Die dazu noetigen Commands > werden gleich im GPIB Master Controllers implementiert, ok. Diese Softwarelösungen machen das ja. > die Daten sind dann ueber das andere Interface erhaeltlich. Diese Aussage verstehe ich nicht. Über welches andere Interface?
>> die Daten sind dann ueber das andere Interface erhaeltlich. > >Diese Aussage verstehe ich nicht. Über welches andere Interface? zB ueber ein RS232, oder ein Ethernet.
Thomas R. schrieb: > ein NI GPIB USB (nicht HS) ist auch Cypress µC basierend, allerdings ist > drin der alte FX (EZ-USB) eingebaut. Die firmware ist damit nicht binär > kompatibel zu den FX2 und NI hat keinen grund das zu ändern weil die den > GPIB-USB-HS verkaufen möchten. NI möchte auf diese Weise ihren teuren HS-Adapter verkaufen? Die älteren nicht HS-Varianten sind somit kein guter Gebrauchtkauf? > Ein weiterer unterschied zum Agilent ist das da drin ein NAT4882 statt > wie beim Agilent NAT9914 verbaut ist. Übrigens, der NAT4882 steuert vom > haus auch den SC pin. Dann wäre der NAT4882 also der bessere Chip für so ein Interface? > Nachbauen geht natürlich schon, nur treiber für FX chip sind so eine > sache. Ich habe mit mühe es zum laufen gebracht unter Vista 32bit, > Win7 oder 64bit OSs sind nicht drin. > Man kann auch die FX nirgens kaufen, ausser NOS, daher macht ein nachbau > wenig sinn, vor allem weil der Agilent GPIB-USB auch funktioniert. es macht ja keinen großen Sinn mit veralteten Teilen was zu machen. > Den HS habe nie von innen gesehen, keine ahnung was drin steckt. schade. > 19% einführumsatzsteuer tut nicht wirklich weh, dafür aber > ist die hardware/treiber vom Agilent/NI. Ich halte nix von DIY GPIB > controllern (ich meine software lösung). > Das geht eigentlich gut für geräte, das habe ich schon gemacht, > aber als controller will ich kein schmu haben. wichtig ist letztlich die Funktion. Messbereich umschalten, Messung starten, Werte auslesen. Mehr will ich nicht. Das soll aber gut gehen ohne Stress. Es würde mich ärgern wenn der Adapter in 2 Jahren nicht mehr läuft weil es keinen Treiber mehr passend dazu gibt - nur weil die Hersteller dann wieder neuere Adapter verkaufen wollen. Für 1500.- dann? Wo soll das enden? USB3 kommt ja. > Es gibt eigentlich genug appnotes und beispiele um ein NAT9914 > oder NAT4882 einzusetzen, auch welche für Cypress FX2+NAT9914 > oder CPLD+NAT4882. Ich finde es toll, daß Du Dich da so gut eingearbeitet hast. > Daher verstehe ich nciht warum manche > rad neu erfinden müssen und alles per software machen möchten. Ein AVR ist ja recht flexibel. Und so ein Hexenwerk scheint es ja nicht den Handshake da zu implementieren. Offenbar läuft das Teil bei dieser jugoslawischen Uni ja auch. Wenn man keine DLL braucht kann auch kein Hersteller irgendwas drehen und so verhindern, daß es bei der nächsten Softwareversion noch läuft. > Gut, beide NAT controller sind "schwer" beschafbar, weil nur NI > die verkauft und nciht jeder fritz laden. das ist sicher ein Nachteil neben dem Preis. > NI und Agilent haben natürlich auch richtig gemacht, keine billig LDOs > sondern step-up/down drin. USB hat auch seine Grenzen. Längere Leitungen verursachen mehr Abfall. Wenn dann ein Wandler boosten muss kostet das auch Wirkungsgrad. Wenn der Bus schnell getrieben wird kann das schon Leistung fordern. Der USB-Port muss dann schauen, daß diese 500mA nicht überschritten werden. Vielleicht ist sogar noch ein Dialog nötig um den Strombedarf anzumelden. Ggf. kann es Sinn machen über ein Steckernetzteil nachzudenken wenn die Leitung länger wird.
Oktal Oschi schrieb: >>> die Daten sind dann ueber das andere Interface erhaeltlich. > zB ueber ein RS232, oder ein Ethernet. RS232 ist ja ok. Wenn die Baudrate hoch genug ist. Der Vorteil des GPIB-Bus war ja auch die Geschwindigkeit. Da liefen damals Drucker damit, Plotter, Floppy Disk-Laufwerke und sogar Festplatten ! Auf die Idee eine Festplatte über RS232 anzusteuern käme ich heute nicht. Ethernet ist ok. Der Energiebedarf ist jedoch recht hoch. Da braucht es wohl ein Steckernetzteil vor Ort am Adapter. So ganz einfach scheint es nicht so ein Ding zu bauen. Die 224.- für das Prologix-Teil sind auch eine kleine Stange Geld. Die USB-Lösungen aus China sind da billiger.
Matthias W. schrieb: > > Dann wäre der NAT4882 also der bessere Chip für so ein Interface? > der kann mehr, ob man braucht ist eine andere sache. > Und so ein Hexenwerk scheint es ja nicht > den Handshake da zu implementieren. Offenbar läuft das Teil bei dieser > jugoslawischen Uni ja auch. Wenn man keine DLL braucht kann auch kein > Hersteller irgendwas drehen und so verhindern, daß es bei der nächsten > Softwareversion noch läuft. > >> Gut, beide NAT controller sind "schwer" beschafbar, weil nur NI >> die verkauft und nciht jeder fritz laden. > > das ist sicher ein Nachteil neben dem Preis. > als die lösung von Ljubljana entstanden war konnte man locker noch den upD7210 kaufen. Die ICs kosten nicht die welt, ob alte org. controller oder die von NI (7210, 9914 oder 4882), die zeit die man investieren muss ist die selbe, es war wohl eine ABM massnahme für studenten.
@Thomas R.: Super Projekt! Ich wollte schon fast einen Chinaclone bestellen.. Matthias W. schrieb: > Wenn man einen Auftrag hat mit Labview was > machen zu müssen kann man schlecht ausbüchsen. Dann muss es auch damit > gehen. Im professionellen Umfeld wird man wohl auch eher den Kaufpreis für das Original verschmerzen können als sich mit einem Chinaclone herumzuschlagen zu müssen oder das Teil selbst zubauen. Matthias W. schrieb: > NI möchte auf diese Weise ihren teuren HS-Adapter verkaufen? Warum sollten die ein entwickeltes Design über Board werfen um ihre Firmware kompatibel zu anderen Lösungen zu machen? Wäre wohl recht unsinnig.. > Die älteren nicht HS-Varianten sind somit kein guter Gebrauchtkauf? Musst du zu jeder Aussage eine Frage liefern? Wenn du neuere Betriebssysteme einsetzen willst wohl eher nicht, hat Thomas doch erklärt. > es macht ja keinen großen Sinn mit veralteten Teilen was zu machen. Ach wirklich? > Wenn dann ein Wandler boosten muss kostet das auch Wirkungsgrad. Wenn > der Bus schnell getrieben wird kann das schon Leistung fordern. Der > USB-Port muss dann schauen, daß diese 500mA nicht überschritten werden. > Vielleicht ist sogar noch ein Dialog nötig um den Strombedarf > anzumelden. Da die Agilent-Teile wohl USB zertifiziert sein dürften, wird das entsprechend in der Firmware implementiert sein. > Ggf. kann es Sinn machen über ein Steckernetzteil nachzudenken wenn die > Leitung länger wird. Die Teile von NI, Agilent usw funktionieren einwandfrei ohne Netzteil. Warum sollte man jetzt bei einem Nachbau unbedingt eines vorsehen wollen? Man könnte auch gleich einen Akku mit einbauen? Entschuldige, aber wenn hier jeder alles kommentiert und jede noch so offensichtliche Aussage hinterfragt bzw zerlegt wird sprengt das bald den Rahmen und wird unübersichtlich. Gut, es kommt wohl eh bald ein neuer Beitrag zu dem Nachbau, aber da geht's dann wohl genauso weiter.
Thomas R. schrieb: >> Dann wäre der NAT4882 also der bessere Chip für so ein Interface? > der kann mehr, ob man braucht ist eine andere sache. Wenn er keinen echten Vorteil bringt, warum dann soll man ihn nehmen. Wenn er nicht mehr kostet kann man es ja überlegen. > als die lösung von Ljubljana entstanden war konnte man locker noch den > upD7210 kaufen. Es wird schon Gründe gegeben haben warum die einen AVR nehmen wollten. Mir gefällt die Idee mit den gut echtzeittauglichen AVR etwas zu machen, das dann auch Zukunft hat. Offenbar arbeiten die Studenten schon lange an Optimierungen der Software. Keine Ahnung ob das wirklich nötig ist. Die werden sich das schon überlegen. > Die ICs kosten nicht die welt, ob alte org. controller > oder die von NI (7210, 9914 oder 4882), die zeit die man investieren > muss ist die selbe, es war wohl eine ABM massnahme für studenten. Die Problematik bei diesen Chips sehe ich im Treiber. Jeder Anwender greift da wohl über eine DLL zu. Wenn ein neueres Windows kommt gibt es das Zittern ob dann noch was geht. Wenn ich lese daß Kunden noch DLLs von Windows 95 auf einem alten Rechner behalten nur damit sie eine alte Karte weiter nutzen können dann sieht man was für ein Krampf so ein Konzept ist, wenn es um Nachhaltigkeit geht. Eben diese chips (9914, 4882) sollten doch so schlau sein, daß man nur ein paar Register programmiert und dann der Chip den Rest alleine macht. Wofür braucht es da einen proprietären Treiber? Ein paar Befehle schicken an den USB-Adapter sollte doch reichen. Der Mann, der seine Messgeräte einfach steuern wollte http://www.oe5.oevsv.at/export/sites/oe5/technik/messen_dl/HPIB_GPIB_IEEE488_Schnittstelle_V02.pdf hat transparent geschrieben wie einfach das Ansprechen letztlich geht.
Rob schrieb: > Im professionellen Umfeld wird man wohl auch eher den Kaufpreis für das > Original verschmerzen können als sich mit einem Chinaclone > herumzuschlagen zu müssen oder das Teil selbst zubauen. klar. > Warum sollten die ein entwickeltes Design über Board werfen um ihre > Firmware kompatibel zu anderen Lösungen zu machen? Wäre wohl recht > unsinnig.. Meine Frage zielte darauf ab, warum NI selbst ein Design GPIB-USB A hat, ein Design GPIB-USB B und dann noch ein Design GPIB-USB HS. Welchen Grund soll ein Nutzer haben den teuren GPIB-USB HS zu kaufen, wenn die anderen doch genauso zuverlässig arbeiten? Oder ist das nicht der Fall? > Musst du zu jeder Aussage eine Frage liefern? wer etwas lernen will muss Fragen stellen. Anhand der Antworten können dann auch andere lernen. Wer schon alles weiß braucht keine Fragen mehr zu stellen. Nur warum liest er dann hier solche Beiträge? Langeweile? >> es macht ja keinen großen Sinn mit veralteten Teilen was zu machen. > Ach wirklich? was willst Du damit sagen? > Da die Agilent-Teile wohl USB zertifiziert sein dürften, wird das > entsprechend in der Firmware implementiert sein. ja. Und dann muss es auch im Selbstbau so gemacht werden. Vielleicht ist dies ja nicht ganz so einfach . . . > Die Teile von NI, Agilent usw funktionieren einwandfrei ohne Netzteil. prima wenn es so ist unter allen Betriebsbedingungen. Ich kenne den Energiebedarf so einer ISA-Karte nicht. Letztlich braucht der Chip Strom und die Treiber. Aus dem ISA-Slot kann man locker 1A und mehr ziehen, aus dem USB-Port über ein längeres Kabel eben nicht. > Warum sollte man jetzt bei einem Nachbau unbedingt eines vorsehen wollen? Man sollte schon nachdenken über Energiebedarf und Stabilität solcher Ansätze wenn man sich ernsthaft mit einem Design beschäftigt. > Man könnte auch gleich einen Akku mit einbauen? Zynismus? Ich stelle diese Fragen, weil ich meine, daß man über manches mal nachdenken sollte. Ich selbst hatte 2 teure Adapter von USB nach GPIB. Das 700.- teure Teil bescherte mir 8 Wochen Stress. Der Support wusste wenig dazu zu sagen. Das zeigt daß diese Technik keinesfalls so unproblematisch ist. Man muss sich schon seriös damit auseinandersetzen. Wenn nicht mal die Hersteller in der Lage sind dem Kunden solche Klippen aus dem Weg zu räumen wer soll es dann können?
Hallo, ich verfolge diesen Thread ebenfalls. Was die Übersichtlichkeit angeht, so frage ich mich, ob man jeden Satz des Vorredners zitieren muss, eine wirklich unangenehme Angewohnheit, die den Thread unnötig in die Länge zieht und damit langweilig macht. Was die Frage der verschiedenen Versionen angeht, so verhält es sich ähnlich dem Agilent GPIB-USB-Adapter: 82357A USB/GPIB --> USB1.1 interface to IEEE488 interface 82357B USB/GPIB --> USB2.0 interface to IEEE488 interface Beim Adapter von NI erkennt man den Unterschied in der Übertragungsgeschwindigkeit: GPIB-USB-A: 650 Kbytes/s GPIB-USB-B: 850 Kbytes/s (NI-488.2 version 2.0 and later) GPIB-USB-HS: 1,8 MB/s (IEEE 488.1) und 7,2 MB/s (HS488) branadic
Matthias W. schrieb: > Meine Frage zielte darauf ab, warum NI selbst ein Design GPIB-USB A hat, > ein Design GPIB-USB B und dann noch ein Design GPIB-USB HS. Welchen > Grund soll ein Nutzer haben den teuren GPIB-USB HS zu kaufen, wenn die > anderen doch genauso zuverlässig arbeiten? Oder ist das nicht der Fall? Warum baut Audi nicht mehr den 80, war doch auch ein Auto und ist auch zuverlässig gefahren? Warum gibt es ein Iphone4? Der HS ist nun mal der aktuelle in der "Modellpflege". >> Musst du zu jeder Aussage eine Frage liefern? > > wer etwas lernen will muss Fragen stellen. Anhand der Antworten können > dann auch andere lernen. Ja, aber bei grundlegenden Sachen hilft z.B. Google weiter. Und alles muss nicht von dir kommentiert werden, erst Recht bei Aussagen wie "Das Teil hat USB" - "Ach, das Teil hat also USB?". Gegen ernsthafte Fragen hab' ich nichts, aber das meiste kann man Thomas' Beiträgen entnehmen. Und wenn er Prototypen mit dem NI Chip baut/ extra Bezugsquellen sucht/ zig mal schreibt, dass er nichts von den Softwarelösungen hält, muss man wohl nicht fragen, was er von den Softwarelösungen hält? > Nur warum > liest er dann hier solche Beiträge? Langeweile? Weil ich Interesse an Roberts' Beiträgen und dem Nachbau hab'. Matthias W. schrieb: > Die Problematik bei diesen Chips sehe ich im Treiber. Der Agilent, der hier nachgebaut werden soll, ist das aktuelle Modell. Da wird es also noch ein bisschen Treibersupport geben. Dass Ein Hersteller keine ISA-Treiber für Windows7 anbietet ist doch wohl verständlich. Aber bei dem Clone sollte sich der Preis - und damit Das Risiko bei Modellpflege - doch in Grenzen halten. > Ein paar Befehle schicken an den USB-Adapter sollte doch reichen. Der > Mann, der seine Messgeräte einfach steuern wollte > http://www.oe5.oevsv.at/export/sites/oe5/technik/m... > hat transparent geschrieben wie einfach das Ansprechen letztlich geht. Dann bau' doch das nach. Thomas wird sicherlich nicht plötzlich die Lösung mit dem NI-Chip über den Haufen werfen und einen AVR nehmen. Wenn dir also die andere Lösung besser gefällt, warum nicht? >>> es macht ja keinen großen Sinn mit veralteten Teilen was zu machen. >> Ach wirklich? > > was willst Du damit sagen? Das nicht jeder hier geschriebene und offensichtliche Satz ein Kommentar deinerseits benötigt. >> Da die Agilent-Teile wohl USB zertifiziert sein dürften, wird das >> entsprechend in der Firmware implementiert sein. > > ja. Und dann muss es auch im Selbstbau so gemacht werden. Vielleicht ist > dies ja nicht ganz so einfach . . . Ja, wenn die Original-Firmware läuft, dann ist es sicher schwierig, das so hinzubekommen, dass die immer noch das gleiche macht. Mal davon abgesehen, dass ich hier volles Vertrauen zu Thomas habe. >> Die Teile von NI, Agilent usw funktionieren einwandfrei ohne Netzteil. > > prima wenn es so ist unter allen Betriebsbedingungen. Ich kenne den > Energiebedarf so einer ISA-Karte nicht. Letztlich braucht der Chip Strom > und die Treiber. Aus dem ISA-Slot kann man locker 1A und mehr ziehen, > aus dem USB-Port über ein längeres Kabel eben nicht. Was willst du jetzt mit einer ISA-Karte? Der FX2 Chip war nie auf einer, da er ein _USB_-Controller ist. Und die Gerätschaften haben eine eigene Spannungsversorgung, da werden 500mA schon ausreichend sein. Und ja, das dürfte unter so ziemlich allem Betriebsbedingungen so sein.. > Man sollte schon nachdenken über Energiebedarf und Stabilität solcher > Ansätze wenn man sich ernsthaft mit einem Design beschäftigt. Immerhin sind bei NI wohl keine Bastler am Werk, die das Pi mal Daumen machen. Deren Lösungen werden in der Industrie eingesetzt, wo es auf absolute Zuverlässigkeit ankommt. Oder anders gesagt; die haben mehr Ahnung als du ;-P Sprich, bei einem "Bastlernachbau" dürfte man das Beste Ergebnis wohl dann erzielen, wenn man möglichst nah an den originalen Teilen dran ist. >> Man könnte auch gleich einen Akku mit einbauen? > > Zynismus? Ich stelle diese Fragen, weil ich meine, daß man über manches > mal nachdenken sollte. Ich selbst hatte 2 teure Adapter von USB nach > GPIB. Das 700.- teure Teil bescherte mir 8 Wochen Stress. Der Support > wusste wenig dazu zu sagen. Mit den originalen NI-Lösungen hatte ich noch keine Probleme. Aber privat sind mir die zu teuer, da wäre dann interessant, was das für Teile sind die bei dir nicht laufen? Und womit genau du Probleme hattest? Vielleicht Geräte/ Software die sich selbst nicht ganz an die Spezifikationen halten? > Wenn nicht mal die Hersteller in der Lage sind dem Kunden solche Klippen > aus dem Weg zu räumen wer soll es dann können? Welcher Hersteller? NI? Agilent?
branadic schrieb: > GPIB-USB-A: 650 Kbytes/s > GPIB-USB-B: 850 Kbytes/s (NI-488.2 version 2.0 and later) > GPIB-USB-HS: 1,8 MB/s (IEEE 488.1) und 7,2 MB/s (HS488) Danke für diese Info.
Rob schrieb: > da wäre dann interessant, was das für Teile sind die bei dir nicht laufen? Das Teil was nicht lief (zusammen mit Labview) war ein Original-Keithley-USB-Adapter an einem Keithley-Gerät. > Vielleicht Geräte/ Software die sich selbst nicht ganz an die > Spezifikationen halten? Der Keithley-USB-Adapter sollte sich an die Specs des Keithley-Geräts halten. >> Wenn nicht mal die Hersteller in der Lage sind dem Kunden solche Klippen >> aus dem Weg zu räumen wer soll es dann können? > Welcher Hersteller? NI? Agilent? Keithley in Verbindung mit Labview. So einfach ist die Sache eben nicht ! Schönreden hilft dann gar nicht weiter !
Angehängte Dateien:
Hallo, ich habe den GPIB_USB Adapter aus dem Heft Elektor April 2011 vereinfacht nach gebaut. Das bedeutet ein altes Elektor R8C Starterkit (Beilage im Heft 12-2005!) und ein Nokia USB-Datenkabel CA-42 Clone (Chip Polific PL2302), bei Ebay für nur 5 EUR (inkl. Versand). Benutzt wird es an meinem Logic Analyzer HP1631D. Genauere Details mit Bildern zum Nachbau sind auf http://www.rudiswiki.de/wiki9/GPIBtoUSB Grüße, Rudi
Rudolf Reuter schrieb: > GPIB_USB Adapter vereinfacht nach gebaut. > http://www.rudiswiki.de/wiki9/GPIBtoUSB Vielen Dank Rudi !
da irgendetwas nicht gestimmt hat mit dem nachbau habe mir die bilder vom org. Agilent 82357B besorgt. Irgendwie waren die aussagen vom china cloner nicht ganz klar. Jetzt ist klar warum, die 488.2 ist mit hilfe von CPLD realisiert, das hat der china clone nicht. An sich nicht so schlimm, der nachbau vom china clone geht mittlerweile 100%, nur ich wollte eigentlich Agilent nachbauen und nicht den armen chinesen seine einzige geld eingangsquelle wegnehmen. Der author hat mich auch kontaktiert und ganz nett gebeten, ich werde es also hier nicht publizieren. Was Agilent clone angeht, ich werde weiter machen, wird aber aus beruflichen gründen nicht so schnell gehen.
Angehängte Dateien:
-
txo10MHz_BNC.png
4,5 KB
Hallo, mein GPIB_USB Konverter mit dem R8C Starterkit ist jetzt fertig, Bild siehe Post vom 18.06.2011. Dazu habe ich ein PYTHON Programm geschrieben, mit dem man die wichtigsten Funktionen fernsteuern kann. Zum Beispiel eine Bildschirm Hardcopy machen, siehe Anhang. Dokumentation unter http://www.rudiswiki.de/wiki9/GPIBtoUSB Grüße, Rudi
Rudolf Reuter schrieb: > Dazu habe ich ein PYTHON Programm geschrieben prima Rudi, sieht toll aus. Auch dieses Messgerät, das Du da ausliest scheint interessant zu sein.
Matthias W. schrieb: > Auch dieses Messgerät, das Du da ausliest > scheint interessant zu sein. Hallo Matthias, das Gerät HP1631D ist zwar schon 27 Jahre alt, aber mit 2 x 200 MHz sampling rate im Oszillographen-Teil ist es immer noch konkurrenzfähig :-) Dazu kommt noch die Logik Analyse mit 43 Kanälen (State) und 16 Kanäle im Timing. Leider sehr schwer und laut (230 W müssen gekühlt werden). Letzte Woche wurde eines bei Ebay für 110 EUR versteigert. Also immer noch empfehlenswert. Grüße, Rudi
Rudolf Reuter schrieb: > Leider sehr schwer und laut (230 W müssen gekühlt werden) Das kann ich bestätigen. Laut ist gar kein Ausdruck, meins dröhnt ganz erbärmlich. Aber du hast recht, es ist absolut solide Messtechnik die man heute fast schon geschenkt bekommt. (Hab 2007 für 350€ ein frisch kalibriertes Gerät von der BW gekauft)
Rudolf Reuter schrieb: > das Gerät HP1631D ist zwar schon 27 Jahre alt, aber mit 2 x 200 MHz > sampling rate im Oszillographen-Teil ist es immer noch konkurrenzfähig Danke für den Hinweis. Gewicht und Größe sind natürlich etwas hinderlich wenn der Keller schon voll steht mit Geräten. Digital habe ich noch nichts. Rigol wird nun auch von Meilhaus vertrieben. GWInstek scheint brauchbar wie ich gehört habe. Im Vergleich zu den alten soliden Geräten ist heute alles sehr kurzlebig geworden. Hameg versucht wenigstens leise zu sein. Leider soll das Bedienkonzept wenig intuitiv sein. Schade, wenn es so ist.
Loonix schrieb: > absolut solide Messtechnik die man heute fast schon geschenkt bekommt. Das ist natürlich zu bedenken. Wenn man was dran reparieren muss wird es wohl schwer. Freaks die sich da auskennen und Hilfe geben könnten schwer zu finden sein.
Matthias W. schrieb: > Wenn man was dran reparieren muss wird es > wohl schwer. Daran muss man aber nichts reparieren, selbst die Elkos der Schaltnetzteile haben damals noch gehalten. ;-) Ansonsten dürfte es bestenfalls darum gehen, mechanisch beanspruchte Teile mal zu tauschen, also Lüfter oder Floppylaufwerk. Die Signalverarbeitung ist in derartigen Geräten komplett mit custom ICs gemacht (die HP auch selbst entworfen und gefertigt hat), daran kann man sowieso nichts ernsthaft reparieren. (Falls jemand Interesse hat, ich werde demnächst mein HP1652B verkaufen, das hat auch ein Oszilloskop drin. Ich habe mir jetzt ein HP16700 zugelegt.)
So ähnlich wie Rudi möchte ich auch was bauen. Dazu habe ich mir so eine Teensy-Platine bestellt. Auf diese soll ein ATmega32U2. Muss mal sehen wo ich den ohne viel Versandkosten bekommen kann. Ein paar Drähte zur GPIB-Buchse noch. Und dann das Programm dazu. So ist die Idee.
Hallo Matthias, bei Ebay gibt unter dem Suchbegriff Arduino Nano 3 eine Platine mit Mini-USB Buchse und AVR ATMega328P Prozessor für 15,50 EUR inkl. Versand aus Hongkong. Das dauert so 2-3 Wochen Versand, und bei einem Warenwert unter 22 EURO beim Zoll abgaben frei. Das Schaltbild gibt es bei: http://www.arduino.cc/en/Main/ArduinoBoardNano Ich denke, dass damit auch der GPIB_USB Konverter läuft. Ich habe mir mal 2 Stück bestellt. Grüße, Rudi
Angehängte Dateien:
-
arduino.png
150 KB -
arduino1.png
99 KB -
teensy.png
140 KB -
teensy_schaltbild.png
18 KB
Vielen Dank Rudi für den interessanten Beitrag. Der Arduino Nano 3 mit ATMega328P ist nett gemacht. Sogar ein ISP-Stecker ist drauf, wenn auch nur die 6-polige Variante. Prima, wenn Du das als Basis nutzt. Ich habe Bild, Plan und Eagle mal angehängt. Ich habe dieses Teensy-Board bestellt für knapp 8.-. Als CPU möchte ich einen ATmega32U2 besorgen. Das müsste auch gehen. Es sind weniger Teile, wenn man eine Leiterplatte draus machen möchte, was sich ja anbietet. Vielleicht kannst Du Dich mit dem Konzept ja anfreunden. Der Vorteil könnte sein, daß bei dieser Lösung USB besser integriert ist über ein DualPortRam. Es sind weniger Teile im Spiel. Der ADC des Nano 3 wird hier ja nicht benötigt.
Hallo Matthias, der Vorteil von dem Arduino Nano ist die USB Mini Buchse, die CPU hat 2 KB RAM, und es ist fertig aufgebaut. Also nur noch 16 Widerstände und 0V an die GPIB Buchse löten und FERTIG ;-) Bei dem original teensy hat die CPU nur 512 Byte RAM. Das ist für diese Anwendung schon sehr knapp. Grüße, Rudi
Als Anschluß an das Teensy-Board habe ich überlegt: GPIB-Buchse ATmega32U2 D5 Pin 13 PD4 INT5 Pin 10 D6 14 PD5 XCK 11 D7 15 PD6 INT6 RTS 12 D8 16 PD7 INT7 HWB CTS TO 13 REN 17 PB0 SS 14 D1 1 PD0 INT0 OCOB 6 D2 2 PD1 INT1 AIN0 7 D3 3 PD2 INT2 AIN1 RXD1 8 D4 4 PD3 INT3 TXD1 9 EOI 5 PB5 19 DAV 6 PB6 20 NFRD 7 PB7 OCOA OC1C 21 NDAC 8 PC7 INT4 ICP1 22 IFC 9 PC6 OC1A 23 SRQ 10 PC5 OC1B 25 ATN 11 PC4 26 Ist die Frage ob das so günstig ist. Wenn der Bus was signalisiert könnte es Sinn machen diesen Pin auf einen IRQ zu legen. Ich habe die Software noch nicht angesehen.
Rudolf Reuter schrieb: > der Vorteil von dem Arduino Nano ist die USB Mini Buchse, die CPU hat 2 > KB RAM, und es ist fertig aufgebaut. ja, das leuchtet ein. Das Teensy, was ich da nun genommen habe ist komplett aufgebaut bis auf die CPU. Die werde ich auflöten können. Das RAM der ATmega32U2 liegt bei 1kB. Wäre schön wenn es reicht. Was meinst Du?
Rudolf Reuter schrieb: > der Vorteil von dem Arduino Nano ist die USB Mini Buchse, die CPU hat 2 > KB RAM wenn das Teil gut geht könnte ich mir schon vorstellen eine kleine Platine zu machen, damit das kompakter hinten dran hängt am Gerät als es mit den heute üblichen Adaptern geht. USB Mini-Buchse ist ja machbar. Der ATmega32U2 hätte (falls das RAM reicht) den Vorteil, daß es weniger Teile sind. Die 16 Widerstände 470 Ohm hältst Du für erforderlich? Fromhagen hatte da nichts vorgesehen bei seiner Lösung.
Hallo Matthias, die 1 KB RAM sollten reichen. Die 470 Ohm Widerstände sind zum Schutz der CPU gedacht. Ohne die richtigen Treiber IC's ist das nur eine eingeschränkte Lösung für wenige Bus Teilnehmer. Aber das ist ja im Hobby Bereich die Normalität. Grüße, Rudi
Rudolf Reuter schrieb: > die 1 KB RAM sollten reichen. prima. Dann muss ich nur die CPU noch bekommen. > Die 470 Ohm Widerstände sind zum Schutz der CPU gedacht. meinst Du 220 Ohm würden auch reichen? Je niederohmiger um so sicherer müssten 30cm GPIB-Kabel oder vielleicht ein Meter noch getrieben werden können. Hast Du mal Versuche mit einem längeren Kabel gemacht? > Ohne die richtigen Treiber IC's ist das nur eine eingeschränkte > Lösung für wenige Bus Teilnehmer. Aber das ist ja im Hobby > Bereich die Normalität. klar. Ich möchte auch nur 2-3 Geräte da dranhängen, mehr nicht. Den Rest mache ich mit USB.
Hallo Matthias, meine verwendete GPIB Kabellänge beträgt 2,3 m. Bei längeren Kabeln könnte man im Bedarfsfall die Verzögerungszeiten beim Handshake anpassen. Die Widerstände zum GPIB Bus sollten nur die CPU schützen. Das bedeutet den I/O Kurzschluss Strom auf einen erlaubten Wert begrenzen. Dazu muss man auch noch die maximal erlaubte Stromaufnahme der CPU achten, sie ist kleiner als die Summe der maximal möglichen I/O Ströme. Grüße, Rudi
Rudolf Reuter schrieb: > meine verwendete GPIB Kabellänge beträgt 2,3 m. 2.3m hört sich für mich ausreichend an. > Bei längeren Kabeln könnte man im Bedarfsfall > die Verzögerungszeiten beim Handshake anpassen. wenn das Sinn macht könnte man das ja tun. Wenn der Verlust an Geschwindigkeit klein ist mag es sinnvoll sein. > Die Widerstände zum GPIB Bus sollten nur die CPU schützen. Ist halt die Frage wie kritisch das wirklich ist. Es gibt ja mehrere Fälle: - alle GPIB-Geräte abgeschaltet. Adapter an und treibt Strom in den Bus. - alle GPIB-Geräte eingeschaltet. Adapter treibt gegen diese Geräte. - . . . am einfachsten wäre mal zu schauen welcher Spannungsabfall sich an den Schutzwiderständen (ggf. niederohmigere zum Messen nehmen) einstellt. Dann sieht man ja rasch was sich da aufsummieren kann. Wenn echte Treiber mit im Spiel sind, die vielleicht 24 oder gar 48mA treiben können pro Pin, so kommt da auch bei realen Adaptern ggf. einiges zusammen. Thermisch geschützt sind solche Treiber üblicherweise nicht. Wenn der Treiberchip die Wärme nicht besser ableiten kann als eine CPU kann es sogar sein, daß dieser Fall ungünstiger ist als wenn man auf die Treiberchips verzichtet und 220 Ohm Serienwiderstände hat. Mehr als I=4/220=18mA können nicht aus einem Pin fließen (bei 220 Ohm). 40mA wären zulässig pro Pin und in Summe 200mA (S.264). Daß über alle Pins länger so viel fließt scheint eher unwahrscheinlich. Bei 20mA und 85°C treibt der Baustein kein Low mehr. Die USB-Zuleitung hat ja auch Widerstand. Auch ein Polyswitch wäre als Schutz denkbar.
Matthias W. schrieb: >>> Wenn nicht mal die Hersteller in der Lage sind dem Kunden solche Klippen >>> aus dem Weg zu räumen wer soll es dann können? >> Welcher Hersteller? NI? Agilent? > > Keithley in Verbindung mit Labview. So einfach ist die Sache eben nicht > ! > Schönreden hilft dann gar nicht weiter ! Keithley ist aber nicht NI oder Agilent. Denen würde ich da eher trauen, statt zu pauschalisieren... Wobei ich mir hier eher vorstellen kann, dass der Fehler wohl nicht an Keithley lag.. Matthias W. schrieb > ... Du traust Agilent/ NI nicht zu, dass die ihre Adapter richtig designen und jetzt möchtest du unbedingt ein Elektor-Teil nachbauen? Da muss man nichts mehr verstehen, oder?
Rob schrieb: > Wobei ich mir hier eher vorstellen kann, dass der Fehler wohl nicht an Keithley lag.. und warum lief es dann mit dem NI-Adapter problemlos? > Du traust Agilent/ NI nicht zu, dass die ihre Adapter richtig designen > und jetzt möchtest du unbedingt ein Elektor-Teil nachbauen? Du stellst Behauptungen auf, die nicht weiterführen. Ich habe oben deutlich gesagt, daß es wochenlang Probleme gab und Keithley und NI den schwarzen Peter hin und hergeschoben haben ohne daß es vor Ort eine Lösung gab. So was ist schlicht unzumutbar. Ich brauche so was nicht. Auch die China-Lösung muss nicht stressfrei sein, denn nach Aussage von dort läuft das Teil mit Keithley unter Python angeblich nicht. Es kann also gehen muss aber nicht. > Da muss man nichts mehr verstehen, oder? Was ist da so schwer zu verstehen? Immerhin hat Rudi (so wie auch andere !) seine GPIB-Aufgabe mit diesem einfachen billigen Ansatz ohne den Monster-Treiber von NI/Agilent lösen können. Der C-Code scheint verständlich zu sein und so ist anzunehmen, daß diese Lösung auch noch unter den nächsten Windowsversionen laufen wird im Gegensatz möglicherweise zu den üblichen teuren Industrielösungen. Wenn Du das nicht verstehen kannst/willst finde ich das schade. Bleib dann lieber bei Deiner Lösung und gut ist. Wenn Du aktiv was Positives beitragen willst zu diesem AVR-Ansatz, dann tue es. Ansonsten lass die machen, die hier was aufbauen was in der Praxis funktioniert.
Matthias W. schrieb: > ... > und warum lief es dann mit dem NI-Adapter problemlos? und > Du stellst Behauptungen auf, die nicht weiterführen. Ich habe oben > deutlich gesagt, daß es wochenlang Probleme gab und Keithley und NI den > schwarzen Peter hin und hergeschoben haben ohne daß es vor Ort eine > Lösung gab. Das widerspricht sich irgendwie; was genau war denn das Problem? Der GPIB-Bus ist doch irgendwie genormt und wenn sich alle Geräte an die Norm halten, sollte es doch funktionieren. > Auch die China-Lösung muss nicht stressfrei sein, denn nach Aussage von > dort läuft das Teil mit Keithley unter Python angeblich nicht. Es kann > also gehen muss aber nicht. Die China-Lösung verwendet die Treiber und Software-Library von Agilent. Wenn es unter Python nicht funktioniert, dann liegt das nicht an der Hardware, sondern vermutlich daran, dass das Keythley-Gerät nicht die SCPI-Sprache unterstüzt und bei der Agilent-Software kein Treiber für das Keythley-Gerät dabei ist. Man kann das aber trotzdem irgendwie ansprechen, muss dann aber auf einer unteren Protokoll-Ebene (z.B. vpp43) mit dem Gerät kommunizieren. Bei einem Selbstbau-Adapter muss man das aber auch, das ist also kein Nachteil des China-Adapters (bzw. von Agilent oder NI)
Johannes E. schrieb: > Der GPIB-Bus ist doch irgendwie genormt und wenn sich alle Geräte an die > Norm halten, sollte es doch funktionieren. das dachte ich auch. Leider war das wohl eine Treibersache in Verbindung mit der Firmware von Keithley. Jedenfalls konnte ich die Geräte über Labview nicht brauchbar ansprechen. Mit dem Adapter von NI in Verbindung mit dem NI-Treiber lief es ohne Stress auf Anhieb. > Man kann das aber trotzdem irgendwie ansprechen, muss dann aber auf > einer unteren Protokoll-Ebene (z.B. vpp43) mit dem Gerät kommunizieren. ja. Das scheint mir der Rettungsanker zu sein. > Bei einem Selbstbau-Adapter muss man das aber auch, das ist also kein > Nachteil des China-Adapters (bzw. von Agilent oder NI) Ich habe nichts gegen einen billigen Chinaadapter, wenn es eine C-Datei dazu gibt die verständlich einen Zugriff auf dieser unteren Protokoll-Ebene ermöglicht. Ist das denn der Fall? Gibts dazu etwas?
Matthias W. schrieb: >> Du traust Agilent/ NI nicht zu, dass die ihre Adapter richtig designen >> und jetzt möchtest du unbedingt ein Elektor-Teil nachbauen? > > Du stellst Behauptungen auf, die nicht weiterführen. Nicht ich stelle die Behauptungen auf, ich fasse nur dein Gelaber weiter oben zusammen. Und hier ging es eindeutig um die Adapter von Agilent und NI, denen du beiden nicht zugetraut hast, den Energiebedarfs des Busses richtig abzuschätzen (u.A.): >> Die Teile von NI, Agilent usw funktionieren einwandfrei ohne Netzteil. >> Warum sollte man jetzt bei einem Nachbau unbedingt eines vorsehen wollen? > > Man sollte schon nachdenken über Energiebedarf und Stabilität solcher > Ansätze wenn man sich ernsthaft mit einem Design beschäftigt. > Wenn nicht mal die_ _Hersteller in der Lage sind dem Kunden solche > Klippen aus dem Weg zu räumen wer soll es dann können? Du verallgemeinerst hier ohne Grenzen, bemängelst Probleme mit einem anderen Hersteller wenn es um NI/Agilent geht, erst auf zig Nachfragen, rückst du damit raus, dass es um Keithley geht. Das ist etwa so, wie wenn du darüber schimpfst, dass alle Golf kacke sind und der Autobau nicht so trivial ist, weil du vor Jahren mit deinem Lada Probleme hattest. Und dann aber nicht mal dazu sagst, dass es an Lada hing, sondern munter bei der Golf-Diskussion mitmischt. > und warum lief es dann mit dem NI-Adapter problemlos? Jetzt auf einmal lieferst du diese Info. Wo du vorher diesen Problemfall dazu heranführst, den NI und Agilent möglicherweise undurchdachtes Design zu unterstellen? > ..deutlich gesagt, daß es wochenlang Probleme gab und Keithley und NI den > schwarzen Peter hin und hergeschoben haben ohne daß es vor Ort eine > Lösung gab. Nun, was erwartest du von NI auch anderes? Wenn dein neuer PC nicht geht, weil die Hausverteilung Mist ist, wird das wohl auch nicht der PC-Hersteller richten. Wenn er dir sagt, dass es am Elektriker liegt, ist das wohl alles was man verlangen kann. > Immerhin hat Rudi (so wie auch andere !) seine GPIB-Aufgabe mit diesem > einfachen billigen Ansatz ohne den Monster-Treiber von NI/Agilent lösen > können. Der C-Code scheint verständlich zu sein und so ist anzunehmen, > daß diese Lösung auch noch unter den nächsten Windowsversionen laufen > wird im Gegensatz möglicherweise zu den üblichen teuren > Industrielösungen. Wie lange waren jetzt die letzten Adapter unterstützt? >10 Jahre? Und du weißt natürlich, ohne Tests, dass du dann mit dem Adapter super klarkommen wirst? Was du den NI/ Agilent nicht zugetraut hättest? > Wenn Du aktiv was Positives > beitragen willst zu diesem AVR-Ansatz, dann tue es. Ansonsten lass die > machen, die hier was aufbauen was in der Praxis funktioniert. Joa, du großer Macher. Irgendwie hab ich eher das Gefühl du laberst nur und die, die wirklich was machen, müssen sich damit rumschlagen, dir jede Kleinigkeit zu erklären, die man mit 5 Minuten googeln auch selbst herausfinden könnte. Aber noch eine Frage dazu; bei der NI Lösung hat dich gestört, dass kein Netzteil vorhanden war, jetzt willst du dich mit 200 Ohm Schutzwiderständen zufrieden geben? Ganz ohne Treiber-ICs? Ganz ohne FET-Stufen, die dann z.B. 1A pro I/O Pin liefern können?
> Ich habe nichts gegen einen billigen Chinaadapter, wenn es eine C-Datei > dazu gibt die verständlich einen Zugriff auf dieser unteren > Protokoll-Ebene ermöglicht. Ist das denn der Fall? Gibts dazu etwas? Ich denke, dass man mit Agilent SICL Zugriff auf alle GPIB-Funktionen haben sollte. Das kann man aus C/C++ und Visual Basic verwenden. Das ist aber ziemlich Agilent-Spezifisch, funktioniert also nur mit einem GPIB-Adapter von Agilent. http://www.home.agilent.com/agilent/redirector.jspx?action=ref&cname=AGILENT_EDITORIAL&ckey=1316025&lc=ger&cc=DE&nfr=-11143.0.00&pselect=SR.GENERAL Mit Agilent 488 hat man auch Zugriff auf Low-Level Funktionen, ist kompatibel mit NI. Mit Visa geht das bestimmt auch irgendwie, hab ich aber noch nicht gemacht.
Rob schrieb: > Joa, du großer Macher. Irgendwie hab ich eher das Gefühl du laberst nur Sorry, aber bisher hast Du außer frechem Geschwätz nichts Produktives geliefert. Wird das nun besser werden oder was soll das lange Konvolut, das hier doch niemanden sonst bereichert?
Johannes E. schrieb: > Ich denke, dass man mit Agilent SICL Zugriff auf alle GPIB-Funktionen > haben sollte. Das kann man aus C/C++ und Visual Basic verwenden. Das ist > aber ziemlich Agilent-Spezifisch, funktioniert also nur mit einem > GPIB-Adapter von Agilent. Danke Johannes für die Info. > Mit Agilent 488 hat man auch Zugriff auf Low-Level Funktionen, ist > kompatibel mit NI. was meinst Du mit Agilent 488? > Mit Visa geht das bestimmt auch irgendwie, hab ich aber noch nicht > gemacht. Visa ist diese eine Treiberschicht?
Matthias W. schrieb: > Sorry, aber bisher hast Du außer frechem Geschwätz Und du mit deinem dummen, wodurch sich auch meines hätte vermeiden lassen. Matthias W. schrieb: > Wird das nun besser werden oder was soll das lange Konvolut, > das hier doch niemanden sonst bereichert? Na, ich hab gehofft, du würdest es einfach kapieren und dich zurückhalten, bzw zumindest Google und Hirn einschalten. Matthias W. schrieb: > was meinst Du mit Agilent 488? http://l mgtfy.com/?q=Agilent%20488 Ist das wirklich so verdammt schwer?
Rob schrieb: > Na, ich hab gehofft, du würdest es einfach kapieren und dich > zurückhalten, bzw zumindest Google und Hirn einschalten. ach ja? Ich stell hier absichtlich nur blöde Fragen, die niemand weiterbringen? Leider bin ich halt kein GPIB-Fachmann und daher auch durchaus unwissend an der einen oder anderen Stelle. > http://l mgtfy.com/?q=Agilent%20488 dieser Link hilft mir nicht weiter. Da lande ich dann bei http://www.questscan.com/ Offenbar ist das eine (vermutlich riesige?) Softwarebibliothek. > Ist das wirklich so verdammt schwer? Es ist in der Tat schwer manche Dinge zu verstehen, wenn man 25 Jahre zuvor erlebt hat, daß es mit GPIB gar keine Probleme geben muss, sogar ohne solche Monstertreiber. Warum ist das heute so anders? Darüber mache ich mir meine Gedanken. Manchmal bringt es was nachzudenken was besser gemacht werden könnte, weil das die Basis dafür ist, daß dann auch was besser wird.
> was meinst Du mit Agilent 488? http://www.gidf.de/%22agilent+488%22 > Visa ist diese eine Treiberschicht? So ungefähr, das ist eine herstellerübergreifende, einheitliche API, um Messgeräte über GPIB, Seriell, LAN, ... anzusprechen. Das wird von Agilent und NI und anderen Herstellern unterstützt. Dadurch kann man seine Software sowohl mit einem GPIB-Adapter von Agilent als auch mit einem NI-Adapter verwenden.
http://l mgtfy.com/?q=Agilent%20488 hier muss man ein Leerzeichen entfernen. Dann funktioniert es und hilft dir hoffentlich weiter. Falls du noch kein Lesezeichen zu der Seite hast, würde ich dir dringend eines empfehlen. Da findet man viele nützliche Dinge!
Rob schrieb: > hier muss man ein Leerzeichen entfernen. Dann funktioniert es und hilft > dir hoffentlich weiter. Falls du noch kein Lesezeichen zu der Seite > hast, würde ich dir dringend eines empfehlen. Da findet man viele > nützliche Dinge! Danke Rob.
Es freut mich, dass wieder sachlich miteinander geschrieben wird :-) Grüße, Rudi
David ... schrieb: > Ist hier noch etwas interessantes entstanden? Rudi hat sein Teil am Laufen ! Wäre interessant wer noch so etwas hat . . .
Johannes E. schrieb: >> Visa ist diese eine Treiberschicht? > > > > So ungefähr, das ist eine herstellerübergreifende, einheitliche API, um > > Messgeräte über GPIB, Seriell, LAN, ... anzusprechen. > > Das wird von Agilent und NI und anderen Herstellern unterstützt. > > > > Dadurch kann man seine Software sowohl mit einem GPIB-Adapter von > > Agilent als auch mit einem NI-Adapter verwenden. Visa ist genauso wie SICL eine Treiberschicht, welche eine Kommunikation zwischen Anwendersoftware und IEC-Bus Karte herstellerübergreifend ermöglichen soll. Doch Rohde&Schwarz Dienstprogramme, welche SICL Treiber für die NI-Karte benutzt, wird von Agilent IEC-Buskarten trotzdem nicht verstanden, genauso wie Agilent Dienstprogramme nicht unbedingt von den NI Karten verstanden wird. Es scheint da offenbar doch noch kleine Unterschiede zu geben. SCPI ist übrigens eine mehr oder weniger offener Versuch die Stringbefehle der IEC-Bus Geräte zu standarisieren. Mit mehr oder wenger großen Erfolg. Aber selbst innerhalb Agilent gibt es da Unterschiede. Siehe z.B. HP54602 und HP54645D. Da sind die Kanalbefehle der analogen Eingänge unterschiedlich. Ralph Berres
Thread beobachten
Seitenaufteilung abschaltenBitte 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.