Forum: Mikrocontroller und Digitale Elektronik Sammelbestellung AR488 kompatibler USB-GPIB Adapter. Interesse?


von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Da fällt mir ein: das HP6633 wollte mit dem AR488 gar nicht reden. Hab 
den USBTMC dann dafür genommen.

von Dieter S. (ds1)


Lesenswert?

Zu den Problemen bei vielen Geräten am Bus: Vielleicht mal mit PE 
(Pullup Enable) des SN75160B experimentieren, eventuell ändert das was.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> Daher wundert mich auch etwas, dass der Aufbau eines größeren Busses
> damit doch etwas problematisch ist.

Mich auch... Ich hätte erwartet, dass ein voller Bus kein Problem macht.

Obwohl das natürlich stimmen könnte:

Jörg W. schrieb:
> 900ss schrieb:
>> Ich kann mich erinnern, als ich mich irgendwann so 2008 rum mit einem
>> DIY Adapter beschäftigte, da hieß es, dass ein AVR an eine Stelle das
>> Timing verletzt weil es in SW schlicht zu langsam ist.
>
> Ging mir auch so, ja. Aber hier ist ja ein ESP32 drauf, der sollte schon
> ein Stück schneller sein. Kann aber natürlich trotzdem sein, dass ein
> Handshake in Software problematisch ist. Als man den Bus definiert hat,
> hat man an dieser Stelle komplett auf (TTL-)Hardware gesetzt.

In dem ursprünglichen hpib Guide sind noch eine extra Terminierung 
beschrieben, die ich nur in einer einzigen Hardwareumsetzung gesehen 
habe.

Auch auf Fotos NI Karten habe ich die nicht gesehen. Die SN7516x sollten 
die aber eigentlich integriert haben (so lese ich zumindest das 
Datenblatt).

Ja, der esp32 ist verhältnismäßig schnell - die GPIO bitbanging ist aber 
immer so eine Sache... Wird es stabiler wenn du mit -Ofast compilierst? 
Das würde die timing-theorie stützen.

73

von Vanye R. (vanye_rijan)


Lesenswert?

> Welche der früheren GPIB-Karten aus den PCs hatte denn die
> Treiber-ICs in Fassungen?

Die Teile wurden wohl spaeter auch gar nicht mehr gebraucht!

Ich hab hier gerade einen SMT02 von R&S auf dem Tisch. Da ist ein 
TNT4882 drin. Datenblatt gibt es hier:

https://www.ni.com/de-de/shop/model/tnt4882.html

Da sind die Treiber seit 1995 bereits integriert.


BTW: Sollte man diesen Thread nicht mal verschieben? 90% hier ist ja 
garnicht mehr "Markt"

Vanye

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Ja, der esp32 ist verhältnismäßig schnell - die GPIO bitbanging ist aber
> immer so eine Sache... Wird es stabiler wenn du mit -Ofast compilierst?

Muss ich mal gucken, im Moment habe ich Dieters Binary laufen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Vanye R. schrieb:
> BTW: Sollte man diesen Thread nicht mal verschieben?

OK

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Ja, der esp32 ist verhältnismäßig schnell - die GPIO bitbanging ist aber
> immer so eine Sache.

Was mir dazu noch einfällt: die Probleme, wenn paar Geräte mehr am Bus 
waren, waren fast immer Datenverfälschungen, also gekippte Bits. Wie / 
warum der HP6633 nicht reagiert, habe ich aber keine Ahnung.

Ich seh schon, ich muss mir demnächst mal noch einen GPIB-auf-LA-Adapter 
bauen. ;-)

von Dieter S. (ds1)


Lesenswert?

Zu PE des SN75160B gibt es in der Doku des TMS9914A ein paar Hinweise:

1
The Pull-Up Enable (PE) input of the SN75160 is an active high input
2
which selects whether the 'DIO(8-1)' lines are driven by open collector
3
or push/pull buffers. A push/pull buffer is required if faster data rates
4
are required and the 'stdl' and/or the 'vstdl' features are used.
5
Open collectors must be used if parallel polling is being used in a
6
particular GPIB environment. If only one of these features is desired
7
the PE input may be hardwired otherwise it must be derived from ATN and EOI.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Dieter S. schrieb:
> Zu den Problemen bei vielen Geräten am Bus: Vielleicht mal mit PE
> (Pullup Enable) des SN75160B experimentieren, eventuell ändert das was.

Der hat einen Pullup dran, müsste also standardmäßig aktiv sein, falls 
die Software das nicht irgendwie überschreibt (da habe ich noch nicht 
rein geschaut).

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> Dieter S. schrieb:
>> Zu den Problemen bei vielen Geräten am Bus: Vielleicht mal mit PE
>> (Pullup Enable) des SN75160B experimentieren, eventuell ändert das was.
>
> Der hat einen Pullup dran, müsste also standardmäßig aktiv sein, falls
> die Software das nicht irgendwie überschreibt (da habe ich noch nicht
> rein geschaut).

PE an einen gpio zu legen war eine "Eingebung" von mir. Die Firmware 
geht von einer fixen Verdrahtung aus.

73

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> PE an einen gpio zu legen war eine "Eingebung" von mir. Die Firmware
> geht von einer fixen Verdrahtung aus.

Damit sollten die Pullups am Bus aber dauerhaft aktiv sein, wenn ich das 
Zitat oben richtig verstehe.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> Hans W. schrieb:
>> PE an einen gpio zu legen war eine "Eingebung" von mir. Die Firmware
>> geht von einer fixen Verdrahtung aus.
>
> Damit sollten die Pullups am Bus aber dauerhaft aktiv sein, wenn ich das
> Zitat oben richtig verstehe.

