Hallo Leute, Ich möchte/muß ein spezielles Gerät für einen Prüfplatz bauen und soll dieses in den vorhandenen GPIB-Gerätebus miteinbinden. Bevor ich jetzt das Rad wieder neu erfinden muß, wollte ich nachfragen ob schon jemand was mit diesem älteren Bus realisiert hat und Infos bereitstellen kann. Bzw. kennt jemand Seiten zu diesem Thema? Bei Google und hier finde ich zu 99% nur Fragen - aber keine brauchbaren antworten.. :( Kennt zufällig jemand einen leicht beschaffbaren GPIB-Controller, der mit den Bus-Handshake abnimmt? Oder evtl. auch kleine Module? ect.. Für Infos wäre ich sehr dankbar! :) Schöne Grüße, Techniker
..und woher? Farnell, RS, Reichelt, Conrad, Schuricht, Digikey, Spörle haben nichts.. :(
bzw. NAT7210 als ASIC von National Instruments
Oh Gott, derjenige, der Dir diesen Auftrag gegeben hat, ist nicht aus der Steinzeit, sondern noch vor der Entstehung unseres Sonnensytems. Was soll das werden, Controller, Teilnehmer, mit Subadressen, mit parallel Polling, mit SRQ, SCPI-Sprache ? Ich hab mal ein älteres Gerät ersetzen müssen und nen CPLD dafür entwickelt. Da das Gerät mehrere male verkauft wurde und manchmal noch wird, hat es sich gerade so gerechnet. Für ne Einzelanwendung ist sowas aber Unsinn. Peter
Für Prüfplätze ist der GPIB-Bus immer noch Stand der Technik, da alle Profigeräte diese Schnittstelle besitzen.. Ich habe vorgeschalgen es seriell zu machen (wäre am einfachsten) - wurde jedoch abgeschmettert.. :-( -> GPIB-Lösung wird gewünscht. Jep, als Sprache kommt Plain-Text (SCPI) zum einsatz.. ;-)
uPD7210 ist abgekündigt und bei Segor nicht mehr erhältlich. Bei NI ist der NAT7210 aber online bestellbar (allerdings wird die Site gerade gewartet und die betreffende Page ist nicht erreichbar).
Da der NAT7210 pin- und funktionskompatibel mit dem NEC µpD7210 ist, frage ich mich ob schonmal jemand diesen an einem AVR dran hatte? :) Evtl. hat sogar jemand Code hierfür? :) Wäre nett...
Also ich habe im Studium mit altem einfachen Pentium und ISA oder PCI Karte den BUS programmiert. Mit handelsüblichen ANSIC oder in Turbo Pascal. Wenns um eine schnelle Lösung geht würde ich das auch wieder so machen. Als Festplatte eine CF Karte, einfaches Dos oder Linux aufgespielt und dann über die Steckkarte den BUS angesprochen. Gruß Sven
Ich hab mir vor einiger Zeit mal einen Converter USB-GPIB gebaut um damit meinen Ossi auszulesen. Die GPIB-Seite bestand dabei nur aus einem Mega8 und einem (haltet euch fest :-) PCF8574. Letzeres nur weil mir die IO-Pinne ausgegangen waren. Ich denke aber wenn es nicht auf maximale Geschwindigkeit ankommt, und der OP wollte ja sogar RS232 nehmen, dann kann man den Bus auch in Software nachbilden. Es muss ja nicht gerade ein Mega8 sein, es koennte auch ein M16C mit IOs bis zum abwinken, oder vergleichbares von Atmel sein. Ein Controller mit etwas mehr Ram kann aber nicht schaden. Mein Design krankt etwas daran das der Mega8 zuwenig Speicher hat und ich da etwas haeufig kleine Bloecke verschicken muss. Die Infos ueber den Bus habe ich uebrigens aus aelteren Elrad Artikeln und etwas suchen im Internet. Olaf
guck mal hier, evtl. kannst Du was verwenden... http://www.mcselec.com/index.php?option=com_content&task=view&id=67&Itemid=57 Gruß, Holm
Hi! Kann mir bitte jemand dieses Datenblatt runterladen und hier posten? http://www.datasheetarchive.com/datasheet.php?article=3442887 Bei mir kommt nur die Meldung, dass meine IP hier in der Arbeit für heute das Limit erreicht hat.. :-(
@Peter: > Ich hab mal ein älteres Gerät ersetzen müssen und nen CPLD dafür > entwickelt. > Da das Gerät mehrere male verkauft wurde und manchmal noch wird, hat es > sich gerade so gerechnet. Ich tippe mal, dass du da keine Infos dazu rausgibst? :-/ Falls doch, wäre ich dir sehr dankbar! :) (evtl. auch per mail..) Schöne Grüße
Ich habe übrigens gerade ähnliches vor wie du. Habe mir gerade einen gebrauchten HP-Oszi gekauft, der ausschließlich HP-IB als Schnittstellenmodul hat. Damit ich wenigstens paar Screenshots zur Außenwelt geben kann (hardcopy print geht auch über HP-IB), wollte ich einen AVR zur Wandlung auf RS-232 (oder vielleicht auch USB) drankleben. Steuerung des Busses habe ich zwar selbst nicht vor (der Oszi scheint selbst die Steuerung zu übernehmen, wenn er drucken will), scheint mir aber auch nicht so viel aufwändiger zu sein. Peters Vorbehalte gegenüber IEEE488/IEC625 habe ich gelesen (und das nicht wirklich definierte end of transmission handling finde ich auch beknackt), aber mir geht's wie dir, ich habe hier auch keine andere Wahl. Im Prinzip dürfte es keine zu schlimme Herausforderung sein, selbst das handshake mit einem (schnellen) AVR zu erledigen. Die Zeitforder- ungen sind alle aus heutiger Sicht recht moderat. Als Bus-Treiber machen sich 75160 und 75161/75162 ganz gut. Die ersten beiden gibt's bei Reichelt als DIP, den 75162 gibt's bei Segor als SO (und den '160 ebenfalls). Die Teile erledigen die Datenrichtungsumschaltung und den Busabschluss (active termination). Der 75162 kann die REN- und IFC- Leitungen separat in ihrer Richtung steuern und erlaubt damit den Betrieb von mehreren Controllern am Bus. Mal gucken, mein alter russischer Zählfrequenzmesser hat auch noch IEE488, vielleicht mach' ich ja wirklich mal einen Bus draus... Der von Holm genannte Link mit dem RS-232-Wandler kümmert sich übrigens rein gar nicht um die Bussteuerung, sondern erledigt lediglich das Daten-Handshake, also listener und talker sind de facto ständig selektiert dort. Für das Grundverständnis des Busses hat mir das Buch, das in diesem Thread genannt worden ist: Beitrag "GPIB - Programmierung" gut geholfen (aus der Bibliothek). Allerdings sehen die Statusdiagramme der einzelnen Funktionen gemäß Standard fürchterlich kompliziert aus. Je mehr man drüber nachdenkt, um so mehr entkompliziert sich das dann im Kopf. ;-)
Hat den µPD7210 bzw. den NAT7210 schonmal wer mit einem AVR in C angesteuert? Kennt jemand Beispiele hierzu? :-/ Tutorial? Irgendwie raff ich den genauen Kommunikationsablauf nicht ganz.. :(
@Jörg: Danke für deinen langen Beitrag! :) Werd mal auch nach brauchbaren Büchern suchen..
>Hat den µPD7210 bzw. den NAT7210 schonmal wer mit einem AVR in C >angesteuert? Kennt jemand Beispiele hierzu? :-/ Ich habe vor ca. 10 Jahren einen 7210-kompatiblen (Nachfolge-)Baustein mit einem 8085 (MFA-Ausbildungssystem) angesteuert. Wenn ich die Unterlagen noch finde, kann ich sie gerne posten. Inzwischen ist mir eine GPIB-Interface-Platine untergekommen, die das Interface mit einem Z80 und der entsprechenden PIO realisiert. Leider ist die Karte abgeraucht und Unterlagen konnten wir auch nicht (mehr) auftreiben. Die Karte ist laut Aufkleber aus dem Jahre 1985... Die 75160er-Bausteine wurden damals auch verwendet. Ich würde sagen, dass der Z80 von damals mit einem AVR von heute vom Können her vergleichbar ist. Ergo: Man sollte ein langsames Device mit einem AVR realsieren können. Die Busgeschwindigkeit richtet sich eh nach dem langsamsten Gerät.
> Ich würde sagen, dass der Z80 von damals mit einem AVR von heute vom > Können her vergleichbar ist. Naja... der AVR ist grob um Faktor 10 schneller würde ich sagen.
DB1NV Jochen Jirmann hat in den UKW-Berichten 4/1998 und 1/1999 ein "Einfaches universelles IEC-Bus-Interface" veröffentlicht
> DB1NV Jochen Jirmann hat in den UKW-Berichten 4/1998 und 1/1999 ein > "Einfaches universelles IEC-Bus-Interface" veröffentlicht Uiii! :) Hat den Bericht zufällig noch jemand?
Die UKW-Berichte kann man für wenig Geld beim Verlag bekommen.
Die Platine zum IEC-Bus-Interface gibts hier: http://www.ukw-berichte.de/ukw-docs/bau-lit/lp_0399.html DB1NV-IEC 04/98 LP IEC-Bus-Interface Best.-Nr. 06052 23,-€ Die Liste lieferbarer älterer Hefte ist leider im Moment nicht erreichbar: http://www.ukw-berichte.de/ukw-docs/zeitschr/ukw_heft.html
Wurde damals ein 7210 verwendet? Kennt den Artikel jemand? Ist er es wert, ihn zu kaufen? Wieviel kostet der überhaupt? :)
Hallo, Ich habe ein tolles nicht so gebrauch ISA/GPIB Karte. Es hat 4 ICs: PAL 16P8 NAT4882 und... DS75160 DS75162 Direkt am BUS. Ich benutze es nicht. Gruß Ale
Soweit ich noch weiß, war keine Spezialchip verwendet. Ich habe noch eine GPIB-Karte für den Apple II mit 4* MC3448 GPIB-Treiber http://pdf1.alldatasheet.com/datasheet-pdf/view/125977/MOTOROLA/MC3448A.html im 16pin-Gehäuse, dann gab es noch den 24pinner MC3447: http://pdf1.alldatasheet.com/datasheet-pdf/view/125979/MOTOROLA/MC3447P3.html
Jörn Kaipf wrote: > Schau mal bei http://www.emsystech.com/ -> IEEE488/GPIB nach USB > Interface Naja, kostet erstens ,,richtig Geld'', und zweitens wäre da noch die Frage ungeklärt, wie man das mit einem FreeBSD zum Laufen bekommt. Bei einem FT245 oder gar AT90USB1287 wäre mir letzteres im Prinzip zumindest klar. Außerdem ist da schon ein wenig die Bastler-Herausforderung dabei, das ,,bisschen'' mal auf einem AVR selbst zu bauen.
Ich habe den IEC-Bus mit dem Commodore CBM8000 benutzt an diversen HP, Keithley und R&S-Messgeräten. Der hatte einfach die schwachen Portausgänge eines VIA6522 als IEC-Bus herausgeführt, daher durften die Kabel nicht sehr lang sein. http://de.wikipedia.org/wiki/CBM_8000-Serie http://de.wikipedia.org/wiki/IEEE-488
> Der hatte einfach die schwachen Portausgänge eines VIA6522 als IEC-Bus > herausgeführt, daher durften die Kabel nicht sehr lang sein. Genauso hab ich es bei meinem HPIB-USB Converter auch gemacht. Die Datenleitungen haengen direkt am PCF8574, und die Steuerleitungen am AVR. Man braucht keine Bustreiber wenn das Teil direkt am Endgeraet haengt, und das lange Kabel dann erst auf USB-Seite ist. Es ist natuerlich etwas anderes wenn man wirklich einen dicken Bus mit vielen Geraeten stemmen moechte. Und Geschwindigkeit ist auch kein PRoblem, ich muss ja schliesslich erst ein Datenbyte ueber I2C ausgeben. Man kann den Bus ueber Handshake beliebig langsam bekommen. Solange man nur einen Ossiscreen auslesen moechte reicht das aus. Ich hatte uebrigens noch so die Idee, falls ich mal echt Langeweile haben sollte, ein kleines Modul zu basteln das man als Stecker auf den HPIB aufsteckt, auf Knopfdruck den aktuellen Screen ausliesst, eine FFT macht und wieder in den Ossi zurueckschreibt. :-) Hm..oder gleich auf SD-Karte ablegt? Schade das ich gerade noch ein anderes Megaprojekt laufen habe das kein Zeitentzug verkraftet... Olaf
Oder man verwendet den Ossiscreen nur als Sichtgeraet und haengt dort einen Analyzer fuer I2C, SPI oder RS232 dran. Ginge zwar am PC schoener, aber so eine Ausgabe auf Tektronix DSO macht die Messung gleich viel wichtiger. :-D Olaf
Jörg Wunsch wrote: > Naja, kostet erstens ,,richtig Geld'', und zweitens wäre da noch > die Frage ungeklärt, wie man das mit einem FreeBSD zum Laufen > bekommt. Bei einem FT245 oder gar AT90USB1287 wäre mir letzteres > im Prinzip zumindest klar. Muss ein FTDI sein. In der Installationsanleitung für die USB Treiber wird eine ftdibus.sys kopiert.
Die 7210 Controller ICs kann man bei der unten genannten Firma fuer wenig Geld (USD$15) bestellen. http://www.measurementcomputing.com/cbicatalog/cbiproduct.asp?dept%5Fid=107&pf%5Fid=1800&mscssid=1CXLNV1LKAR08N4Q69Q7ESKJ2PUH5RPB Gruss, Gerhard
Description: "The MCC7210.2 is the new standard GPIB controller chip replacing the NEC uPD7210. Like many OEMs facing the phasing out of the NMOS NEC uPD7210, Measurement Computing needed a replacement and needed it to embrace the latest technology, preserve legacy code and circuitry, and be available at a great price. So we designed one from the ground up." IEEE-488.2 (GPIB) Compatibility: "The MCC7210.2 adheres to ANSI/IEEE Standard 488-1978, an update to the IEEE-488.2 specification. The IEEE-488 bus or GPIB (General Purpose Interface Bus) is a standard for instrumentation communication and control for instruments from manufacturers the world over." Gerhard
Olaf wrote: > Ich hatte uebrigens noch so die Idee, falls ich mal echt Langeweile > haben sollte, ein kleines Modul zu basteln das man als Stecker auf > den HPIB aufsteckt, auf Knopfdruck den aktuellen Screen ausliesst, > eine FFT macht und wieder in den Ossi zurueckschreibt. :-) Das wäre in meinem Falle Eulen nach Athen tragen. ;-) Der Modul, der das HP-IB hat, hat auch noch einen ROM drin mit 'ner FFT und ein bissel anderer Mathematik. So kann man auch einen Finger an den Eingang von Kanal 1 klemmen, wählt die Integrationsfunktion aus und bekommt anschaulich dargestellt, dass erstens die Integration die Kurve glättet und zweitens das Integral eines Sinus der Kosinus ist. :)
So ich habe mal den Artikel in den UKW-Berichten nachgeschaut: PIC16C74 (?) in DIL-40, 2*74HCT245, EEProm 93Cirgendwas und MAX232 das ist alles. Es wandelt IEC-Bus auf RS232 und bietet nebenbei noch eine Parallelschnittstelle, das ist alles. Mit Trafo auf einer Europakarte. Im Artikel steht, die c't hätte 12 Jahre zuvor eine IEC-Bus-Karte veröffenticht, aber ich finde im Inhaltsverzeichnis nur welche für den Atari ST: Software in Bildern Grafisches Programmieren mit LabView Martin Klein, Herbert Pichlik Report, Grafische Programmierung, visuelle/grafische Programmierung, G, Virtuelle Instrumente, Gerätesteuerung, Messen/Steuern/Regeln, PC-Meßtechnik, IEEE-/IEC-Bus, LabView 5, National Instruments c't 5/98, S. 230 (kle) Die IEEE-488.2-Norm Standard-Bus mit neuen Features Jürgen Kappus Know-how, IEC-Bus, GPIB, HPIB, IEEE 488.1, 488.2 c't 11/92, S. 283 (un) Extra-Bus IEC-625/IEEE-488-Bus für Atari Mega ST Siegfried Schmidt Prüfstand, MIDI-, Centronics-, RS-232-Schnittstelle, Mega 488 ST c't 12/89, S. 84 (cm) IEC-Bus - im Labor bewährt Rolf Keller, Helmut Hurling Kartei c't 9/87, S. 187 IEC-Bus am Atari ST Preisgünstige Software-Lösung unter RTOS-UH/PEARL Siegfried Schmidt Programm, Atari, IEC-Schnittstelle c't 7/87, S. 132 Meßplatzkontrolle mit Atari ST IEC-Bus-Interface Carl-Marcus Weitz Prüfstand c't 5/87, S. 48 Konferenzschaltung für den C64 IEC-Bus-Karte nach IEEE-488 - Teil 2: Treibersoftware Klaus Mandelatz, Alfred Lappessen Projekt, Commodore c't 8/85, S. 108 (ja) siehe 10/85, S. 11 Konferenzschaltung für den C64 IEC-Bus-Karte nach IEEE-488 - Teil 1: Eintrittskarte Klaus Mandelatz Projekt, Commodore c't 7/85, S. 74 (ja) Konferenzschaltung Der IEC-Bus Rolf Keller Grundlagen, Schnittstellen c't 2/84, S. 79
@Der Techniker, die Frage, die man zuerst klären sollte: Willst Du in einem bestehenden System ein weiteres IEEE-Gerät einbinden oder willst Du der Master für eine Reihe von alten Geräten sein ? Ein IEEE-Gerät kannst Du nicht mit einem MC simulieren, da es auf Befehl (ATN) des Masters sämtliche Signale umschalten muß und so schnell ist kein MC. Du brauchst also auf alle Fälle einen Controller (NEC7210, TMS9914) und die Bustreiber (75160+75161). Den Code für meinen CPLD-Controller kann ich nicht herausgeben, ist mit nem XCR3128 gemacht, unterstützt kein parallel Polling. Als Master kannst Du aber einen MC benutzen und das Handshake in Software machen, brauchst dann nur noch die Bustreiber. Peter
In der Elrad gab es mal das E.M.M.A.-Projekt ("Einplatinen Mikrocomputer mit Midi-Anschluß" oder so ähnlich). Da gab es dann auch eine IEC625-Erweiterung. Wieso liegt das Zeug (Hefte, Kopien, Ausdrucke...) eigentlich immer ganz unten in Umzugskartons, die ganz hinten stehen?
Peter Dannegger wrote: > Ein IEEE-Gerät kannst Du nicht mit einem MC simulieren, da es auf Befehl > (ATN) des Masters sämtliche Signale umschalten muß und so schnell ist > kein MC. Die Datenrichtungsumschaltung macht der 75161/162 doch selbst (auch in Abhängigkeit von ATN). Das Handshake-Signal wollte ich getrickst verdrahten: auf ein NDAV hin muss sofort das NRFD aktiviert werden. Ich dachte dabei daran, das NDAV auf den externen Takteingang eines Zählers zu legen und den mit der negativen Flanke zählen lassen. Der Zähler steht auf 0, das OCR auf 1 und die Steuerung wird so gebaut, dass ein OCR von 1 zu einem Umschalten des entsprechenden OC-Ausgangs nach 0 führt. Den nimmt man dann als NRFD. Via Interrupt oder Polling hat man dann genug Zeit, das Byte abzuholen und zu bestätigen.
>>Ein IEEE-Gerät kannst Du nicht mit einem MC simulieren Geht wohl, läuft bei uns zwar mit 1MHZ, aber ein 16 MHZ µC würde auch 8 MHz packen. @ Techniker: http://de.wikipedia.org/wiki/IEEE-488 Da sind paar Links, wobei ich dir deutsche Literatur ab dem Jahre 1980 empfehlen kann, such nach IEC BUS. Und umsetzen kannst du das ganze auf einem Atmega.
Eine gute Beschreibung der Schnittstelle mit dem 68488 gibt's auch in dem Buch 'Halbleiter-Schaltungstechnik' von U. Tietze und Ch. Schenk, ISBN 3-540-12488-8 und ISBN 0-387-12488-8. Da sind auch noch viele ander sehr gut beschriebene Analog- und. Digitalschaltungen beschrieben. Ich weiß nicht ob's das Teil noch gibt, ist von 1983 (Springer-Verlag). Falls Interesse besteht würde ich den Artikel über die GPIB-Schnittstelle einscannen und diverse Rechte verletzen. ;)
@Peter: Der Master ist ein Industrie-PC mit Labview-Proggi. Ich muß ein Gerät bauen, das am GPIB dranhängt. Das "einzige" Problem ist die GPIB-Schnittstelle.. :( Verwenden würde ich gerne einen NAT9914 von NI incl. den genannten Treibern. Was ich noch bräuchte ist etwas Beispiel-Code oder eine hinreichend gute Anleitung wie die Kommunikation im Detail abzulaufen hat.. :-/ Bzw. welche Zustände ich alles abzufangen habe.. PS: Danke an alle für die rege Beteiligung! :)
Vielleicht hilft dir das weiter. Ist ein schönes Ablaufdiagramm drin.
Jörg Wunsch wrote: > Die Datenrichtungsumschaltung macht der 75161/162 doch selbst (auch in > Abhängigkeit von ATN). Genau, aus Eingängen werden Ausgänge und umgekehrt. Zum Bus hin ist alles paletti, aber zum MC hin gibts erstmal lustige Datenkämpfe und floatende Pins, bis dann endlich der MC den ATN-Change-Interrupt ausgeführt hat. Man könnte tricksen, indem man in jede Leitung zum MC etwa 220 Ohm in Reihe legt, damit die Datenkämpfe nicht gar so brutal sind. Und die floatenden Eingänge sind nicht so schlimm, die 75160/161 gibts ja nicht in CMOS. Genau aus diesem Grund war meine Entscheidung für einen CPLD erfolgt, der hat ja Tristate-Terme. Peter
Peter Dannegger wrote: > Zum Bus hin ist alles paletti, aber zum MC hin gibts erstmal lustige > Datenkämpfe und floatende Pins, bis dann endlich der MC den > ATN-Change-Interrupt ausgeführt hat. Moment mal, während das Gerät talker ist (nur dann muss es ja die Ausgänge treiben) sollte doch bitte der controller nicht anfangen, ATN zu aktivieren, oder? > Man könnte tricksen, indem man in jede Leitung zum MC etwa 220 Ohm > in Reihe legt, damit die Datenkämpfe nicht gar so brutal sind. Ja, sicher 'ne gute Idee. Eine Alternative käme mir noch in den Sinn: während das Gerät als talker die Leitungen treibt, führt ein aktiviertes ATN zum sofortigen Reset des MC. Damit sind dessen Ausgänge auch schlagartig inaktiv. Nach dem Reboot merkt er, dass ATN aktiv ist und hört erstmal auf seinen Meister. > Und die floatenden Eingänge sind nicht so schlimm, die 75160/161 > gibts ja nicht in CMOS. Pull-ups in den AVR-Eingang. Oder gleich externe Pull-ups dran. > Genau aus diesem Grund war meine Entscheidung für einen CPLD > erfolgt, der hat ja Tristate-Terme. Ist mir hier einfach zu aufwändig, ich möchte gern mit dem AVR auskommen. Ist ja auch nur 'n Einzelgerät.
"Moment mal, während das Gerät talker ist (nur dann muss es ja die Ausgänge treiben) sollte doch bitte der controller nicht anfangen, ATN zu aktivieren, oder?" Der Controller darf jederzeit ATN aktivieren. Zwangsläufig muß der Controller ja auch garnicht Listener zum aktivierten Talker sein. Im Hobbybereich mag eine spartanische Lösung hier und dort gut funktionieren; professionelle Lösungen bekommt man nur mit speziellen Controllern/FPGAs.
Gast wrote: > Der Controller darf jederzeit ATN aktivieren. Zwangsläufig muß der > Controller ja auch garnicht Listener zum aktivierten Talker sein. Das ist klar. Aber einen laufenden Transfer abzuwürgen, ist ja wohl eher kontraproduktiv. > Im Hobbybereich mag eine spartanische Lösung hier und dort gut > funktionieren; professionelle Lösungen bekommt man nur mit > speziellen Controllern/FPGAs. Absolutismen stimmen nie. ;-) Dass man sie ab einer bestimmten Stückzahl damit kostengünstiger bekommt, ist 'ne andere Frage. Außerdem heißt ,professionell' lediglich, dass man damit seinen Lebensunterhalt bestreitet... Eine Qualitätsaussage verbindet sich damit kaum.
Weiß zufällig jemand eine Quelle für GPIB-Einbaubuchsen? (..also diese Centronics-Buchsen nur ohne Hebel und dafür mit Schraubbolzen, wie Sie an prof. Messmitteln vorhanden sind..) Das ganze soll keine Bastel-Lösung werden und darf deshalb etwas kosten.. ;-) Benötigt werden vorerst ca. 30-50 Stück
Ja, diesen ganzen IEEE-Krams gibts nur für Mondpreise zu kaufen. Allein diese M3,5 Sechskantbolzen kriegt man kaum unter 5€ pro Stück (und man braucht 2 davon). Die Einbaubuchsen kosten etwa 20€. Und ein 1m kurzes IEEE-Kabel gibts schon für schlappe 100€. Für ein Gerät mit zusätzlichem USB-Anschluß darf man höchstens 10€ Aufpreis verlangen. Für ein Gerät mit zusätzlichem IEEE-Anschluß dürfen es aber schonmal 500€ mehr sein. Irgendwie scheinen die magischen Buchstaben IEEE bei einigen Menschen jegliches kaufmännische Denken total abzuschalten. Peter
Stimmt schon mit den Apothekenpreisen! Wir haben einen USB-GPIB-Adapter von NI, schlappe 700€, die PCMCIA-Karte 900€ und das Passende Kabel nochmal 180€. Au weia! Aber zum Thema Einbaubuchsen: haste bei RSonline schon geguckt? http://www.rsonline.de/cgi-bin/bv/rswww/searchBrowseAction.do?D=ieee488&Nr=AND%28avl%3ade%2csearchDiscon_de%3aN%29&Ntk=I18NAll&Nty=1&Ntt=ieee488&Dx=mode%20matchpartial&Ntx=mode%20matchpartial&N=0&No=25&name=SiteStandard&obs=sObs&callingPage=/jsp/search/search.jsp&BV_SessionID=@@@@0684907854.1184220908@@@@&BV_EngineID=ccdkaddlgkjmfjhcefeceeldgkidhgf.0&cacheID=denetscape
>Wir haben einen USB-GPIB-Adapter von NI, schlappe 700€,
Quancom 250Euro - Soll auch funktionieren.
Der Techniker wrote: > Weiß zufällig jemand eine Quelle für GPIB-Einbaubuchsen? > > (..also diese Centronics-Buchsen nur ohne Hebel und dafür mit > Schraubbolzen, wie Sie an prof. Messmitteln vorhanden sind..) Wie Peter schon schrieb, dürfte das einzige Problem die Beschaffung der M3,5-Bolzen sein. Den Klemmbügel kannste ja einfach rausnehmen (meist fällt er ja sowieso von allein raus ;-).
@Thilo: Kannst du mir die RS-Nummer nennen, da der Link nicht funktioniert? @Jörg: Den Bügel einfach rausnehmen reicht nicht ganz, da dann noch diese hässlichen Halter für den Bügel da sind. Zudem kann man die - schwer erhältlichen - Bolzen nicht so gut montieren.. :( Schei.... IEEE488-Bus! :( ;)
OK, hier die RS-Nummern: 239-1162 (Clips entfernen und Bolzen einschrauben) oder 163-1009.
Bin da kürzlich über einen Link gestolpert: http://lpvo.fe.uni-lj.si/gpib/ Ist ein Projekt (open source) der Uni in Ljubljana(Slowenien). Es handelt sich um eine USB-GPIB Umsetzung auf Basis FTDI FT245BM (BL geht auch) und Atmel 90S8515 oder Mega8515 mit DS75160 und 75161. Also alles was man braucht. Schaltplan und Software ist komplett dabei, wird wohl mein nächstes Projekt! Wer mag kann das auch komplett da fix und fertig für etwa 170 Euronen bestellen.
Aus Zeitmangel und weil es keine so hohe Prio hat, war das Projekt bis jetzt auf Eis gelegt. Mittlerweile ist die Demo-Leiterplatte mit einem NAT9914BPQ, einem ATmega128, einem Grafikdisplay und ein paar Tastern fertig bestückt und liegt vor mir.. ;) Hab als erstes mal die Test-Routinen zur Kommunikation mit dem NAT9914 von NI genommen und an den GCC angepasst. Zur meinem großem Erstauen funktionierte die Kommunikation auf anhieb! :-D Als nächstes würde ich gerne mal ein paar Bytes von LabView über IEEE an mein Board senden und dies als Rohdaten am Display ausgeben.. Nun ist als erstes Datenblatt-wälzen angesagt, welche Register ich vom NAT wie setzen muß, dass ich Daten empfangen kann.. :-/ Deshalb meine Frage, um mir evtl. etwas Arbeit zu ersparen: Hat jemand eine Quelle für ein bischen Demo-Code, wie ich mit dem NAT mit der Aussenwelt kommunizieren kann..?!? :) Schöne Grüße, Techniker
@Techniker: Darf man mal ein Bild vom Aufbau sehen ?
@Sven: ..wenn du mir eine Quelle für Demo-Code nennen kannst, dann zeig ich dir die Fotos ;) g
@Techniker: Das sieht aber schon sehr fein aus. Ich habe leider keinen fertigen Atmel code aber in einer pdf sind einige Ansteuerroutinen am Ende in C: http://www.physics.brocku.ca/~edik/gpib/AN110.pdf Vielleicht hilft Dir das ja und Du kanntest die noch nicht.... Gruß Sven
@Sven: Genau dass sind die NI-Testroutinen incl. die Lektüre, die ich durchkauen müsste.. ;) Deshalb eine Frage: gibts die schon irgendwo fertig? :o) Gruß, Techniker
@Sven: Uuuppssss... schäm Ich hab wohl Tomaten auf den Augen. In der Doku weiter unten nach den Testroutinen ist ja ein Demo-Code zur Kommunikation mit der Aussenwelt. :o) Werd den mal an den GCC und meine Programmstruktur anpassen und weitertesten.. :) Danke für den Hinweis.. PS: Hätt da noch'ne Frage: Überall lese ich von 'Triggern'.. Was ist denn damit beim IEEE-Bus gemeint? Gruß, Techniker
Dirk wrote: > Bin da kürzlich über einen Link gestolpert: > > http://lpvo.fe.uni-lj.si/gpib/ Ich habe das Ding, so wie es dort beschrieben ist heute fertig bekommen. Kosten ca. 60 Euro incl. Platinenfertigung aber ohne Gehäuse. Platinendaten (Gerber + Protel-Files liegen bei). Und was soll ich sagen, es funktioniert. Mein Tischmultimeter spricht mit meinem PC :-) Aber den Sourcecode darf man sich nicht ansehen. Brrr.. schüttel! Für eine Uni..... naja. Werde mich jetzt trotzdem artig bei denen bedanken. Aber geschenktem Gaul..... Also wer Lust hat, dass Ding scheint zu funktionieren. Hajo
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.