Hallo Leute Ich habe mir seit ein paar Tagen einen GPIB Transceiver der Fa National-Instruments mit der Bezeichnung GPIB120A zugelegt. Da ich mittlerweile mehr als 20 Geräte am IEC-Bus hängen habe und der Bus laut Spezifikationen für maximal 16 Geräte wegen der Treiberleistung ausgelegt ist, habe ich den Bus mit Hilfe des Transceivers in 2 Abschnitte unterteilt. Das Problem was ich habe, ist folgende. Normale Datenübertragung wie Multimeter auslesen oder Gerät einstellen funktioniert ohne Probleme. Wenn ich aber ein größere Datei übertragen will (z.B. Bildschirminhalt auslesen ) oder ich durch anpollen der Geräte feststellen will, welche Geräte sich melden, dauert das ohne Transceiver ein paar Sekunden mit Transceiver mehrere Minuten. Die Fa NI hat kein sonderliches Interesse mir weiter zu helfen, da das Gerät seit 9 Jahren aus dem Support ist. Schaltbilder wollen sie auch keines rausrücken. das sei alles streng geheim. Hat jemand von euch eine Idee, wonach ich suchen sollte, um den Fehler einzugrenzen? Laut Beschreibung ist das Gerät vollständig transparent für jegliche Signale die auf dem Bus abgehen. Es besteht übrigens vollständig aus gefühlte 50 TTL-Ics kein Gal kein Pal kein Prozessor. Ich bin mal gespannt was für Tipps ich hier ernten werde. Ralph Berres
Ralph Berres schrieb: > Ich bin mal gespannt was für Tipps ich hier ernten werde. Lass die NI Gurke einfach weg. Die Treiber werden das auch so schaffen, Zweifel räumt eine Pegelmessung aus. Bei 20 Geräten würde ich mir eher überlegen ob ich zwei separate Busse nehmen kann.
X4U schrieb: > Bei 20 Geräten würde ich mir eher überlegen ob ich zwei separate Busse > nehmen kann. Das habe ich mir auch schon überlegt. Es fallen dann aber jede Menge Anpassungen in meine Programme an, was auch viel Zeit kostet. Ralph Berres
Ralph Berres schrieb: > X4U schrieb: >> Bei 20 Geräten würde ich mir eher überlegen ob ich zwei separate Busse >> nehmen kann. > > Das habe ich mir auch schon überlegt. Es fallen dann aber jede Menge > Anpassungen in meine Programme an, was auch viel Zeit kostet. Womit schreibst du die denn?
ist das was ähnliches wie HP-Basic (nun HT-Basic)?
X4U schrieb: > ist das was ähnliches wie HP-Basic (nun HT-Basic)? Ja Eine Firma hat das übernommen und bietet jetzt als HT-Basic an. Ralph Berres
Ralph Berres schrieb: > X4U schrieb: >> ist das was ähnliches wie HP-Basic (nun HT-Basic)? > > Ja Eine Firma hat das übernommen und bietet jetzt als HT-Basic an. > > Ralph Berres Wenn ich mich recht entsinne ist es relativ einfach die Enter Statements zu ändern. Bei der Gelegenheit kann man es auch gleich vernünftig strukturieren Enter Bus1 .... Enter Bus2 .... Ist aber lange her das ich was damit gemacht habe.
Naja Ich habe sämtliche Geräte in vom Hauptprogramm ausgegliederte Unterprogramme angesiedelt. Ich muss dadurch eine ganze Reihe von Unterprogrammen die Adressen ändern. Und das bei jedem Hauptprogramm. Da kommt schon einiges zusammen. Auch die Verkabelung zu ändern ist nicht so ganz ohne. Das bedeutet viel Räumarbeit. Das ist ein Knochenjob wenn man das alleine macht. Aber eigentlich war das Thema von mir, der IECbusexpander. Vielleicht hat hier ja jemand so ein Gerät im Einsatz und kann mir Tipps geben. Ralph Berres
Mein Problem scheint wohl zu speziell zu sein. Ralph Berres
Du hast Tabelle B-2 im Handbuch gesehen "Performance Characteristics"? Kommt die dort angegebene "Data transfer rate degradation" hin? Kommen die angegebenen "Transfer Rates" hin? Wenn ja, hast du deine Antwort: Ist so, weil ist bei dem Gerät so.
Naja die Zeiten sind bei mir eher Faktor 100 größer als in der Tabelle. Besonders die LED Source Handshake blinkt im 5 Sekundentakt. Ich schätze mal das selbst 1Kbyte/sek Transverrate nicht erreicht wird. Ralph Berres
Folgendes habe ich jetzt rausgefunden. Mein Benchlink-Programm spricht jede IEC-Busadresse mit einen *IDN? an, wartet die Antwort ab und listet die so gefunden Adresse auf. Ohne dem GPIB120A geht das innerhalb 1-2 Sekunden. Mit dem GPIB120A sieht man richtig wie alle 3 Sekunden die LED Source Handshake für einene Zehntel Sekunde ausgeht. Wenn alle Adressen gescannt sind geht sie ganz aus. Ich bin aber noch nicht dahinter gekommen, welcher Schaltkreis für die Verzögerung verantwortlich ist, und wozu diese Verzögerung überhaupt notwendig ist. Vielleicht hat hier jemand eine Idee. Kennt jemand das Gerät zufällig? Folgenden Text habe ich irgendwo auf der NI-Seite noch gefunden. Problem: When I am using a GPIB-120A, I see listeners on every possible GPIB address, which do not actually exist. I see this behavior using Scan for Instruments in Measurement and Automation Explorer, as well as with the FindLstn and ibln commands. How can I properly detect my instruments when using a GPIB-120A? Solution: The GPIB-120A will return all Listeners listed in the FindLstn call, or all possible listeners when used with Scan for Instruments in Measurement & Automation Explorer. This is expected behavior for many GPIB expanders and extenders. If you require the use of Scan for Instruments, FindLstn, or ibln, you may wish to consider using the GPIB-120B or GPIB-140A, which do not exhibit this behavior. Using the GPIB-120A, the best approach is to maintain a list of the known addresses of connected instruments, and perform an identication query to verify their presence on the system. This removes the need to search for listeners on the GPIB bus. Somit scheint das kein Fehler von nur meinem Gerät zu sein, sondern es scheint dieses Gerät generell zu betreffen. Aber was ist der Sinn und Zweck? Hoffen, das ein Gerät nach 3 Sekunden doch noch antwortet? Ich meine 100mS würden auch ausreichen. Ralph Berres
IEC 488 stammt aus einer Zeit, als lokale Intelligenz in Messgeräten noch sehr teuer war. Die damals nötigen Kopfstände wurden dann bis zum Schluß mitgeschleift. Das machte dann auch solche TTL-Gräber nötig wenn es mal an die Grenzen der Specs ging. Die Entwickler solcher Gerätschaften haben dann meißt einen Kompromiss akzeptiert und Die Geräte für eine bestimmte Konstellation gebaut. Wer etwas anderes brauchte hat das selber entwickelt oder sehr viel Geld bezahlt. Was die Sache nicht besser macht ist die Verwendung der alten Programme...
??? schrieb: > IEC 488 stammt aus einer Zeit, als lokale Intelligenz in Messgeräten > noch sehr teuer war. Er wird aber auch heute noch verwendet. OK es gibt zwar immer mehr Geräte die auf TCP-IP oder USB setzen und den IEC-Bus nur noch als Option anbieten, aber es gibt immer noch viele aktuelle Geräte , wie z.B. das HP34401 welche eine RS232 und eine IEC-Bus Schnittstelle besitzen. Selbst nicht mal 10 Jahre alte Signalgeneratoren wie der SML von R&S besitzen nur IEC-Bus und RS232. Nun könnte man argumentieren. Benutze einfach die RS232 Schnittstelle. Aber bei 21 Geräte RS232 ?? Und was macht man mit den Geräten die nur IEC-Bus besitzen? Jetzt könnte man weiter argumentieren, schmeiße die Geräte auf den Müll und kaufe dir neue. Ich glaube selbst Firmen die damit Geld verdienen schrecken davor zurück. Erst recht dann der Hobbyist. Man könnte sich als nächste Alternative für jedes Gerät einen IEC-Bus-USB Adapter zulegen. Bei mindestens 300 Euro ( Nachbau aus China, von dem man nicht weis ob es bei allen befehlen funktioniert ) auch nicht gerade preiswert. Letzte Alternative wohl zweite IEC-Bus Karte die ganze Verkabelung dopplet und Programme umschreiben. Was bei gekauften Dienstprogramme natürlich auch nicht einfach ist. Fakt ist, wenn ich Software und Hardware erneuern wollte, würde ich arm darunter werden. Ralph Berres
Genau das ist das Problem mit IEE488. Es ist zu verbreitet bei den teuren Geräten. Wenn aber neue Software geschrieben werden muss, kann man mit IEE488/GPIB auf USB viele alte Probleme mit neuen Problemen tauschen... Wärend ein funktionierendes IEE488-System eigentlich immer funktioniert kan ein USB basiertes System schonmal unvorhersehbar reagieren. Ich hab das mit genügend Systemen durch... Was aber trotzdem nicht schlecht wäre, den Bus teilen und einen anderen (intelligenten) Koppler benutzen. Eigentlich galt aber immer die Regel ein IEE488-System nicht zu groß werden zu lassen. und was RS232 mit vielen Geräten angeht gibts ja da die 2 Übel Multiportkarten und RS435 ... naja Mikrosoft hatte ja schon vor Jahren öffentlich gezeigt was der Vorteil des ungehemmten ansteckens von USB-Geräten an einen Rechner ist...
??? schrieb: > Wenn aber neue Software geschrieben werden muss, kann > man mit IEE488/GPIB auf USB viele alte Probleme mit neuen Problemen > tauschen... Genau so ist es :-) ??? schrieb: > Wärend ein funktionierendes IEE488-System eigentlich immer funktioniert > kan ein USB basiertes System schonmal unvorhersehbar reagieren. Die IEC-Bus-Schnittstelle hat ein 3 Draht Handshake, welches sicherstellt, das das langsamste momentan adressierte Gerät die Geschwindigkeit bestimmt. Das erhöht die Betriebssicherheit schon irgendwie, kann aber auch schon mal Probleme machen, wenn ein Gerät aus irgendeinen Grund nicht antwortet und den DAV nicht frei gibt. Schon erlebt, bei dem Schnittstellenwandler für den R&S SMLU. Der hatte , wenn das Gerät abgeschaltet hatte , den DAV blockiert. Ich habe einen halben Tag gebraucht, bis ich dahinter kam. Ein Relais in diese Leitung hat das Problem behoben. ??? schrieb: > Was aber trotzdem nicht schlecht > wäre, den Bus teilen und einen anderen (intelligenten) Koppler benutzen. Es gibt einen Nachfolger des GBIB120A, nämlich den GPIB120B. Der soll dieses Problem angeblich nicht haben, weil er mehr Intelligenz hat. Aber irgendwie habe ich keine Lust nur für dieses Experiment mit unbekannten Ausgang über 1000 € zu investieren. ??? schrieb: > Eigentlich galt aber immer die Regel ein IEE488-System nicht zu groß > werden zu lassen Deswegen ja die Übung mit dem GPIB120A. Seltsamerweise läuft der Bus noch recht zuverlässig mit 21 Geräten am Bus. Also weit außerhalb der Spezifikationen. Die Treiber-ICs der einzelnen Geräten ( nicht nur des Controllers ) sind von dem Strom den sie treiben können nur für maximal 15 Geräte ausgelegt. Da bei mir Messgeräte irgendwie jungen , und ich nicht noch mehr Geräte an einen Bus hängen wollte, habe ich mich zu dem GPIB120A entschlossen ( der übrigens nur 30$ aus Amerika gekostet hat. Mit Porto und Zoll waren es dann etwa 100€ ). ??? schrieb: > und was RS232 mit vielen Geräten angeht gibts ja da die 2 Übel > Multiportkarten und RS435 ... Ehrlich gesagt, finde ich die RS232 Schnittstelle ganz schönen Murks. Schon die unzähligen Auswahlmöglichkeiten bei der Konfiguration und der Verdrahtung macht es schwer diesen Anschluss ( Bus ist es ja keiner ) zu verwenden. Auch habe ich keine Lust einen ganzen Bündel RS232 Kabel mit seinen Verwechslungsmöglichkeiten zum PC zu ziehen. Mal abgesehen, das die Geschwindigkeit auch extrem langsam ist. ??? schrieb: > naja Mikrosoft hatte ja schon vor Jahren öffentlich gezeigt was der > Vorteil des ungehemmten ansteckens von USB-Geräten an einen Rechner > ist... Da weist du mehr als ich. Erzähle mal das interessiert mich. Nachdem ich in einem Dienstprogramm eine Möglichkeit gefunden habe die Anzahl der gescannten IEC-Bus Adressen auf das notwendige Maß einzuschränken, kann ich jetzt mit dem Manko leben. Ein Freund von mir hat in einem Forum von NI was gefunden, was genau dieses Problem wiederspiegelt. Es scheinen alle Geräte dieses Types das zu machen, somit kein Defekt meines Gerätes. ( siehe weiter oben ). Ralph
Ralph Berres schrieb: > Ich muss dadurch eine ganze Reihe von > Unterprogrammen die Adressen ändern. Naja, wer kommt denn schon auf so verrückte Ideen, Adressen hart in Programme rein zu kodieren. Sowas übergibt man als Argument, als Variable, als Define, als Umgebungsvariable, im Ini-File usw. Wir nehmen für jedes IEE488-Gerät einen eigenen IEE488/USB-Umsetzer. Dann gibt es keine Konflikte und kein Gerät kann das andere ausbremsen. Und man spart sich die starren teuren Kabel.
Peter Dannegger schrieb: > Naja, wer kommt denn schon auf so verrückte Ideen, Adressen hart in > Programme rein zu kodieren. > Sowas übergibt man als Argument, als Variable, als Define, als > Umgebungsvariable, im Ini-File usw. Naja ich habe so einige gekaufte Dienstprogramme, die müssten alle unkonfiguriert werden. Mein selbstgeschriebenes Programm in Basic ist für jeden Sender ein eigener Treiberprogramme geschrieben, und für jeden Empfänger gleich mehrere Treiberprogramme. Mehre deswegen weil halt noch davon abhängt was gemessen wird. Isgesamt sind es so um die 150 Einträge die ich ändern muss. Peter Dannegger schrieb: > Wir nehmen für jedes IEE488-Gerät einen eigenen IEE488/USB-Umsetzer. > Dann gibt es keine Konflikte und kein Gerät kann das andere ausbremsen. > Und man spart sich die starren teuren Kabel. Bei 21 Geräte ein ziemlich kostspieliges Verfahren. Ralph Berres
Ralph Berres schrieb: > Bei 21 Geräte ein ziemlich kostspieliges Verfahren. Jain. http://www.ebay.de/itm/261397671097 Ich habe zwei Stück bei dem gekauft und kann immer noch nicht hundertprozentig sagen, ob es sich dabei nun um Plagiate handelt oder nicht (falls doch sind diese sehr gut gemacht!). Dazu muss ich sagen, dass ich ein garantiert originales als Verglich zur Verfügung habe (gekauft bei DataTec). Wie dem auch sei, die Dinger funktionieren einwandfrei und sind hervorragend verarbeitet. Solltest Du tatsächlich 21 Stück abnehmen, würde er Dir sicherlich einen entsprechenden Preis machen, wahrscheinlich nicht mehr als vielleicht 70 USD das Stück :-)
Dieses Angebot sieht danach aus , als ist es ein Originalprodukt. Wäre also eine verdammt gute Fälschung. Aber trotzdem kommt hier noch Zoll ( ca 4% ) und Mehrwertsteuer hinzu. Ist aber trotzdem extrem preiswert. Bei den vielen Geräten wäre das bestimmt über 2000 Euro die ich finanzieren müsste. Mal abgesehen von den USB Hubs . Kann Win2000 überhaupt soviel sinnvoll verwalten? Ralph Berres
Ralph Berres schrieb: > Bei den vielen Geräten wäre das bestimmt über 2000 Euro die ich > finanzieren müsste. Mal abgesehen von den USB Hubs . Kann Win2000 > überhaupt soviel sinnvoll verwalten? Der Anbieter behauptet, dass ein USB-GPIB Adapter 14 GPIB-Geräte ansteuern kann. Agilent/Keysigt behauptet das ebenfalls im 82357B User’s Guide. Theoretisch könntest du mit einem dieser Adapter deinen vorhandenen GBPI-Bus in zwei Busse mit 10 bzw. 11 Geräten pro Bus aufteilen.
Jay schrieb: > Theoretisch könntest du mit einem dieser Adapter deinen vorhandenen > GBPI-Bus in zwei Busse mit 10 bzw. 11 Geräten pro Bus aufteilen. Ja klar das würde gehen. Ich kann auch gleich 2 IEC-Bus Karten in den Rechner stecken. Kommt aufs gleiche raus. Nachteil. Da ich ja dann in der Software 2 verschiedene Karten adressieren muss, müssen in sämtliche Software die bei mir vorhanden ist, von jeweils sämtlichen eingesetzten Geräten die IEC-Bus Adresse geändert werden, da in den Softwares die Adresse immer aus Karte und Gerät besteht, z.b. 701 Dabei ist 7 die IEC-Bus Karte im Rechner und 01 in meinen Falle der Oszillograf HP54602B. Eine zweite IEC-Bus Karte würde dann die Adresse z.B. 8 zugewiesen bekommen. Um diese ganzen Softwareänderungen zu umgehen, hatte ich dann nun mal den IEC-Bus Expander GPIB120A bevorzugt. Der IEC-Bus kann bis zu 31 Adressen adressieren, jedoch die Leistung der Bus-Treiber-ICs in jedem Gerät reicht nur für 16 Geräte aus. Das sind 48mA. Ralph Berres
Wenn du jedesmal die Adresse fest bei den Ausgabebefehlen stehen hast ist das natürlich Mist. Besser wäre es, am Anfang des Programms einer Variablen die Adresse zu geben und dann nur noch mit der Variablen arbeiten. Aber da die Adressen ja eindeutig sind, sollte ein "Ersetzen Alle" im Editor auch gehen.
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.