Nein, ich bin mir ziemlich sicher, dass die konfiguration tristate und 
nicht open-drain ist.

73

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

mich irritiert immer noch das Schaltbild,
schaue ich auf
https://www.lcsc.com/datasheet/lcsc_datasheet_2501211440_hongjiacheng-H5VU25U_C7420374.pdf
gibt es keine Serien R und mehr Dioden nach + und -

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> mich irritiert immer noch das Schaltbild

Ja, und? Man hätte das Teil auch einfach nur als Blackbox in den 
Schaltplan zeichnen können, du musst eigentlich nur wissen, dass es ein 
Schutzdioden-Array ist. Für die reine Funktion der Schaltung ist das 
Teil doch komplett unerheblich.

Das Pseudo-Schaltbild im Datenblatt dokumentiert beispielsweise auch 
nicht, dass der empfohlene Footprint Pin 1 und 8 miteinander verbindet.

von Joachim B. (jar)


Lesenswert?

Jörg W. schrieb:
> Für die reine Funktion der Schaltung ist das
> Teil doch komplett unerheblich

mir war aber so als wenn du Probleme mit der Ansteuerung von mehreren 
GPIB Geräten hast und da der ESP eben nicht 5V fähig ist schaut man 
woran es liegen könnte und da sehe ich als Ungereimtheiten.
Solange ich es nicht besser weiß wird eben dahin geschaut!
Man kann aber auch blind weiterraten.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> da der ESP eben nicht 5V fähig ist

Dass er das nicht ist, spielt doch hier keine Rolle. Das Diodenarray 
hängt am Bus, aber der ESP ist mit den 7516x-Treibern vom Bus 
entkoppelt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Jörg W. schrieb:
> Habe jetzt mal versucht, einen etwas größeren Bus damit aufzubauen, das
> war ziemlich fummelig (Aussuchen von "gängigen" Kabeln) und nur begrenzt
> möglich.

Allmählich kommt wohl Klarheit. ;-)

@Dieter kann es sein, dass bei deinem Arduino-Build die Optimierung zu 
wenig oder gar ganz ausgeschaltet war?

Wenn ich den PlatformIO-Build nehme und noch die nervigen Meldungen 
rauswerfen, während er im Listen-only-Modus auf Zeichen wartet, dann 
funktioniert jetzt schon recht viel, und es sieht auch so aus, als ob 
ich einen ordentlich langen Bus damit aufbauen kann.

Ich habe mal noch den alten HP54512B mit dran gehängt, neben dem HP6633B 
eines der Geräte, die auch SCPI machen – einige andere hier machen es 
nicht.

Das Problem beim HP6633B lag nur daran, dass mein Test im Terminal 
standardmäßig kein CR-LF sendet, das scheinen sie dort zu mögen. Mit 
einem manuellen CR-LF oder mit ++auto 2 reagieren sie beide auf *IDN?

Lediglich der Rückweg aus dem Listen-only ist nach wie vor etwas 
fummelig, da sehr oft die ++-Kommandos dort nicht akzeptiert werden. Mit 
mehrfachem copy&paste eines "++mode 1" geht es dann irgendwann. Wäre 
interessant, ob sich das noch irgendwie verbessern lässt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Wäre interessant, ob sich das noch irgendwie verbessern lässt.

Was mir dazu noch in den Sinn kam: die Modem-Interface-Signale sollten 
sich ja problemlos out of band verarbeiten lassen. Damit könnte man den 
Adapter zumindest durch ein Schließen des Host-Devices wieder aus dem 
listen / device mode wieder in den Grundzustand zurücksetzen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

@Hans Dieter (ds1) hatte einige Änderungen in den Code gebaut, die es 
u.a. auch erlauben, beim Bus-Timing kleine "settling times" einzufügen. 
Mit diesen Änderungen (und DC vom 75161 an IO45) funktioniert bei Dieter 
und bei mir jetzt alles – inklusive eines „gut besetzten“ Busses (6 
Geräte).

Ich habe Dieters Änderungen noch ein wenig aufgeräumt¹ und dir einen 
pull request daraus gemacht.

¹u.a. habe ich seinen Debugging-Code bei mir in einen eigenen Branch 
gesetzt und aus dem PR rausgelassen. Es gibt da auch schon andere 
Debug-Optionen, und nachdem auch bei ihm jetzt alles läuft, muss man das 
++debug ja vielleicht nicht unbedingt im primären Code haben.

: Bearbeitet durch Moderator
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Falls nochmal jemand drüber stolpern sollte: 
pymeasure.adapters.PrologixAdapter sollte man mit dem pyvisa-py backend 
benutzen:
1
from pymeasure.adapters import PrologixAdapter
2
3
adapter = PrologixAdapter("ASRL/dev/XXXX::INSTR", 13, visa_library="@py", timeout=1000)
Mit der normalen IVIVisaLibrary (ohne "visa_library=" Paramter) kracht 
es ansonsten:
1
Traceback (most recent call last):
2
  File "<stdin>", line 1, in <module>
3
  File "/home/joerg/.local/lib/python3.11/site-packages/pymeasure/adapters/prologix.py", line 106, in __init__
