Hier ein Screenshot meines "Corona-Programmes" und eine erste Version zum Herunterladen. Sehr erstaunlich finde ich es dass man mit diesen aus heutiger Sicht lahmen Geräten (deren Design immerhin so gut 30 Jahre alt ist) sogar recht lebendige Echtzeit-Wiedergabe auf den Bildschirm zaubern kann, und das über die altehrwürdige GPIB- Schnittstelle deren Daten auf USB umgesetzt werden. HP hat damals hervorragende Arbeit geleistet. Ich habe das Programm mal HP859x genannt da ich aus Mangel an einer Vielzahl von Geräten nicht weiss wie vielseitig und homogen die GPIB-Kommandos in den verschiedenen Spektrum- Analyzern implementiert sind. Für HP8594E, HP8595E, HP8596E wird es auf jeden Fall funktionieren. Bleibt zu hoffen dass noch ein paar HP Spektrum-Analysatoren mehr damit bespielt werden können. Wer es sinnvoll benutzen will braucht ein GPIB-USB Interface von National Instruments. Eventuell tut es auch eine GPIB- Einsteckkarte dieses Herstellers (kann ich nicht überprüfen) da NI sich mit den Interfaces nicht leicht gemacht hat alles kompatibel zu halten. Was man dafür nicht braucht ist diese Gigabyte-Sammlung an VISA-Software. Das nackte GPIB-USB Interface und der Treiber dazu genügen. Zum Installieren einfach das Archiv entpacken und die Installations-Exe starten. Es handelt sich um eine 32 Bit Applikation mit Labwindows CVI Runtime Environment. Ob das unter Win10 auch funktioniert überlasse ich euerer Experimentierfreudigkeit. Spezielle Anforderungen braucht es jedenfalls nicht. Programm folgt im nächsten Beitrag.
Angehängte Dateien:
-
HP859x_Windows.png
12 KB
Hier nun das Installationsprogramm im Zip-Archiv. Bedienungsanleitung gibt es keine, ihr müsst selbst zurechtkommen ;-)
Kein FA schrieb: > Ich habe das Programm mal HP859x genannt da ich aus Mangel an > einer Vielzahl von Geräten nicht weiss wie vielseitig und > homogen die GPIB-Kommandos in den verschiedenen Spektrum- > Analyzern implementiert sind. Für HP8594E, HP8595E, HP8596E > wird es auf jeden Fall funktionieren. Bleibt zu hoffen dass > noch ein paar HP Spektrum-Analysatoren mehr damit bespielt > werden können. welche IEEE488 Befehle hast du zur Steuerung des Spektrumanalyzers benutzt? Wie hast du die IEEE488 Schnittstelle eingebunden? Hintergrund ist, ich habe verschiedene Geräte von HP ( HP3562 und HP8752 ) IECbus karte ist bei mir HP82341C, welches in Verbindung mit der Connekt suite von HP die Schnittstellen Visa und SICL zur Verfügung stellt. Ralph Berres
Ralph B. schrieb: > Kein FA schrieb: > Ich habe das Programm mal HP859x genannt da ich aus Mangel an > einer Vielzahl von Geräten nicht weiss wie vielseitig und > homogen die GPIB-Kommandos in den verschiedenen Spektrum- > Analyzern implementiert sind. Für HP8594E, HP8595E, HP8596E > wird es auf jeden Fall funktionieren. Bleibt zu hoffen dass > noch ein paar HP Spektrum-Analysatoren mehr damit bespielt > werden können. > > welche IEEE488 Befehle hast du zur Steuerung des Spektrumanalyzers > benutzt? > > Wie hast du die IEEE488 Schnittstelle eingebunden? > > Hintergrund ist, ich habe verschiedene Geräte von HP > ( HP3562 und HP8752 ) > IECbus karte ist bei mir HP82341C, welches in Verbindung mit der Connekt > suite von HP die Schnittstellen Visa und SICL zur Verfügung stellt. > > Ralph Berres Wenn er den "Corona"-Source gepostet hätte, müsstest du nicht fragen, sondern könntest rein schauen. Frag ihn doch mal ganz lieb ob er den sourcecode rausrückt...
Hier gibt es ein ähnliches Projekt aus Österreich https://www.oevsv.at/export/oevsv/technik-folder/oe5_vm/bin/HPIB_GPIB_IEEE488_Schnittstelle_V02.pdf. "Das 3. Projekt: Übertragen der Messungen des Spectrumanalysators HP-8559A bzw. HP-8569A an den PC"
Hinweis: Die Leiste oben, zappelt beim Schreiben auf dem Smartphone immer wieder in das Bild. Kann mich erinnern dass andere Nutzer es auch schon bemängelt haben. Interessiert anscheinend den Administrator (Inhaber) offenbar einen Shissdreck...
Diese Leiste stört auch bei Conrad, wenn man einen Screenshot mit dem Firefox-Plugin "Fireshot" macht. Ständig ist die irgendwo quer über das Bild eingeblendet. Der HP-8559A/8569A ist allerdings noch älter, etwa 1982 und der eigentliche Spek aus Mitte der 70er. Das konnte über HPIB immerhin zwei Textzeilen auf dem Schirm eintragen und natürlich die beiden Traces als Pixel auslesen.
:
Bearbeitet durch User
Ralph B. schrieb: > welche IEEE488 Befehle hast du zur Steuerung des Spektrumanalyzers > benutzt? Ganz normale wie sie in jedem Programmierhandbuch zu GPIB nachzulesen sind. Ralph B. schrieb: > Wie hast du die IEEE488 Schnittstelle eingebunden? Das Labwindows CVI Runtime Environment bietet eine gpib.lib welche sich eine oder mehrere GPIB Schnittstellen (wenn vorhanden) sucht.
Kein FA schrieb: > Ralph B. schrieb: >> welche IEEE488 Befehle hast du zur Steuerung des Spektrumanalyzers >> benutzt? > > Ganz normale wie sie in jedem Programmierhandbuch zu GPIB > nachzulesen sind. > > Ralph B. schrieb: >> Wie hast du die IEEE488 Schnittstelle eingebunden? > > Das Labwindows CVI Runtime Environment bietet eine gpib.lib > welche sich eine oder mehrere GPIB Schnittstellen (wenn > vorhanden) sucht. Sag doch einfach dass du deinen Code nicht teilen willst! Das spart dir unnötige Zeichen auf der Tastatur einzutippen...
Kein FA schrieb: > Ganz normale wie sie in jedem Programmierhandbuch zu GPIB > nachzulesen sind. das heist ich kann in deinen Programm die IECbusbefehle, welche mein Gerät versteht einbinden? Ansonsten beantwortet das nicht meine Frage. woher weis ich ob die von dir benutzen IECbus Befehle von meinen Geräten auch verstanden werden? Es sind sich ja nicht mal der HP8752 und der HP3562 einig, was die Plotbefehle zum Ausdrucken des Bildschirminhaltes betrifft. Kein FA schrieb: > Das Labwindows CVI Runtime Environment bietet eine gpib.lib > welche sich eine oder mehrere GPIB Schnittstellen (wenn > vorhanden) sucht. Aha du verwendest also eine Labwindows Entwicklungsumgebung , mit der du ein Runtimeprogramm erzeugt hast. Diese setzt vermutlich eine National Instrumentskarte voraus, um dein Programm verwenden zu können? Verstehe mich bitte nicht falsch. Aber ehe ich dein Programm runterlade und auf meinen Messgeräterechner ( win2000 ) installiere, möchte ich doch wenigstens vorher abschätzen können, ob es erfolgsversprechend ist. Nicht erfolgversprechend ist es schon, wenn sich deine benutzten IEC-Bus Befehle von meinen erforderlichen unterscheiden, da man diese vermutlich nicht in der Runtimeversion ändern kann. Oszi50 schrieb: > Sag doch einfach dass du deinen Code nicht teilen willst! Das spart dir > unnötige Zeichen auf der Tastatur einzutippen... Er kann es nicht so einfach teilen, weil dafür die Entwicklungsumgebung des Labwindows von National Instruments benötigt wird. Diese kostet immerhin 1500 € plus Märchensteuer. Ralph Berres
:
Bearbeitet durch User
Das würde mich auch interessieren, welche Befehle da verwendet wurden. Ich wollte dasselbe (eine Art Echtzeitanzeige) als Qt-Programm für Windows und Linux schon mal machen für die Prologix-Adapter. Mich hat aber immer genervt, dass beim HP 8568B und 8566A beim Ausleswn der Trace immer ein kleiner Delay bestand, und das Programm so sehr langsam reagierte.
Ralph B. schrieb: > Ansonsten beantwortet das nicht meine Frage. Ich habe deine Frage beantwortet. Ich werde allerdings nicht mein Programm durchforsten nach einer Liste von GPIB Kommandos die ich verwende. Ralph B. schrieb: > Verstehe mich bitte nicht falsch. Verstehe mich bitte nicht falsch. Aber du kannst mit dem Programm machen was du willst. Ich bin hier nicht in einer Bringschuld, obwohl das hier von so manchem Leser so gesehen wird. Erfreue dich an dieser kleinen Gabe oder mach irgendetwas anderes was nicht mit diesem Thread zu tun hat. Ralph B. schrieb: > Aber ehe ich dein Programm runterlade > und auf meinen Messgeräterechner ( win2000 ) installiere Das klingt nach einer Monster-Aufgabe die du zu bewältigen hast. Dann lass es lieber sein.
Kein FA schrieb: > Erfreue > dich an dieser kleinen Gabe oder mach irgendetwas anderes was > nicht mit diesem Thread zu tun hat. Kein FA schrieb: > Das klingt nach einer Monster-Aufgabe die du zu bewältigen hast. > Dann lass es lieber sein. Ziemlich arrogant deine Antwort. Ralph Berres
/FA != FA (Ergänzungsmenge), egal. Der 8568/66 ist auch schon älter, 1978/1980 http://hpmemoryproject.org/technics/bench/8568/bench_8568_home.htm und für längere Benutzung, z.B. um Harmonische abzulesen, brauchte man eine Schutzbrille, der Lüfter bläst durch die Tastatur genau in die Augen.
Christoph db1uq K. schrieb: > /FA != FA (Ergänzungsmenge), egal. was heisst das? Christoph db1uq K. schrieb: > Der 8568/66 ist auch schon älter, 1978/1980 > http://hpmemoryproject.org/technics/bench/8568/bench_8568_home.htm ich glaube den 8566 gab es noch ziemlich lange, denn der wurde sogar noch unter Agilent verkauft. Habe mal einen Werbeprospekt von Agilent für den 8566 gesehen. Jahrzahl wüsste ich aber nicht. > und für längere Benutzung, z.B. um Harmonische abzulesen, brauchte man > eine Schutzbrille, der Lüfter bläst durch die Tastatur genau in die > Augen. jup, grade jetzt im Frühling optimal für Allergiker - die sonst schon tränenden Augen werden bis zur Bindehautentzündung gereizt xD
Ralph ist auch Funkamateur und damit definitionsgemäß kein Nicht-Funkamateur. Die Schnittmenge ist daher leer. Laut der Seite wurde 1985 ein Update auf die B-Version gemacht. Nachdem die Kollegen damals sich beklagt hatten habe ich eine Plexiglasscheibe vor die Tasten gehängt, war aber etwas umständlich.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Laut der Seite wurde 1985 ein Update auf die B-Version gemacht. Nachdem > die Kollegen damals sich beklagt hatten habe ich eine Plexiglasscheibe > vor die Tasten gehängt, war aber etwas umständlich. das kann ich mir vorstellen. Die Lüfter der alten HP Geräte sind allgemein ein Problem. Mein 8341A Sweeper hat einen ca. 20cm Lüfter. Ohne Witz, das klingt wie ein Düsentriebwerk und man hört richtig die Luft durch rauschen. Ziemlich üble Sache :-) aber das war jetzt ein bisschen OT. Asche über mein Haupt!
Angehängte Dateien:
-
HP853A_GPIB.png
180 KB
In einem Awacs-Flugzeug ist der Lärm vermutlich egal, aber im Labor stört das sehr. Für meinen HP8558 will ich auch mal was schreiben, einen Raspi als GPIB-Controller mit Python sollte ich noch hinbekommen. Die möglichen Befehle sind ziemlich übersichtlich. Die Plot-Taste würde ich nicht auswerten. Man bekommt nacheinander 481 Y-Werte der Kurve und nochmal soviele für die zweite. Die könnte man sogar in HPGL oder SVG als Vektorgrafik ausgeben, dann sieht der Ausdruck vielleicht eleganter aus.
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Die Plot-Taste würde ich nicht > auswerten. Man bekommt nacheinander 481 Y-Werte der Kurve und nochmal > soviele für die zweite. Die könnte man sogar in HPGL oder SVG als > Vektorgrafik ausgeben, dann sieht der Ausdruck vielleicht eleganter aus. Das Problem mit der Plot-Taste oder Ausgabe als HPGL ist halt, dass man nur die Graphik hat, und nicht die Rohdaten. Die möchte man aber unter Umständen haben, damit man a) selber einen hübscheren Plot machen kann (z.B. mit anderen Daten noch im selben Diagramm oder ähnliches) b) irgend eine Auswertungsroutine noch laufen lassen möchte (z.B. irgend einen Fit oder dergleichen). Es gibt von John Miles KE5FX das GPIB Toolkit, womit man diese Typen von Spekis auswerten kann. Unter anderem ist auch eine Wasserfalldarstellung inbegriffen. Was mich daran interessiert: das funktioniert mit meinem 8566B rasend schnell, die Plots werden wirklich hübsch schnell dargestellt, obwohl da ziemlich viele Datenpunkte übertragen werden. Ich habe bis heute nicht begriffen, wie genau er es macht, dass das so gut funktioniert. Ich habe es nie hin gekriegt, dass die GPIB-Schnittstelle mit meinem eigenen Code so gute Performance hat. Und dabei nutzt John ja auch die Prologix-Dinger. (Sonst hätte ich das bei mir gar nicht laufen lassen können, da Agilent- und NI-Adapter im Preis-/Leistungsverhältnis ausserhalb meines Budgets liegen). Weisst du Christoph vielleicht, obs irgend einen speziellen Mode gibt, wo man die Daten schnell übertragen kann? Tobias
http://www.ke5fx.com/gpib/readme.htm Da war einer sehr fleißig. Mein alter Spek liefert praktisch nur die Kurve. Wenn ich eine genauere Frequenz wissen möchte, muss ich einen Frequenzzähler am herausgeführten YIG-Ausgang anschließen. Der ist einfach freischwingend, die angezeigte Frequenz ist nur ein Digitalvoltmeter der YIG-Spannung, die man selbst an einem kleinen Trimmer auf der Frontplatte auf Null drehen muss.
Tobias P. schrieb: > Es gibt von John Miles KE5FX das GPIB Toolkit, womit man diese Typen von > Spekis auswerten kann. Unter anderem ist auch eine Wasserfalldarstellung > inbegriffen. Was mich daran interessiert: das funktioniert mit meinem > 8566B rasend schnell, die Plots werden wirklich hübsch schnell > dargestellt, obwohl da ziemlich viele Datenpunkte übertragen werden. Ich > habe bis heute nicht begriffen, wie genau er es macht, dass das so gut > funktioniert. Bei dem John Miles sein Programmpaket, wird die Prologix Schnittstelle als Listner/ Talker und der Spektrumanalyzer als Controller eingestellt. Ausgelöst wird das Plotten dann durch Betätigung der Plottaste am Spektrumanalyzer. Vorher muss aber das Plotprogramm 7475 Empfangsbereit geschaltet werden. Das ist hinderlich, wenn man viele Geräte am IECbus hat. Man muss dann jedesmal die IECbusschnittstelle abwechselnd als Listner/ Talker oder als Controller konfigurieren, je nach dem was man auf dem IECbus machen will. Das ganze nur vom Rechner aus zu steuern war nicht vorgesehen. Ralph Berres
:
Bearbeitet durch User
Ralph B. schrieb: > Bei dem John Miles sein Programmpaket, wird die Prologix Schnittestelle > als Listner/ Talker und den Spektrumanalyzer als Controller eingestellt. das ist nicht ganz korrekt. Zwar kann man mit 7470.exe das machen, was du beschreibst, aber dann gibt es noch das "Spectrum Surveillance" tool, welches die Rohdaten vom Spekki runterlädt und wo man keine Plottasten betätigen muss. Das spricht den Analyzer normal über dessen GPIB-Adresse als Device an.
Tobias P. schrieb: > Ralph B. schrieb: >> Bei dem John Miles sein Programmpaket, wird die Prologix Schnittestelle >> als Listner/ Talker und den Spektrumanalyzer als Controller eingestellt. > > das ist nicht ganz korrekt. Zwar kann man mit 7470.exe das machen, was > du beschreibst, aber dann gibt es noch das "Spectrum Surveillance" tool, > welches die Rohdaten vom Spekki runterlädt und wo man keine Plottasten > betätigen muss. Das spricht den Analyzer normal über dessen GPIB-Adresse > als Device an. das habe ich nicht gewust. Ich kann es aber auch nicht mehr ausprobieren, da ich den geliehenen Prologix Schnittstelle wieder zurück gegeben habe. Auser dem Plotprogramm 7475 verwende ich nichts mehr von dem John Miles. Ralph Berres
Ralph B. schrieb: > Ich kann es aber auch nicht mehr ausprobieren, da ich den geliehenen > Prologix Schnittstelle wieder zurück gegeben habe. die sind ja neu nicht teuer. Ich glaube, die Prologix Dinger sind die einzigen bezahlbaren GPIB Adapter. Alles andere ist masslos überteuert. Ich habe mir mal überlegt, selber einen solchen Adapter zu bauen, schwierig wäre es nicht, aber macht wenig Spass und die fertigen Dinger sind einfach zu gut. Spass vs. Kosten haben mich dann vom Selbstbau nicht überzeugt :-)
Tobias P. schrieb: > Ich habe mir mal überlegt, selber einen solchen Adapter zu bauen, > schwierig wäre es nicht, Unterschätze sowas nicht. ein OM aus unseren OV hatte es versucht. Hardwaremäßig war das kein Problem. Aber nach fast einen Jahr frustrierter Programmiererei hatte er es aufgegeben und sich den HP82357B gekauft. Und er kann programmieren. Ralph Berres
Den Schnittstelle gibts für USB und Ethernet http://prologix.biz/gpib-usb-controller.html USB 149 Dollar, der andere um 200 Dollar. Kompatible aus China anscheinend schon um $25. Die Hardware von GPIB ist wirklich simpel, 8Bit Datenbus und nochmal 8 Handshake-Leitungen, alles mit open-collector Logik. Was kann das Prologic-Teil außerdem, um den Programmieraufwand zu vereinfachen?
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > Was kann das > Prologic-Teil außerdem, um den Programmieraufwand zu vereinfachen? naja der kann nicht wirklich viel, am PC schaut es aus wie eine RS-232, wo man Text rausgeben kann oder rein bekommt. Der handelt nur hardwaremässig das GPIB-Protokoll ab und gibt die Rohdaten am PC aus bzw. schickt Rohdaten vom PC auf den GPIB. Ich habe mit Python und mit C++ schon Applikationen geschrieben, die damit arbeiten, aber das war alles immer ein bisschen ein Gebastel. Das Problem ist, dass man oftmals beim Antworttelegramm, dass der Analyzer zurückschickt (und dass die gewünschten Rohdaten enthält, beispielsweise) nicht im Voraus weiss, wie lang es ist. Und da ich mit Threads und dem ganzen Geraffel auf der PC-Seite nicht so fit bin, war mir nie ganz klar, wie man jetzt auf das Ende der Daten warten soll. Eine weitere Komplikation kommt dazu, weil einige Analyzer die rohdaten auf einer einzigen Zeile als kommagetrennte Werte senden (z.B. HP8568, 8566), während andere Analyzer die Daten Zeilenweise verschicken (z.B. HP8753 sendet eine Tabelle mit Real und Imag, die Zeilen der Tabelle sind mit CR/LF getrennt). Dann gibt es noch das EOI-Signal, wenn ich mich recht erinnere. Einige Analyzer verwenden dies, um dem GPIB-Controller zu signalisieren, dass der Transfer beendet ist (z.B. HP4195), während andere Analyzer das EOI-Signal nie verwenden und stattdessen mit irgend einem Sonderzeichen das Ende der Telegramme markieren (z.B. HP436). Es ist also eigentlich gar nicht möglich, eine universelle Bibliothek zu bauen, welche GPIB ansich einfach abhandelt, daher ist mir das auch immer ein bisschen ein Rätsel, warum das bei NI funktioniert. Eben die erste Schwierigkeit kommt beim Erkennen vom Ende der Daten, die zweite Schwierigkeit kommt dann noch weil die Analyzer unterschiedlich lange brauchen, bis sie nach einer Anfrage Daten zurückschicken - daher kann man auch Timeouts nicht so einfach festlegen. Das alles macht die GPIB-Schnittstelle einfach ein bisschen unkomfortabel und bastelig und ich habe noch keine brauchbare Lösung gefunden (ausser die von John, und die läuft nur auf Windows, ist also auch nicht das Gelbe vom Ei). Wenn da aber jemand eine tolle Idee liefern könnte, wie man es "richtig" macht, dann würde mich das schon sehr interessieren. Technisch möglich ist es ja, ganz offensichtlich. Wie oben erwähnt, hatte ich ja auch mal ein Programm gebaut, ähnlich wie das was der TO hier veröffentlicht hat. Es konnte den 8568, 8566 und 8563 ansteuern und Rohdaten ausgeben sowie anzeigen. Ich wollte auch eine Art "Echtzeitdisplay" auf dem PC-Bildschirm haben, aber das hat nie brauchbar funktioniert, weil z.B. der 8563 immer 801 Datenpunkte sendet, und die Übertragung so vieler Daten als Klartext so lange gedauert hat, dass es nie flüssig lief. Das liegt aber mit Sicherheit auch an meiner Implementierung, denn John kann mit seinem "Spectrum Surveillance Tool" auch quasi Echtzeit wiedergeben, nur verstehe ich nicht ganz, wie es funktioniert. Jedenfalls scheint es irgend eine spezielle Betriebsart oder etwas in der Art zu sein, wo der Analyzer die Daten schneller sendet (binär?) oder er hat einfach die Schnittstelle effizienter programmiert.
Tobias P. schrieb: > Dann gibt es noch das EOI-Signal, wenn ich > mich recht erinnere. Einige Analyzer verwenden dies, um dem > GPIB-Controller zu signalisieren, dass der Transfer beendet ist (z.B. > HP4195), während andere Analyzer das EOI-Signal nie verwenden und > stattdessen mit irgend einem Sonderzeichen das Ende der Telegramme > markieren (z.B. HP436). das ist in der Regel das CR/LF Zeichen Tobias P. schrieb: > die zweite > Schwierigkeit kommt dann noch weil die Analyzer unterschiedlich lange > brauchen, bis sie nach einer Anfrage Daten zurückschicken - daher kann > man auch Timeouts nicht so einfach festlegen. dieses Dreidrahthandshake ermöglicht, das der langsamste momentan adressierte Teilnehmer die Geschwindigkeit auf dem Bus bestimmt. Der IECbuskontroller hat auf der PC Seite dann zwei Zweidrahthandshakeleitungen einer für Senden und einer für Empfangen. Timeout-Routinen sollten wirklich nur zum abfangen von Fehlern auf dem IECbus dienen, und sich im Sekundenbereich bewegen. Ansonsten steuert man das PCseitige Handshake mit Hilfe von Interupts. Im Grunde genommen finde ich die IECbusschnittstelle für Messgerätesteuerung immer noch ziemlich genial, auch wenn sie schon über 40 Jahre alt ist. Ralph Berres
Christoph db1uq K. schrieb: > Den Schnittstelle gibts für USB und Ethernet > http://prologix.biz/gpib-usb-controller.html > USB 149 Dollar, der andere um 200 Dollar. Kompatible aus China > anscheinend schon um $25. Wo für $25? Kenne nur die Keysight 82357B Plagiate für ca. 80€. War mir nur für eine Bildschirmhardcopy noch zu teuer. Grüße von petawatt
Horst S. schrieb: > Wo für $25? > Kenne nur die Keysight 82357B Plagiate für ca. 80€. War mir nur für eine > Bildschirmhardcopy noch zu teuer. Die preisgünstigste Möglichkeit eine Hardcopy des Bildschirmes zu erhalten, ist das abfotographieren mit dem Smartphon. Das hat ja heute ( fast ) jeder. Ralph Berres
https://de.aliexpress.com/i/4000034884174.html die vierzig Räuber haben solche Preise "GPIB drehen USB, GPIB-USBCDC Kompatibilität, Prologix IEEE-488 Instrument Control Interface" US $18.33
Ralph B. schrieb: > Die preisgünstigste Möglichkeit eine Hardcopy des Bildschirmes zu > erhalten, ist das abfotographieren mit dem Smartphon. Das hat ja heute ( > fast ) jeder. Mein Leihgerät HP8590L hatte wenigstens noch eine Parallelschnittstelle für meinen alten Deskjet. Momentan bleibt mir auch nur das Foto. Fühle mich an die alten Zeiten im Hochspannungsinstitut und im Kurzschluss-Labor der KEMA erinnert. Es wurden massenweise Polaroidfilme verbraucht und mit Lineal und Skalpell ausgewertet. Bau mir gerade eine Fremdlichtabschirmung da die Bildschirmoberfläche vom HP8591E übel spiegelt. Der GPIB-USB-Wandler für 18,33 von AliExpress ist nicht mehr lieferbar. Kostet jetzt 25,22€ https://de.aliexpress.com/item/4000306576135.html?spm=a2g0o.detail.1000013.5.8d4f436cLKfoOj&gps-id=pcDetailBottomMoreThisSeller&scm=1007.14977.165002.0&scm_id=1007.14977.165002.0&scm-url=1007.14977.165002.0&pvid=ea13a434-c5ca-43cb-91c2-f8e31074b063&_t=gps-id:pcDetailBottomMoreThisSeller,scm-url:1007.14977.165002.0,pvid:ea13a434-c5ca-43cb-91c2-f8e31074b063,tpp_buckets:668%230%23131923%238_668%23808%236395%23435_668%23888%233325%232_668%232846%238112%23528_668%232717%237563%23518 Ist ein Prologix-Clon: https://github.com/fenrir-naru/gpib-usbcdc Grüße von petawatt
:
Bearbeitet durch User
Angehängte Dateien:
-
ukw.png
9,6 KB
Horst S. schrieb: > Wo für $25? > Kenne nur die Keysight 82357B Plagiate für ca. 80€. War mir nur für eine > Bildschirmhardcopy noch zu teuer. Am billigsten ist ein Prologix-Plagiat oder eine der unzähligen Prologix-kompatiblen Bastellösungen. Gibt es sogar auf Arduino-Basis, z.B. https://github.com/Twilight-Logic/AR488 Du öffnest ein Terminalfenster und tippst "PLOT 0,0,55000,37500;" ein. Das was Dir dann entgegenkommt speicherst Du in einer Datei mit der Endung *.plt ab. Dieses Format nennt sich "HPGL" und kann von vielen Graphikprogrammen eingelesen werden.
übrigens bei dem HP8752 und HP8753 braucht man im Grunde genommen nur einen einzigen Befehl um an die Plotdaten zu kommen. Siehe mein Basic Programm 1 LOAD BIN "BPLUS" 2 OPTION BASE 1 3 DIM Daten$[20000] 4 DIM Daten1$[200] 5 DIM Daten2$[200] 6 DIM Daten3$[200] 7 DIM Daten4$[200] 8 DIM Daten5$[20000] 9 REAL Daten 10 ASSIGN @HP8752 TO 726 11 OUTPUT @HP8752;"outpplot " 12 ENTER @HP8752;Daten1$ 14 PRINT Daten1$ 15 ENTER @HP8752;Daten2$ 17 PRINT Daten2$ 18 ENTER @HP8752;Daten3$ 20 PRINT Daten3$ 21 ENTER @HP8752;Daten4$ 23 PRINT Daten4$ 25 ENTER @HP8752;Daten5$ 27 PRINT Daten5$ 28 ! GOTO L330 29 Daten$=Daten1$&Daten2$&Daten3$&Daten4$&Daten5$ 30 PURGE "C:\Ibasic\HP8752\Projekte\Grafik.plt" 31 ! 33 CREATE "C:\Ibasic\HP8752\Projekte\Grafik.plt",0 34 ! 36 PRINTER IS "C:\Ibasic\HP8752\Projekte\Grafik.plt" ! Der Printbefehl wird auf Laufwerk C umgeleitet.END 37 PRINT Daten$ 38 QUIT ALL 39 L330: END
Horst S. schrieb: > Der GPIB-USB-Wandler für 18,33 von AliExpress ist nicht mehr lieferbar. > Kostet jetzt 25,22€ Hab das Teil mal bestellt. Im ersten Versuch wird der Bestellvorgang ganz am Ende mit dem Hinweis "nicht lieferbar" abgebrochen. Nach Änderung des Versandlands von Germany auf Austria auf der Startseite von Ali wird die Bestellung an die nicht geänderte Adresse bestätigt. Geo-Blocking? Hat jemand Erfahrung mit dem Interface? Wie installieren für Bildschirmhardcopy von HP8591E auf WIN10 mit Tools von John Miles? Grüße von petawatt
:
Bearbeitet durch User
Hallo, ich habe vor einiger Zeit diesen hier erworben: http://www.galvant.ca/#!/store Das ist mehr oder weniger ein Clone des Prologix, schön dabei ist, dass sowohl die Firmware des Adapters wie auch eine nette Python Lib vom Stephen in Github verfügbar sind: https://github.com/galvant Das InstrumentKit ist wirklich handlich und läßt sich anhand der Beispiele leicht für eigene GPIB Geräte erweitern. Gruß... Bert
:
Bearbeitet durch User
Hallo, falls ein RaspberryPi zur Hand ist, könnte man auch mein GPIB-Shield verwenden (http://elektronomikon.org) Mit der python-lib von linux-gpib bin ich auch sehr zufrieden. lG, Thomas
Bert 0. schrieb: > ich habe vor einiger Zeit diesen hier erworben: Kostet aber auch $75 plus sicherlich Steuer und Versand. Dafür gibt es alternativ schon das Agilent-82357B-Plagiat. Wird bei eBay nie als gebraucht angeboten. Muss wohl einigermaßen funktionieren. Grüße von petawatt
Horst S. schrieb: > Dafür gibt es > alternativ schon das Agilent-82357B-Plagiat. man muss aber aufpassen, das dieses Plagiat ein CE Zeichen hat, sonst wird es bei der Einfuhr vom Zoll abgewiesen. ( Selber schon erlebt ). Dann ist dein Geld weg. Seitdem kaufe ich solche Produkte nicht mehr beim Chinesen. Ralph Berres
Ralph B. schrieb: > man muss aber aufpassen, das dieses Plagiat ein CE Zeichen hat Da haben die Chinesen dazugelernt. Es wird alles inclusive CE-Zeichen kopiert. Nun ist das CE-Zeichen ja kein Prüfnachweis. Es wird nur vom Hersteller versichert, dass alle relevanten Vorschriften eingehalten werden. Ein Prüfnachweis in Form von Testzertifikaten wird erst mal nicht mitgeliefert. Wird der Zoll wohl auch kaum bei Agilent anfordern können. CE-Aufkleber gibt es günstig bei AMAZON und werden gedankenlos auf alle Produkte geklebt. Nach einer heftigen Diskussion zwischen CENELEC und IEC wurde damals in meiner IEC-Arbeitsgruppe die Kennzeichnungspflicht von z.B. Hochspannungsschaltgeräten mit einem CE-Zeichen erfolgreich verhindert. Sicherlich eine juristische Grauzone. Ein GPIB-USB-Adapter ist auch kein Produkt für den privaten "Endverbraucher". Grüße von petawatt
Thorsten .. schrieb: > Wo kriegt man die DLL her bzw. was fehlt da noch? Mein System Win7/32 hat diese DLL nicht und braucht sie auch nicht. Habe es gerade auf einem Windows 10 Rechner ausprobiert und bekomme dieselbe Fehlermeldung. Scheint eine notwendige Erweiterung zu sein. Aber es scheint Suchmöglichkeiten zu geben. "ext-ms-win-gdi-desktop-l1-1-0.dll fehlt"
Horst S. schrieb: > Nach einer heftigen Diskussion zwischen CENELEC und IEC wurde damals in > meiner IEC-Arbeitsgruppe die Kennzeichnungspflicht von z.B. > Hochspannungsschaltgeräten mit einem CE-Zeichen erfolgreich verhindert. > Sicherlich eine juristische Grauzone. Ein GPIB-USB-Adapter ist auch kein > Produkt für den privaten "Endverbraucher". Ursprünglich war das CE-Zeichen zur Erleichterung des Imports gedacht, damit man sich nicht mit den Eigenheiten aller beteiligten EU-Länder auseinandersetzen muss. Es gibt durchaus Produkte, bei denen das Anbringen eines CE-Zeichens strikt verboten ist. Tragende Bauteile von Aufzügen z.B. ---- Ich habe übrigens ein Programm zum Fernsteuern eines Agilent 89441A vector signal / FFT analyzers geschrieben. Der kann zwar schöne FFTs machen, aber eben nicht mit logarithmischer Frequenzskala von 1 Hz bis 1 MHZ. Das Programm macht dann eine FFT für jede Dekade, saugt die Daten ab, sortiert & kombiniert sie und macht dann mit gnuplot einen log-Plot über alles. QT-Terminal, .eps und .png. Der 89441A hat GPIB und LAN über 10 MBit/s BNC-Ethernet. Mit einer Interface-Schachtel von Amazon sieht man ihn dann ganz normal im GBit-LAN. Man macht einfach Port 500x von 192.168.178.38 auf und kann dann GPIB-Strings reinkippen oder abholen. Das hat jahrein/jahraus ganz gut funktioniert, wurde aber im letzten Jahr zunehmend hakeliger. Ich habe dann die Option -488 eingeführt und die GPIB-Kommandos über einen dieser gelben USB/GPIB-Dongles von Prologix geleitet. Ich bin aber nicht abschließend mit dem Prologix klargekommen. Es war nie klar, wann ein CR, CRLF oder sonst was gebraucht wird, oder ob gerade die USB oder die GPIB-Seite hakelt. Die Doku zum Prologix ist so ausführlich wie ein Kochbuch aus der Sahelzone, und das meiste brauchbare ist von dritter Seite. Grundsätzlich reden konnte ich aber mit dem 89441A. Ich habe dann rausgefunden, was an der LAN-Lösung nicht funktioniert hat. Wenn man die Datenrichtung ändert, muss man einmal (leer) seeken, auch wenn man das eigentlich garnicht will. Das war wohl früher optional, wird aber mittlerweile vom Linux-Kernel durchgesetzt. Nachdem das nun wieder funktioniert hat, war echt kein Antrieb mehr da, mich weiter mit dem Prologix zu beschäftigen. Immerhin war nicht der Analyzer am Sterben. Die Quellen sind im Prinzip zu haben, ich will sie aber in dem 95%-fertigen Zustand noch nicht im Netz rumfloaten sehen. Keine Ahnung, ob man das ohne Aufwand nach Windows übersetzen kann. Gruß, Gerhard
:
Bearbeitet durch User
Gerhard H. schrieb: > Ich bin aber nicht abschließend mit dem Prologix klargekommen. Es war > nie klar, wann ein CR, CRLF oder sonst was gebraucht wird, oder ob > gerade die USB oder die GPIB-Seite hakelt. Genau das ist auch mein Problem! ich bin zugegebenermassen nicht der geborene PC-Programmierer. Ich hatte das (unrealistische?) Ziel, in einer beliebigen Sprache (C, C++, Python, wasauchimmer) zwei generische Funktionen zu bauen: gpib_write setzt einen einfachen Befehl ab (zB. "RESET" oder "SPAN 100MHz") und gpib_query fragt etwas ab (zB "SPAN?" oder "MEAS:VOLT?") und liefert als String das Resultat zurück. Prinzipiell hat es funktioniert, aber eben nicht ganz, weil man beim Empfang auf der PC-Seite nie sicher ist, wann der Empfangsstring zuende ist. Die empfangenen Bytes trudeln nacheinander ein, einige Geräte liefern die Daten mit abschliessendem CRLF, andere nicht. Einige Network/Spektrumanalyzer senden die Daten als Kommagetrennte Liste, andere trennen die einzelnen Messpunkte mit Zeilenumbrüchen. Ist es so überhaupt möglich, eine generische brauchbare Lesefunktion zu bauen? Wie kann ich erfragen, ob das Stringende erreicht ist?
Tobias P. schrieb: > Wie > kann ich erfragen, ob das Stringende erreicht ist? Das Stringende wird bei den meisten Geräten mit einen CR/LF abgeschlossen. Die meisten Dienstprogramme wollen das genau sehen. Das CR/LF Zeichen must du übrigens nicht in deinem Programm reinschreiben, das sendet der IECbus Treiber automatisch. Es ist mir bisher noch kein Gerät über den Weg gelaufen, welcher ausschließlich die EOI Leitung gesetzt hat. Bei vielen Geräten kann man im Konfigurationsmenue auswählen ob EOI , CR , LF als Stringabschluss genommen wird. Oft auch eine Kombination von mehreren. Bei manchen sehr alten Geräten konnte man das mit Dipschaltern vorgeben. Tobias P. schrieb: > gpib_write setzt einen einfachen Befehl ab (zB. "RESET" oder "SPAN > 100MHz") und gpib_query fragt etwas ab (zB "SPAN?" oder "MEAS:VOLT?") > und liefert als String das Resultat zurück. Genauso funktioniert das in dem HP-Basic bzw HT Basic auch. Um den Stringabschluss brauchst du dich nicht zu kümmern. Ralph Berres
:
Bearbeitet durch User
Ralph B. schrieb: > Um den Stringabschluss brauchst du dich nicht zu kümmern. ja eben doch oder? 2 Beispiele. Gut: HP 8566B antwortet auf "TA" ("Transfer Trace A data") wie folgt -100,-99,-101,....,-20<CR><LF> und sendet eine kommagetrennte Liste von Datenpunkten. Soweit gut, der PC, der diesen String von der RS-232 empfängt, wartet einfach auf das CRLF und fertig. Schlecht: HP 8753C antwortet auf "OUTPFORM" ("output formatted data") wie folgt 0.01 0.02<CR><LF> 0.03 0.04<CR><LF> ... da kommen die Real- und Imaginärteile in 2 Spalten, für jede Frequenz eine Zeile. Wie kann der Empfänger hier das Stringende finden? auf CRLF warten geht nicht, weil die in den Daten selbst schon vorhanden sind? Das Problem ist halt, dass man dem GPIB Adapter sagen muss: lies mal alles bis zum EOI. Das funktioniert, aber der Adapter sendet dann einen String über die RS-232, und die API für die serielle Schnittstelle am PC ist ja eh schon verkrüppelt - wie soll man da noch sicher einen kompletten String empfangen und sicher dessen Ende finden! :-(
Spätestens wenn du /dev/tty_USB00 in den raw mode versetzt damit die Flusskontrolle mit ctl-s/ctl-q ausgeschaltet ist und damit backspace keinen Input mehr löscht, dann musst du dich um alles selbst kümmern. Und nein, der Analyzer kann seine Strings mit so ziemlich allem abschließen, inclusive garnix und Ziehen der EOI-Leitung beim letzten Byte. Und das gleiche gilt für den Dongle. Und bei dem kannst du eigentlich auch nicht sicher sein ob du gerade an der USB-Seite oder der GPIB-Seite programmierst. Immerhin müssen Dongle-Kommandos lower case sein. Verstöße resultieren aber keinesfalls unbedingt in einer Fehlermeldung. Und den timeout kann man zwar einschalten, das bedeutet aber nicht, dass es irgendwann weitergeht, womöglich sogar mit einem definierten Verhalten.
Tobias P. schrieb: > Schlecht: > HP 8753C antwortet auf "OUTPFORM" ("output formatted data") wie folgt > > 0.01 0.02<CR><LF> > 0.03 0.04<CR><LF> > ... macht er das wirklich bei jeder der bis zu 16000 gesendete Frequenzn so? Ich hatte bei meinen HP8752 ein ähnliches Problem. Ich musste den Header 4 mal aufrufen, bis er komplett war, aber die eigentlichen Plotdaten kamen in einen Rutsch, Befehl war bei mir Outpplot ASSIGN @HP8752 TO 726 11 OUTPUT @HP8752;"outpplot " 12 ENTER @HP8752;Daten1$ 14 PRINT Daten1$ 15 ENTER @HP8752;Daten2$ 17 PRINT Daten2$ 18 ENTER @HP8752;Daten3$ 20 PRINT Daten3$ 21 ENTER @HP8752;Daten4$ 23 PRINT Daten4$ 25 ENTER @HP8752;Daten5$ Ralph Berres
Gerhard H. schrieb: > Und nein, der Analyzer kann seine Strings mit so ziemlich allem > abschließen, inclusive garnix und Ziehen der EOI-Leitung beim letzten > Byte. zumindest die HP 875X Serie macht das aber nicht. Sie haben als Schlusszeichen das CR/LF Das Problem beim Tobias ist das es offensichtlich nach jeder Zeile kommt. Zumindest scheint das bei dem Befehl Outpform zu sein ( was ich noch nie genutzt habe, weil ich halt einen Screenshot haben wollte ). Ralph Berres
Ralph B. schrieb: > Zumindest scheint das bei dem Befehl Outpform zu sein ( was ich noch nie > genutzt habe, weil ich halt einen Screenshot haben wollte ). ganz genau. Ich will meistens keinen Screenshot, sondern die Rohdaten, und plotte die dann selbst, damit alles einheitlich ist. Finde ich persönlich immer etwas unschön, wenn jedes Diagramm ein anderes Format hat :-/ Gerhard H. schrieb: > Und nein, der Analyzer kann seine Strings mit so ziemlich allem > abschließen, inclusive garnix und Ziehen der EOI-Leitung beim letzten > Byte. ganz genau. Funktioniert das mit dem Agilent Dingens besser? oder wie erkennt man zuverlässig das Stringende? jedesmal auf den Timeout warten kann ja auch keine Lösung sein.
Tobias P. schrieb: > oder wie > erkennt man zuverlässig das Stringende? jedesmal auf den Timeout warten > kann ja auch keine Lösung sein. einfach nur Enter solange senden bis nichts mehr kommt. Natürlich jedesmal in eine andere Datei schreiben und alle Dateien aneinanderhängen. Ist zwar eine unschöne Art, müsste aber funktionieren. Der Timeout ist ausschlieslich dazu das um das aufhängen des IEEE488 Busses zu vermeiden. Ralph Berres
Tobias P. schrieb: > ganz genau. Funktioniert das mit dem Agilent Dingens besser? oder wie > erkennt man zuverlässig das Stringende? jedesmal auf den Timeout warten > kann ja auch keine Lösung sein. Prologix und NI/Agilent haben ganz unterschiedliche Arbeitsweisen. Der Prologix und seine Ableger meldet sich als serielles Gerät an. Egal ob über COM-Port, USB oder Ethernet. Also kann er genau das senden und empfangen was ein COM-Port auch kann, nämlich 8 bit ASCII. Darin muss man Nutzdaten, Steuerkommandos für den Adapter und Handshake irgendwie unterbringen. Zum Bedienen reicht aber notfalls ein Terminalprogramm. NI/Agilent bringen einen VISA-Treiber mit. Das ist eine eigene Geräteklasse, wo man Gerätesteuerung und Nutzdaten getrennt rangieren kann. Dafür muss die SW auf spezielle DLLs zugreifen und die Treibersoftware ist sehr raumgreifend.
Ralph B. schrieb: > Tobias P. schrieb: >> oder wie >> erkennt man zuverlässig das Stringende? jedesmal auf den Timeout warten >> kann ja auch keine Lösung sein. > > einfach nur Enter solange senden bis nichts mehr kommt. Natürlich > jedesmal in eine andere Datei schreiben und alle Dateien > aneinanderhängen. > > Ist zwar eine unschöne Art, müsste aber funktionieren. Bei Prologix und Konsorten kannst Du Dir EOI auf ein beliebiges ASCII-Zeichen mappen lassen. Dann sendet der Adapter z.B. ctrl-Z wenn das Gerät fertig ist. Deine Software muss dann halt alles aufsammeln bis dieses Zeichen kommt. Verloren hast Du nur bei Binärdaten, denn da können alle 256 ASCII-Werte vorkommen.
Tobias P. schrieb: >> Und nein, der Analyzer kann seine Strings mit so ziemlich allem >> abschließen, inclusive garnix und Ziehen der EOI-Leitung beim letzten >> Byte. > > ganz genau. Funktioniert das mit dem Agilent Dingens besser? oder wie > erkennt man zuverlässig das Stringende? jedesmal auf den Timeout warten > kann ja auch keine Lösung sein. Ich habe das nicht wirklich zuverlässig hinbekommen. Und das, obwohl die Kommunikation mit dem Analyzer selbst ja schon mit dem LAN-Interface ausgetestet war. Das Timeout hilft auch nicht weiter. Man kann es setzen, aber was im Falle eines Timeouts passiert, ist nirgendwo erwähnt. Was soll es auch schon groß tun? Wenn ich auf einen String vom Analyzer warte, dann ist das USB-Device blockiert. Ich kann getstring() nicht mal eben auf Eis legen, in den Prologic-Registern rumpoken und dann weitermachen. Ich hab's versucht, aber da war nix zu sehen. Wenn ich das LAN-Interface nicht doch noch zum Spielen bebracht hätte, wäre ich wohl auf Linuxgpib und meine PCI-Larte ausgewichen, wenn auch ungern. Immerhin hat der Agilent ein Kommando mit dem man die reinkommenden Befehle in der linken oberen Screenecke angezeigt bekommt, mit Pfeifen wenn was nicht stimmen kann. Ohne Bremse geht das aber schneller als man hinsehen kann.
Angehängte Dateien:
-
ADF4351_integer.png
14 KB -
ADF4351_frac_lownoise.png
29 KB -
ADF4351_frac_lowspurs.png
30 KB
Eine Anwendung meines Spektrum-Analyzer-Programmes. Endlich mal eine glasklare Darstellung von Signalen, keine verschwommenen Fotos vom Analyzer-Bildschirm. Anbei mal eine Demo des AF4351 Synthesizers. Die erste Darstellung ist ein synthetisiertes Signal in Ganzzahl- Teilung. Frequenz des Phasendetektors 1.25 MHz, Teilerfaktor des Hauptteilers dann also 3200 (4GHz / 1.25 MHz). Die zweite und dritte Darstellung zeigt das gleiche Sigal nur um 100 KHz versetzt. Damit ist natürlich dann keine Ganzzahl-Teilung möglich und es entstehen Nebenlinien durch Fraktional-Teilung. Diese Nebenlinien kann man ein wenig unterdrücken indem der Synthesizer die Modulation der Fraktionalteilung verschwimmen lassen kann und damit die Nebenlinien zum (verbreiteten) Rauschen degenerieren. Zum Modifizieren dieser Eigenschaft hat der ADF4351 ein Steuerbit Low Noise/Low Spurs. Bleibt zu bemerken dass durch die Fraktionalteilung das Rauschen in der Umgebung um den Täger in dieser Darstellung sich um etwa 20 dB (Fraktional vs. Integer) unterscheidet.
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.