Da fällt mir ein: das HP6633 wollte mit dem AR488 gar nicht reden. Hab den USBTMC dann dafür genommen.
Zu den Problemen bei vielen Geräten am Bus: Vielleicht mal mit PE (Pullup Enable) des SN75160B experimentieren, eventuell ändert das was.
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
> 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
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.
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. ;-)
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. |
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).
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
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.
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
Angehängte Dateien:
-
H5VU25U_small.jpg
8,4 KB -
H5VU25U_small2.jpg
7,4 KB
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 -
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.
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.
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.
Angehängte Dateien:
-
plot-advantest.png
3,2 KB -
plot-hp54512.png
2,9 KB
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.
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.
@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
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.
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.
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
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
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
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.
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
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.
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?
Angehängte Dateien:
-
ArduinoTargetConfig.png
63 KB
Hans hat die Konfiguration für die Arduino IDE doch dokumentiert (das Bild im Anhang ist von seiner Seite dazu).
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.
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!
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.
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).
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.
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
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
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.
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
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
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.
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)
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.
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!
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?
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
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
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. ;-)
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.
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.
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.
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.
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.
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
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. ;-)
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
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
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.