4
    super().__init__(resource_name,
5
  File "/home/joerg/.local/lib/python3.11/site-packages/pymeasure/adapters/visa.py", line 114, in __init__
6
    if_type = self.manager.resource_info(self.resource_name).interface_type
7
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
8
  File "/home/joerg/.local/lib/python3.11/site-packages/pyvisa/highlevel.py", line 3182, in resource_info
9
    ret, err = self.visalib.parse_resource_extended(self.session, resource_name)
10
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
11
  File "/home/joerg/.local/lib/python3.11/site-packages/pyvisa/ctwrapper/functions.py", line 2076, in parse_resource_extended
12
    ret = library.viParseRsrcEx(
13
          ^^^^^^^^^^^^^^^^^^^^^
14
AttributeError: 'IVIVisaLibrary' object has no attribute 'viParseRsrcEx'. Did you mean: 'viParseRsrc'?
https://github.com/pyvisa/pyvisa/issues/261

Scheint ein Bug in der VISA Library zu sein, dass sie eine Methode nicht 
implementiert haben, die dokumentiert ist.

von Jörg H. (idc-dragon)


Lesenswert?

Ich bin etwas spät dran, das Ding in Betrieb zu nehmen, nun versuche ich 
es aber. ;-)

Scheiterte bisher an PlatformIO, das hatte ich noch nicht. Nun habe ich 
es als VS Code Extension (unter Windows) installiert. Mit dem Repo von 
Hans habe ich die Rev 4 übersetzt und auch geflasht bekommen. Aber dann, 
was nun, wie soll sich das Gerät denn darstellen, als was für eine 
Schnittstelle?

Beim Anstöpseln an USB passiert augenscheinlich nichts. Der 
Windows-Gerätemanager zuckt nicht, ich sehe keine neue serielle 
Schnittstelle, kein Netzwerkinterface, im WLAN keinen neuen AP.

Sorry, habe noch keine Ahnung von GPIB-Adaptern. Gegoogelt habe ich den 
Eindruck, so ein Prologix-Clone sollte eine serielle Schnittstelle sein?

Edit: Habe UART-Pads gefunden und dran gemessen. Die Applikation kommt 
wohl nicht hoch, ich lese in schneller Folge (alle 218ms):
ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400262cf
SPIWP:0xee
mode:DIO, clock div:1
load:0x3ffe5110,len:0x1270
load:0x4004a000,len:0x4
load:0x4004a004,len:0xa04
load:0x4004e000,len:0x3540
entry 0x4004a15c

Hat jemand eine Idee? Ich habe nichts am geclonten Repo verändert.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Hast du die PCBs umgebaut bekommen oder hast du das selbst gemacht?

Falls du das selbst gemacht hast, prüf Mal ob du nicht vergessen hast 
die beiden Widerstände in der Versorgung zu Brücken.

Übrigens habe ich den Arduino code auf Stand gebracht... Irgendwas ist 
dabei aber komisch... Mein Rohde SMY01 liefert mit der neueren Revision 
eine falsche Response auf IDN...

Ich muss da aber noch herausfinden ab welcher Revision das Problem 
Auftritt. Könnte aber auch mit der Umstellung auf tinyusb sein, damit 
ich die Mac Adresse als usb-seriennummer setzen kann...

73

: Bearbeitet durch User
von Jörg H. (idc-dragon)


Lesenswert?

Ich hatte es selbst umgebaut. Den Widerstand R14 habe ich durch einen 
mit 0 Ohm ersetzt.
Gerade nocmal mit dem Oszi gesucht, ob die Spannungen stabil sind, 
scheint aber der Fall zu sein. Ich habe nichts gefunden, was sich 
synchron zu dieser 218ms Boot-Loop bewegt.
Edit:
Die beiden großen Tranceiver-Chips werden handwarm, ist das normal?

: Bearbeitet durch User
von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ja, die werden tatsächlich gut warm.

Am ehesten passt was mit der Firmware nicht... Also z.b falscher Chip 
gewählt.

Probier mal meine Arduino Firmware...die wird imho ohnehin regelmäßiger 
gewartet.

https://github.com/WilheJo-Org1/AR488/commit/33b4f1b4e589c14d27f53c5d96d2ea9f9de14243 
die revision geht mit allen meiner Geräte..die neueste erwirft bei mir 
am SMY01 den 1. Buchstaben beim IDN Kommando.
Ich hätte das Update im Nachhinein in einem eigenen branch machen 
sollen...

73

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Probier mal meine Arduino Firmware...die wird imho ohnehin regelmäßiger
> gewartet.

Ist auch meine Empfehlung, die funktioniert insgesamt besser.

Hans, ich hatte dir einen Pullrequest dafür gemacht, auch dank Dieters 
Korrekturen. Essenziell ist der Hardware-Umbau bezüglich des DC-Signals, 
wenn man das Teil nicht nur als Controller, sondern auch als Device 
benutzen will. Das funktioniert nur nach dem Umbau.

Ansonsten habe ich noch einen intensiven Dialog mit Dieter hinsichtlich 
der Plot-Funktion meines Advantest R4136, aber das Problem dort scheint 
tatsächlich die Firmware des Spekkis bzw. der darin enthaltene TMS9914 
zu sein.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Tatsächlich... Hab ich übersehen, sorry!

Montag ist bei mir eng.. ich Versuch am Dienstag per disect das Problem 
mit dem SMY01 einzugrenzen, dann übernehme die natürlich und schau, dass 
das ggf auch Richtung upstream weitergeht.

Ich hoffe, dass ist keine Limitierung durch den tinyusb Stack... Die 0 
bei der Seriennummer ist leider der IDF geschuldet und die will ich im 
arduino-kontext nicht angreifen... Leider ist da kein Hook vorgesehen, 
damit man die beim Starten dynamisch setzten kann.

73

von Dieter S. (ds1)


Lesenswert?

Eigentlich ist es ja kein Problem des AR488 bzw. des Advantest R4136 
oder TMS9914. Es liegt an der Anwendung:

- AR488 ist "Controller" und sagt dem "Device" Advantest R4136 dass die 
Screen Daten auf den Plotter ausgegeben werden sollen.

- AR488 schaltet von "Controller" auf "Device" um damit er als Plotter 
die Daten empfangen kann.

- Advantest R4136 schaltet annähernd gleichzeitig von "Device" auf 
"Controller" um damit er die Daten an den Plotter senden kann. Das 
klappt nicht weil wohl der AR488 noch "Controller" ist.

von Jörg H. (idc-dragon)


Lesenswert?

OK, nach Installation der Arduino IDE habe ich den Commit probiert. 
Lässt sich übersetzen und flashen, danach kommt ähnlich wie bei 
PlatformIO noch ein Fehler weil die USB-serielle Schnittstelle des 
Bootloaders verschwindet. Es gibt keine Boot Loop mehr, die Meldung auf 
dem UART sehe ich nur einmal.
Was für ein Board soll ich denn auswählen?
Ich habe bisher diese ausprobiert:
ESP32S2 Dev Module
ESP32S2 Native USB
Mit dem ersten sehe nach Start ich ein paar Zeichen Schrott auf dem 
UART, mit dem zweiten nichts.

Nochmal: Was sollte denn passieren, was für eine Schnittstelle entsteht 
ggf.? Ich habe das Board lose auf dem Tisch, kein GPIB angeschlossen, 
ist das vielleicht Voraussetzung?

von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

Hans hat die Konfiguration für die Arduino IDE doch dokumentiert (das 
Bild im Anhang ist von seiner Seite dazu).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Die 0 bei der Seriennummer ist leider der IDF geschuldet und die will
> ich im arduino-kontext nicht angreifen... Leider ist da kein Hook
> vorgesehen, damit man die beim Starten dynamisch setzten kann.

Ja, das hatte ich auch schon gesehen. Ist nicht so tragisch, solange man 
nur einen davon im System hat.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Dieter S. schrieb:
> Eigentlich ist es ja kein Problem des AR488 bzw. des Advantest R4136
> oder TMS9914.

Ja, gut. Das Problem das R4136 ist eher, dass es keine Funktion gibt, 
den Plot normal als Device zu starten, sondern halt nur, indem man die 
Tastenfunktionen via GPIB sendet.

Aber danke auch hier mal für deine Hilfe, Dieter!

von Soul E. (soul_eye)


Lesenswert?

Jörg H. schrieb:
> Nochmal: Was sollte denn passieren, was für eine Schnittstelle entsteht
> ggf.? Ich habe das Board lose auf dem Tisch, kein GPIB angeschlossen,
> ist das vielleicht Voraussetzung?

Ein COM-Port, bzw /dev/tty.

Das funktioniert auch ohne Gerät am Bus. Über Terminal "++ver\r\n" 
senden sollte eine Antwort liefern.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jörg H. schrieb:
> Nochmal: Was sollte denn passieren, was für eine Schnittstelle entsteht
> ggf.?
1
ugen4.9: <Espressif Systems ESP32S2DEV> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)

