GPIB to USB Hardcopy Interface in Betrieb nehmen

Falls es der "GPIB-Grabber" ist hilft archive.org wie üblich weiter:

https://web.archive.org/web/20080923001502/www.emsystech.com/gpib2.html

Und dann lesen (Zitat):

1

Neben der mitgelieferten GPIB-Grabber Software für Windows kann das Interface mit den folgenden Programmen verwendet werden:

2

3

    KE5FX GPIB-Toolkit (Open Source)

4

    Printcapture (Shareware)

5

    Plottergeist (Kommerziell)

Dieter S. schrieb:

Und dann lesen (Zitat):

Ja Danke, aber das sind alles alte Windows-Sachen. Nicht ganz das was ich suchte. Aber klar, zur Not könnte man das versuchen.

Du hast von Suchmaschinen gehört und von WINE?

http://www.ke5fx.com/gpib/faq.htm

"Q. Any tips for running the Toolkit applications under Linux?

A. Some users have reported good results using the WINE compatibility layer."

Ok, werde mir das morgen Abend genauer ansehen. Hätte gedacht, dass eine COM-Portzuweisung einfacher wäre. Gibt ja mittlerweile Python-Libs für HPGL=>SVG Umsetzung.

Habe jetzt Printcapture und das GPIB-Toolkit unter Linux Wine und Windows 10 ausprobiert. Wirklich schön anzuschauende Tools.

Aber der Adapter versteckt sich unter beiden Betriebssystemen.

Unter Windows lassen sich die FTDI-Treiber nicht installieren. Im Gerätemanager sieht man zwar unter unbekannten Geräten den Adapter, aber eine Treiberinstallation scheitert mit "keine Treiber für das Gerät gefunden". Damit funktionieren auch keine der Tools.

Unter Linux sind im Prinzip die Treiber vorhanden, aber wie oben schon gesagt, es gibt keine Zuweisung auf einen Port.

Ich nehme an, der Hersteller hat die Vendor- oder Product-ID verbogen oder ähnliches, vielleicht als Kopierschutz.

Wulf D. schrieb:

Keine Hinweise auf eine COM-Port-Zuweisung, mit der ich z.B. die vermuteten HPGL 7470 Commands abfangen könnte.

Wenn du die dmesg ausgabe vollständig anschaust, dann sollte in der Nähe von

[ 1655.459574] usb 3-6.1: Product: GPIB to USB Hardcopy-Interface

auch die zugehörigen Interfaces im Log auftauchen. Wenn da nix auftaucht - was ich stark vermute, weil diese FTDI kein UART ist, sonder ein parallel-Interface - dann muss der FTDI direkt angesprochen werden. Es könnte z.B. mit

https://pypi.org/project/pylibftdi/

funktionieren, da diese Lib auf der libftdi aufbaut, welche den FT245R können sollte.

Und auch hier hilft eine Suchmaschine (die VID/PID müssen vermutlich erst ftdi_sio mitgeteilt werden):

https://ftdichip.com/faq/how-do-i-add-a-custom-pid-to-the-ftdi_sio-linux-com-port-driver/

1

# modprobe ftdi-sio

2

# echo 0403 dc88 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

Ich kann durchaus verstehen das man Aufwand investiert fuer Dinge die man sonst nicht machen koennte. Aber du kannst doch heute relativ preiswerte GPIB-USB Adapter bekommen die einfach so unter Linux funktionieren. Das kostet dich vielleicht 20-30Euro. Waer es da nicht sinnvoller den alten Adapter wegzuwerfen und einfach mal den Gegenwert von 2-3 Doener zu investieren?

Ich benutze den hier unter Linux und hab noch nie einen Treiber installiert. Geht einfach so.

https://github.com/xyphro/UsbGpib

Vanye

Andreas M. schrieb:

Wenn da nix auftaucht - was ich stark vermute, weil diese FTDI kein UART ist, sonder ein parallel-Interface - dann muss der FTDI direkt angesprochen werden.

So bizarr es klingt, aber ein ft245 ist, sofern er nicht irgendwie wüst umkonfiguriert wird, aus Sicht des Hosts auch 'ne serielle Schnittstelle.

Von FTDI gibt es ein Tool namens "ftprog" zum Programmieren des im ft245r enthaltenen EEPROMs, da könnte man ein Backup des ist-Standes anfertigen, und dann das Ding auf Standardwerte zurücksetzen.

Danke euch für die zahlreichen Tipps. Da führen sicher mehrere Wege zum Ziel. Der wirtschaftlichse wäre sicher einfach einen aktuellen GPIB-Adapter zu kaufen, kenne mich mit Treibern Null aus.

Aber man kann es ja mal probieren. Bin einen Schritt weiter, dank dem Vorschlag von Dieter S., den zuerst probiert und der liefert das gesuchte Device als neues /dev/ttyUSB2

Wahrscheinlich hätte pylibftdi auch funktioniert, aber mit seriellen Interfaces kenne ich mich etwas besser aus.

Mit kleinem Python-Script die Daten aufgefangen. Sehen etwas seltsam aus. Inkscape oder Converter wie hp2xx mögen die nicht. Vielleicht fehlt etwas oder im Zeichensatz läuft was schief, da sind auffallend viele (ETX) und @-Zeichen. Anbei ein Beispiel aus einem 80er-Jahre Spektrum-Analyser.

Die Plot-Datei sieht ein wenig so aus, als klemmt im im oberen Nibble das unterste Bit. Dann würde aus @D und MHj jeweils PD und MHz werden, was sinnvoller ist.

War wohl etwas Patina drauf, formal sieht die HPGL-Datei nun ganz gut aus. Nur der Inhalt erschließt sich mir noch nicht, sehe mit hp2xx nur einen vertikalen, schmalen Streifen.

7470.exe aus dem KE5FX GPIB Toolkit hat damit kein Problem, siehe Anhang.

Probiers doch mal damit: https://github.com/VK2BEA/HPGL-Plotter

[edit] Hmm, scheint aber keine Dateien öffnen zu können sondern arbeitet direkt auf dem gbip

Ja, 7470.exe funktioniert bei mir auch. Über den Umweg pdf kann man damit auch andere, gängigere Formate erzeugen.

Ich denke das genügt so. Andreas HPGL-Plotter sieht auf den ersten Blick auch gut aus, aber der will ein GPIB und wer weiß ob der das Datenformat des Anritsu wirklich versteht.

Prima, hat dann doch noch geklappt. Vielen Dank an die Unterstützer!

[edit] gerade gesehen, 7074.exe kann auch gif-Export in bester Qualität. Und läuft unter wine.