Details:
1
ugen4.9: <Espressif Systems ESP32S2DEV> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
2
ugen4.9.0: umass0: <TinyUSB MSC>
3
ugen4.9.1: umodem0: <TinyUSB CDC>
4
5
  bLength = 0x0012 
6
  bDescriptorType = 0x0001 
7
  bcdUSB = 0x0200 
8
  bDeviceClass = 0x00ef  <Miscellaneous device>
9
  bDeviceSubClass = 0x0002 
10
  bDeviceProtocol = 0x0001 
11
  bMaxPacketSize0 = 0x0040 
12
  idVendor = 0x303a 
13
  idProduct = 0x0002 
14
  bcdDevice = 0x0100 
15
  iManufacturer = 0x0001  <Espressif Systems>
16
  iProduct = 0x0002  <ESP32S2_DEV>
17
  iSerialNumber = 0x0003  <0>
18
  bNumConfigurations = 0x0001
Ist jetzt die Ausgabe von usbconfig auf FreeBSD, aber ich denke, die 
wesentlichen Details kann man erkennen. Insbesondere entsteht halt ein 
"umodem0" (CDC) sowie ein "umass0" (MSC).

von Jörg H. (idc-dragon)


Lesenswert?

War mir klar, dass das an irgendeinem Punkt peinlich für mich wird... 
;-)

Dieter S. schrieb:
> Hans hat die Konfiguration für die Arduino IDE doch dokumentiert (das
> Bild im Anhang ist von seiner Seite dazu).

Aha, danke, habe ich erstens übersehen und wusste zweitens nicht, dass 
das bei Arduino so üblich ist. (Scheint auch versionsabhängig zu sein, 
bei mir ist mindestens die Sortierung anders.)
Zwei Punkte waren unterschiedlich, "USB CDC on Boot" und "Upload Mode".
Nun habe ich auch nach dem Bootloader noch einen COM-Port.

Soul E. schrieb:
> Ein COM-Port, bzw /dev/tty.
>
> Das funktioniert auch ohne Gerät am Bus. Über Terminal "++ver\r\n"
> senden sollte eine Antwort liefern.

Aha, danke.
Prima, mein neuer Port liefert die Antwort "AR488 GPIB controller, ver. 
0.51.29 (JW), 29/01/2025".
Dann kann der Spaß ja losgehen.

von Dieter J. (djac)


Angehängte Dateien:

Lesenswert?

Ich bin erst jetzt dazu gekommen, den AR488 in mein Messprogramm
einzubinden und sodann gründlich zu testen. Zuvor hatte ich
jahrelang den Prologix Ethernet-Controller benutzt, der stets
völlig zuverlässig arbeitete.

Direkt gab es mit dem neuen AR488 jede Menge Probleme, das
Messprogramm wollte nur mit einigen Geräten fehlerfrei
zusammenarbeiten. Deshalb habe ich ein kleines Testprogramm
geschrieben um die Fehler eingrenzen, aber auch, um
die Performance des AR488 mit dem Prologix vergleichen zu
können.

Für einen Teil der Probleme war auch mein Messprogramm
verantwortlich, aber der Fehler konnte mit dem Prologix aus
bestimmten Gründen nicht auftreten.

Nach Beseitigung des Fehlers ergab sich bei den 5 getesteten
Geräten folgendes Bild:

Das Senden über den AR488 zum Gerät arbeitet fehlerfrei.

Beim Lesen mit ++read 10 ergab sich folgende Situation:

Mit Prologix:
1
     # Die Zahlen sind eine Zeitmarke in s
2
     0.041375 ->: b'arm;wait;c1:pava? rms\n'
3
       # triggercmd wavepro950
4
     5.041678 ->: b'++read 10\n'
5
     5.041745 getnl start
6
       # Routine zum Einlesen von USB
7
     5.045165 read: bytearray(b'RMS,216.5E-3,OK\n\n')
8
       # Ergebnis
9
     5.045310 readtime=0.003541, nbr read calls=1
10
       # Auswertung
11
     5.045345 <-: bytearray(b'RMS,216.5E-3,OK')

Mit AR488:
1
   610.510249 ->: b'arm;wait;c1:pava? rms\n'
2
   615.510495 ->: b'++read 10\n'
3
   615.510550 getnl start
4
   615.512468 read: bytearray(b'R')
5
   615.512539 read: bytearray(b'RM')
6
   615.512677 read: bytearray(b'RMS')
7
   615.512939 read: bytearray(b'RMS,')
8
   615.513471 read: bytearray(b'RMS,2')
9
   615.513558 read: bytearray(b'RMS,216')
10
   615.513660 read: bytearray(b'RMS,216E')
11
   615.513832 read: bytearray(b'RMS,216E-')
12
   615.513962 read: bytearray(b'RMS,216E-3')
13
   615.514123 read: bytearray(b'RMS,216E-3,')
14
   615.514297 read: bytearray(b'RMS,216E-3,O')
15
   615.514652 read: bytearray(b'RMS,216E-3,OK\n')
16
   615.514715 readtime=0.004158, nbr read calls=12
17
   615.514740 <-: bytearray(b'RMS,216E-3,OK')

Der time stamp ist in Sekunden mit einer Auflösung von 1µs und mit
der Funktion getnl wird das Ergebnis eingelesen. Im Unterschied zum
Prologix kommt die Antwort nicht in einem kompletten Rutsch sondern
die Bytes kommen mehr oder weniger einzeln an. Das ist offensichtlich
ungünstig auf dem AR488 programmiert.

Dennoch sind die Gesamtzeiten mehr oder weniger identisch und liegen
bei etwa 4ms. Das ist für die Transferzeit ein durchaus brauchbarer
Wert, wenn man bedenkt, wie lange z.B. ein Voltmeter braucht,
um einen Wert zu messen: bei höheren Genauigkeiten im Sekundenbereich.

Eine nähere Inspektion ergab dann, dass dies an der internen
Verarbeitung des ++read liegt, das kann man beim AR488 auch an der
Differenz der time stamps zwischen "start getnl" und Eintreffen des
1. Zeichens im Vergleich zu den weiteren Differenzen erkennen.

Nun gut, nicht optimal, aber beileibe kein Beinbruch. Man muss das
nur wissen, damit es beim Programmieren keine unerwarteten Resultate
gibt.

Beim auto ++auto 1 gibt es ein gemischtes Bild und es hängt auch noch
von dem Ort ab, an welcher Stelle man es einsetzt.

Um das zu verstehen, eine kurze Ablaufbeschreibung des Testprogramms
1
# main() und darin I/O init
2
# send config_controller, Kommandosequenz ar488 betreffend
3
# send ++auto 1, if auto == "once"
4
# send config_dev, Initialisierung einer Messart
5
# LOOP
6
#   send ++auto 1, if auto == "beforetrigger"
7
#   send triggercmd, Kommando zur Einleitung einer Messung
8
#   wait waittime
9
#   send ++read 10 or ++auto 1, if auto == "no" or auto == "beforereading"
10
#   read result with function getnl
11
#   send ++auto 0, if auto == "beforetrigger" or auto == "beforereading"
12
# END LOOP

Das auto 1 ist ohnehin problematisch, weil es Geräte gibt, die eine
Fehlermeldung ausgeben, wenn ein Kommando keinen Rückgabewert hat.
Von daher kommt eigentlich nur die Methode "beforereading" in Betracht,
also das Anschalten vor dem Lesen und ein Ausschalten direkt danach.

Das "beforereading funktioniert mit dem AR488 bei allen getesteten 
Geräten
nicht.

"beforetrigger" funktioniert bei 3 von 5 Geräten nicht, "once" bei 1 
nicht.

Beim Prologix hingegen funktionieren bei allen Geräten alle 
Betriebsarten
ohne Probleme.

Also sollte man beim Programmieren auf ++auto verzichten, zu 
unzuverlässig,
mal blockiert das getnl, mal kommt Datenmüll und hin und wieder 
funktioniert
es. Beim interaktiven Einsatz ("once") sollte es normalerweise 
funktionieren.

Ich vermute, dass dieser Fehler nicht esp32 spezifisch, sondern im
allgemeinen Programmteil lokalisiert ist. Dass deshalb, weil ich bei 
einem
Chinaclone des Prologix ähnliche Fehler bei auto feststellen kann.
Ansonsten sehr schön klein, ist in einem Stecker für ein GPIB Kabel
eingebaut und hat eine bessere Performance als Prologix und AR488.

Es hat eine Transferzeit von 1,7ms und kostete vor ca. 5 Jahren etwa 40€
beim Ali.

Das Testprogramm in Python anbei.

Gruß Dieter

: Bearbeitet durch Moderator
von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Dieter J. schrieb:
> Ich vermute, dass dieser Fehler nicht esp32 spezifisch

Tatsächlich läuft die Diskussion zur Firmware hier:
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

Bisher habe ich die Internas nur grob überflogen.
Dort werden solche Reports aber recht schnell beantwortet.

Zum Transfer Speed... Da könnte mit dem tiny-usb Stack ggf noch Luft 
sein. Immerhin kann man dann Transferarten, Paketgrößen,... 
beeinflussen.

Mit dem pull-request müsste man ja mit 2 AR488 Daten im Kreis schicken 
können... Da sollte sich dann ein Unterschied zeigen.

Jörg W. schrieb:
> Hans W. schrieb:
>> Die 0 bei der Seriennummer ist leider der IDF geschuldet und die will
>> ich im arduino-kontext nicht angreifen... Leider ist da kein Hook
>> vorgesehen, damit man die beim Starten dynamisch setzten kann.
>
> Ja, das hatte ich auch schon gesehen. Ist nicht so tragisch, solange man
> nur einen davon im System hat.

Ich habe oft 2-3 auf einmal in Betrieb.
Gerade bei der Geschwindigkeit hilft das extrem, weil man beim 
Umschalten zwischen geräten am Bus einfach zuviel Overhead produziert.

73

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Die 0 bei der Seriennummer ist leider der IDF geschuldet und die will
> ich im arduino-kontext nicht angreifen..

Ich weiß gar nicht, was sich jetzt geändert hat, ich habe nach deinen 
letzten Merges versucht, Dieters Änderungen zu aktualisieren. Nach dem 
Flashen jetzt:
1
ugen4.9: <Twilight-Logic AR488> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
2
ugen4.9.0: umodem0: <TinyUSB CDC>
3
4
  bLength = 0x0012 
5
  bDescriptorType = 0x0001 
6
  bcdUSB = 0x0200 
7
  bDeviceClass = 0x00ef  <Miscellaneous device>
8
  bDeviceSubClass = 0x0002 
9
  bDeviceProtocol = 0x0001 
10
  bMaxPacketSize0 = 0x0040 
11
  idVendor = 0x303a 
12
  idProduct = 0x0002 
13
  bcdDevice = 0x0053 
14
  iManufacturer = 0x0001  <Twilight-Logic>
15
  iProduct = 0x0002  <AR488>
16
  iSerialNumber = 0x0003  <D8:3B:DA:C3:D8:D2>
17
  bNumConfigurations = 0x0001

Es ist kein umass0 (MSC) mehr da, aber dafür eine Seriennummer.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Eine weitere Beobachtung: ++spoll crasht die Firmware (reboot, wie bei 
++rst). Weiß nicht, ob das nur meinen lokalen Build betrifft, aber es 
ist reproduzierbar.

Ansonsten scheint die Firmware mit den aktualisierten Änderungen von 
Dieter wieder so zu funktionieren wie vorher (Branch "ds1_fixes" in 
meinem Repo).

Ich werde noch ein wenig vergleichen und testen und dann gelegentlich 
den pull request neu stellen.

: Bearbeitet durch Moderator
von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Hast du vllt vorher das msd-on-boot flag in der arduino die ein gehabt?

Ja, ich habe jetzt Code im master eingefügt der automatisch cdc über 
tinyusb nutzt wenn cdc-on-boot deaktiviert ist. Dabei nutze ich eine 
der Mac Adressen als Seriennummer und setze die Strings auf sinnvolle 
werte.

Aber vorsicht, der Master liefert bei mir eine korrupte Response auf IDN 
bei meinem R&S SMY01. Die letzte funktionierende Version ist 0.52.26 von 
Mitte März. Debug Daten habe ich schon generiert - issue ist aber noch 
nicht geschrieben...


Eure Patches habe ich in einen branch gezogen. Der merge mit dem 
master-branch ist aber ziemlich schwierig. Da hat sich wirklich viel an 
der Code
strukz  verändert...

73

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Hast du vllt vorher das msd-on-boot flag in der arduino die ein gehabt?

Möglich

> Ja, ich habe jetzt Code im master eingefügt der automatisch cdc über
> tinyusb nutzt wenn cdc-on-boot deaktiviert ist. Dabei nutze ich eine
> der Mac Adressen als Seriennummer und setze die Strings auf sinnvolle
> werte.

Das ist auf jeden Fall ein Fortschritt. Da ich bei mir semi-permanente 
Gerätenamen für die seriellen USB-Schnittstellen generiere (ähnlich wie 
Linux /dev/serial/by-id), kommt da jetzt ein sinnvoller Name raus.

> Aber vorsicht, der Master liefert bei mir eine korrupte Response auf IDN
> bei meinem R&S SMY01.

Müsste ich nochmal bei den Geräten gucken, die bei mir SCPI-kompatibel 
sind. Die meisten sind es nicht.

Funktioniert bei dir ++spoll, oder crasht das ebenfalls?

> Eure Patches habe ich in einen branch gezogen. Der merge mit dem
> master-branch ist aber ziemlich schwierig. Da hat sich wirklich viel an
> der Code
> strukz  verändert...

Daher habe ich ja gestern Abend selbst mal versucht, das anzugleichen. 
Insbesondere ist ja jetzt aus setGpibState() ein setGpibCtrlDir() und 
setGpibCtrlState() geworden.

Die Anordnung der Dokumentation scheint sich auch geändert zu haben, da 
habe ich Dieters Ergänzungen allerdings in meinem Branch noch nicht 
nachgezogen.

von Thomas Z. (usbman)


Lesenswert?

Jörg W. schrieb:
> Es ist kein umass0 (MSC) mehr da, aber dafür eine Seriennummer.

Die SN ist so nicht in Ordnung. MSC macht Einschränkungen wie die SN 
auszusehen hat. (max 12 Zeichen, keine Sonderzeichen)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Thomas Z. schrieb:
> Die SN ist so nicht in Ordnung. MSC macht Einschränkungen wie die SN
> auszusehen hat.

Ist egal, es gibt ja kein MSC mehr, nur noch ein CDC.

von Ronny H. (rhb)


Lesenswert?

Da das ja urprünglich mal ein Markteintrag war (und ich zu spät):
Meine Adapter von Hans- die ich jetzt erst angefragt habe sind auch 
angekommen (einige wenige hat/te er noch) - vielen Dank!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Aber vorsicht, der Master liefert bei mir eine korrupte Response auf IDN
> bei meinem R&S SMY01. Die letzte funktionierende Version ist 0.52.26 von
> Mitte März. Debug Daten habe ich schon generiert - issue ist aber noch
> nicht geschrieben...

Hast du da irgendein Update?

Diese Version crasht konsistent bei einem ++spoll.

Ohne Dieters Patches geht der device mode nicht, mit den Patches 
funktioniert meine Plotter-Emulation, solange ich "++lon 1" benutze. 
Mein Spekki versucht aber eigentlich, den Plotter auf Adresse 5 
anzusprechen. Wenn ich statt "++lon 1" dann mit "++addr 5" im device 
mode arbeite, crasht die Firmware ebenfalls. Ich vermute mal, dass das 
nicht mit Dieters Patches zusammenhängt sondern die gleiche Ursache hat 
wie der Crash beim serial poll.

Wie würde man den Crash debuggen, da muss ich dann eine serielle Console 
anklemmen, oder?

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ich habe kürzlich 2 unserer Boards nach UK gesendet, damit sich 
waveydipol das genauer ansehen kann.
An der Plotter emulation ist er übrigens auch sehr interessiert...

Kannst du wegen der von dir entdeckt Probleme auch ein issue im 
twighlight-logic ar488 repo machen? Ich hab dein Problem zwar erwähnt - 
ich befürchte aber, dass könnte ohne issue untergehen...

Ich hoffe das Packerl wird demnächst zugestellt... Ist schon 7 Tage 
unterwegs...

73

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> Wie würde man den Crash debuggen, da muss ich dann eine serielle Console
> anklemmen, oder?

Ich bin mir nicht sicher wie man das aktiviert, es sollte aber mit dem 
s3 möglich sein per USB jtag debug zu machen...angeblich auch mit 
parallelem cdc device.

Ansonsten gibt's auch semi-hosted gdb Server über uart... Habe ich aber 
auch noch nicht verwendet.

73

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:

> An der Plotter emulation ist er übrigens auch sehr interessiert...

Ist eigentlich gar nicht so sehr besonders. Man muss halt auf Traffic 
auf dem Bus hören. Im Moment im listen-only mode, als eine Art 
"sniffer". Wenn es funktionieren würde, müsste es sogar direkt 
adressiert funktionieren, weil mein Analyzer das nach Adresse 5 sendet.

Der Rest ist dann eine sinnvolle Ende-Erkennung; kann man mit Timeout 
machen, im Moment mache ich es, indem ich stoppe, wenn ich den String 
"PA00000,00000" gesehen habe, der bei mir das Ende der Plot-Daten 
kennzeichnet.

Danach übergibt man das, was man eingesammelt hat, an hp2xx, was daraus 
ein PNG macht.

> Kannst du wegen der von dir entdeckt Probleme auch ein issue im
> twighlight-logic ar488 repo machen?

https://github.com/Twilight-Logic/AR488/issues/62

Mal gucken, ob ich mir das mit dem Debuggen antun will. Heute Abend 
nicht mehr. ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Jörg W. schrieb:
>> Wie würde man den Crash debuggen, da muss ich dann eine serielle Console
>> anklemmen, oder?
>
> Ich bin mir nicht sicher wie man das aktiviert, es sollte aber mit dem
> s3 möglich sein per USB jtag debug zu machen...angeblich auch mit
> parallelem cdc device.

Ist das Teil jetzt kompatibel zu einem ESP32S2 oder ESP32S3?

Wenn ich einen S2 auswähle, dann möchte das OpenOCD einen externen 
JTAG-Debugger sehen (welches im einfachsten Falle ein MPSSE-fähiger FTDI 
sein kann). Aber ich fürchte, die JTAG-Pins haben wir beim AR488 nicht 
frei, oder?

Wenn ich den S3 auswähle, sagt er mir, dass er kein passendes Gerät 
findet.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Eine weitere Beobachtung: ++spoll crasht die Firmware

War jetzt gar nicht so schwierig zu finden und zu reparieren. ;-)

https://github.com/WilheJo-Org1/AR488/pull/5

Habe auch noch einen PR für Dieters Modifikationen gemacht. Der trennt 
insbesondere die idle states in "controller idle" und "device idle" auf, 
weil beide eine (teilweise) separate Behandlung notwendig machen. 
Außerdem führt er noch zwei Kommandos ein, mit denen man die 
Vorhaltezeit für Senden oder Empfangen konfigurieren kann.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Aber @Hans, um es nochmal ganz explizit zu schreiben: ich bin dir 
außerordentlich dankbar für die Initiative und das Projekt. Was bei mir 
inzwischen damit läuft ersetzt vollständig und erweitert meine früheren 
GPIB-Setups.  Es ist auch wirklich gut, dass die 7516x-Interface-ICs da 
noch reingekommen sind, damit lässt sich problemlos selbst ein größerer 
Bus handhaben.

Ich habe ja auch noch den USBTMC mitgenommen damals. Eigentlich weiß ich 
jetzt schon gar nicht mehr richtig, wofür ich den noch brauche, so gut, 
wie der AR488 inzwischen funktioniert. ;-)

Alles, was ich da inzwischen als PRs eingetütet habe, versteht sich als 
mein kleiner Beitrag zur Weiterentwicklung des Projekts insgesamt.

von Ronny H. (rhb)


Lesenswert?

Dieter J. schrieb:
> Nach dem ++id name tty-esp32-<Nr> darf man ein ++savecfg nicht
> vergessen,

Bei mir funktioniert ein ++savecfg nicht: "EEPROM not supported."
Liegt daran, dass "E2END" in ar488.ino nicht definiert ist. Ändert man 
das, scheint ein Speichern zu funktionieren. Beim Neustart sind die 
Einstellungen jedoch verschwunden. Ich bin zwar kein Programmierer, aber 
ich denke das liegt an der Art der Speicherung  mit 
EEPROM.put(addr,cfgdata);
das "put" bestimmt per "sizeof", wieviele Daten gespeichert werden. Da 
cfgdata jedoch nur ein Pointer ist, wird nur der Pointer gespeichert und 
nicht die cfgsize-Bytes, auf die er zeigt. Wenn ich nun das über eine 
Schleife mache (natürlich auch das Lesen), funktioniert es:

 for (i=0; i<cfgsize; i++){
    EEPROM.write(i+EESTART,cfgdata[i]);

Der Code ist allerdings auch im upstream "Twilight-Logic/AR488"-Repo 
vorhanden und kann meiner Meinung nicht so funktionieren. Ich denke, ich 
mache da mal ein Issue auf.

von Ronny H. (rhb)


Lesenswert?

und dort schon gefixt, das ging schnell

Ronny H. schrieb:
> Der Code ist allerdings auch im upstream "Twilight-Logic/AR488"-Repo
> vorhanden und kann meiner Meinung nicht so funktionieren. Ich denke, ich
> mache da mal ein Issue auf.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Sorry, dass ich hier so spärlich schreibe... Aber der thread 
verschwindet in dem Forum einfach zu schnell von der main-page....


Danke für alle fixes!

Der Problem mit dem 1. Zeichen beim IDN sollte nun upstream gefixt 
sein...aber anscheinend macht der esp32 neuerdings Probleme mit dem 
Arduino weil irgendwas im Hintergrund umgedreht würde...zumindest gibt's 
in UK da sehr seltsames verhalten...der Controller meldet sich per USB, 
gibt aber nix aus.

Wie dem auch sei, ich werde das Anfang nächster Woche mir anschauen, 
alles Merten und upstream weitergeben.

73

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich sehe, dass im Twilight-Logic-Repo einige meiner Vorschläge 
akzeptiert und umgesetzt worden sind. Es lohnt sich also, sich mit den 
Details zu beschäftigen und auch Bugfixes einzureichen. ;-)

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Sooo... ich habe mal alle repos wieder (im DC-pin-feature Branch) 
zusammengeführt.

Leider ist es immer noch so, dass ich am Rode&Schwarz SMY01 vom IDN 
Befehl das 1. Zeichen nicht bekomme.

Das geht mit einer älteren Version problemlos... ich bin da noch in 
Abklärung wo das Problem tatsächlich liegt... mit meinem SMIQ06 geht es 
jedenfalls.

Bei mir compiliert übrigens upstream gerade nicht... das liegt an einer 
falschen forward-declaration in der AR488_Eeprom.cpp.

Ich habe jetzt auch support für ein Composite-Device mit 2 CDC devices.
Beispielsweise ist dann ttyACM0 für die eigentliche Kommunikation 
zuständig und ttyACM1 bekommt die Debug-Ausgaben.

73

: Bearbeitet durch User
von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

OK https://github.com/WilheJo-Org1/AR488 ist jetzt wieder synchron mit 
upstream.

zumindest bei mir ist das Problem mit dem SMY01 gefixt.
++read habe ich nebenbei auch wieder funktional gemacht... da war auch 
ein bug drinnen.

73

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
Noch kein Account? Hier anmelden.