Ich möchte den Funktionsgenerator Keysight 33622A über den PC konfigurieren. Dazu stellt der Hersteller Code Beispiele für C# zur Verfügung. Siehe: https://www.keysight.com/main/editorial.jspx?cc=DE&lc=ger&ckey=887951&nid=-35258.536894470&id=887951 VISA: Waveform Download using C# This sample program downloads to and executes an arbitrary waveform from the Keysight 33220A. Ich habe das Programm für mein Gerät angepasst. Verbindung mit dem Gerät wird aufgebaut, aber es wird eine Fehlermeldung (siehe Anhang) ausgegeben, wenn die SCPI Commands gelesen werden. Hat jemand eine spontane Idee?
Angehängte Dateien:
-
Ergebnis_Breakpoint.PNG
96 KB -
20200720_150825.jpg
210 KB -
Ueberwachung.PNG
46 KB
Warum macht du einen neuen Thread auf? Beitrag "Keysight 33622A Waveform Generator c#" So allgemein würde es dir helfen dich mit den Grundlagen vertraut zu machen statt von irgendwo Code zusammen zu kopieren und schon Probleme zu haben die IDE richtig zu konfigurieren.
schau halt nach was der Status Code bedeutet und korigiere das (0xBFFF 0015)
Thomas Z. schrieb: > schau halt nach was der Status Code bedeutet und korigiere das (0xBFFF > 0015) meinst du damit die -107...
Genau das mein ich... Es geht ja schon das senden schief. Wie sieht dein SendString überhaupt aus? Ist das ein gültiges Kommando?
Ganz wichtig: 1. Keine Fehlercodes usw. durch die Applikation ausgeben lassen, sondern nur Schwurbeltext. 2. Fehlercodes niemals in einem Format darstellen, welches zur Fehlersuche im aktuellen Kontext geeignet wäre.
Andreas S. schrieb: > Ganz wichtig: Möglichst noch die Hauskatze mit auf das Foto der Fehler- Bildschirmausgabe bringen. Fehlermeldungen sind urheberrechtlich geschützt, daher ist Copy & Paste von Texten verboten!
oooops schrieb: > Möglichst noch die Hauskatze mit auf das Foto der Fehler- > Bildschirmausgabe bringen. Die Katze kann beim Debuggen helfen. Ernsthaft. Du erklärst ihr Deinen Code, Zeile für Zeile. Und da wo sie besonders nachdenklich guckt, da denkst Du auch nochmal nach. So findet man viele Fehler selber, weil man nochmal von aussen auf das Ganze schaut.
Angehängte Dateien:
-
Fehler_3.PNG
47 KB -
fehler_2.PNG
59 KB -
Fehler_1.PNG
48 KB -
Wait.PNG
27 KB
Ich habe das Programm nochmal durchgearbeitet. Thomas Z. schrieb: > schau halt nach was der Status Code bedeutet und korigiere das (0xBFFF > 0015) Timeout Expired Before Operation Completed Meine Vorgehensweise: herausfinden, wann, also nach welchem Schritt die Routine GetData, die für die Fehlermeldung verantwortlich ist und zig mal im Programm aufgerufen wird, Bauchschmerzen hat. Wenn ich mittels Einzelschritte das Programm laufen lasse, bekomme ich die Fehlermeldung -107... garnicht, sondern (Fehler 1-3). Das ist für mich der Hinweis, dass es noch weitere Probleme gibt -> ich nehme an, dass ich das Gerät mit falschen Werten füttere. Zurück zum Thema -107... Habe letztlich alle SCIP_Cmd nacheinander mit Haltepunkte versehen, um herauszufinden, ab wann der Überlauf nicht mehr auftritt. Er tritt nicht auf, wenn ich den Haltepunkt auf "Wait for reset to complete" lege (siehe Anhang wait). Error von remote interface tritt ebenfalls nicht mehr auf. Kurz: Entweder Zeile 343 oder 344 einen Haltepunkt, und der Überlauf passiert nicht. Woran liegt das?
Angehängte Dateien:
-
IO_Keysight.PNG
43 KB
ich habe die ersten drei Commands über die vom Hersteller zur Verfügung gestellte Bedienoberfläche ans gerät geschickt. auch hier gibt es DIE Fehlermeldung (siehe Anhang). Jetzt bin ich ratlos. Es liegt also nicht am Programm. Sehe ich den Wald lauter Bäumen nicht?
Klickst du bei "*RST" und "*CLS" auf "Send & Read"? Diese Kommandos senden nichts zurück und der Timeout-Fehler wäre normal. Bei "*OPC?" funktioniert es ohne Timeout-Fehler, da bekommst du auch eine Antwort.
Peter D. schrieb: > Klickst du bei "*RST" und "*CLS" auf "Send & Read"? Diese Kommandos > senden nichts zurück und der Timeout-Fehler wäre normal. Bei "*OPC?" > funktioniert es ohne Timeout-Fehler, da bekommst du auch eine Antwort. hab ich mir schon gedacht. Warum aber dann dieses Verhalten im Code? Dort sende ich und lese bewusst nicht...
noßßa schrieb: > Dort sende ich und lese bewusst nicht getData wird aufgerufen, wenn OPC? geschickt wird. Die Fehlermeldungen stimmen überein. Was sagt mir das jetzt?
Probiere eine Pause nach jedem Senden im Code einzufügen, vielleicht so 100 ms oder mehr.
:
Bearbeitet durch User
Je nachdem, wie "RST*" auf dem Gerät implementiert ist, gibt es anschließend ein kleines Päuschen, in dem der eigentliche Reset ausgeführt wird. Dabei können durchaus Zeichen abhandenkommen, z.B. das nachfolgende Kommando oder Teile davon. Dann gibt es eben ein Timeout. Daher ist dringend empfohlen, nach "RST*" eine Pause von ein paar 100 ms einzulegen.
Was sollen die Fehlermeldungen mit der NullReferenceException? Der Wert von VisaExample.ActiveForm ist null, es wird aber eine Referenz auf eine Form erwartet, auf der dann Refresh() aufgerufen werden soll. merciless
Dirk K. schrieb: > Was sollen die Fehlermeldungen mit der NullReferenceException? > Der Wert von VisaExample.ActiveForm ist null, es wird aber > eine Referenz auf eine Form erwartet, auf der dann Refresh() > aufgerufen werden soll. > > merciless das ist ja nochmal ein andere Thema...
Andreas S. schrieb: > Je nachdem, wie "RST*" auf dem Gerät implementiert ist, gibt es > anschließend ein kleines Päuschen, in dem der eigentliche Reset > ausgeführt wird. okay. Das ist ein Beispielcode für den 33220A, veröffentlicht von Keysight. Du meinst, dass die Befehle in ihrer Auswirkung je nach Gerät variieren können und ich somit für meinen konkreten Anwendungsfall eine Verzögerung einbauen soll? Hätte eigentlich erwartet, wenn Keysight den Code als Vorlage zur Verfügung stellt, ist er allgemein anwendwabr.
Im anderen Thread hast du geschrieben, dass die Programmierung nicht das Problem sei.... Ich sage jetzt mal dass genau das dein Problem ist. Programmieren besteht nicht daraus einfach Routinen ohne nachzudenken aufzurufen. Da ist etwas mehr Knowhow notwendig. Ansonsten bleibt ja noch die Möglichkeit das Ding mit dem Konfigurator zu bedienen.
Andreas S. schrieb: > Je nachdem, wie "RST*" auf dem Gerät implementiert ist, gibt es > anschließend ein kleines Päuschen, in dem der eigentliche Reset > ausgeführt wird. Dabei können durchaus Zeichen abhandenkommen, z.B. das > nachfolgende Kommando oder Teile davon. Dann gibt es eben ein Timeout. > > Daher ist dringend empfohlen, nach "RST*" eine Pause von ein paar 100 ms > einzulegen. ich will nicht sagen, dass du unrecht hast. Aber wenn ich deinen Ansatz weiter verfolge, ergeben sich mir viele Fragen: Warum hat der Hersteller nicht auf die Problematik hingewiesen? Wie viel Zeit ist nötig (100 MS? soll ich lieber 100 Sekunden sagen? od3er ein Jahr?)Wie kann ich sichergehen, dass andere Commands genug Zeit haben respektive abgearbeitet werden? Wenn tatsächlich die Zeit der entscheidende Faktor ist: warum wird nicht eine Rückmeldung vom Gerät erwartet, bevor der nächste Command gesendet werden darf (und nicht ein einfacher Send Befehl)?
noßßa schrieb: > Wenn tatsächlich die Zeit der > entscheidende Faktor ist: warum wird nicht eine Rückmeldung vom Gerät > erwartet, bevor der nächste Command gesendet werden darf (und nicht ein > einfacher Send Befehl)? ich schreibe ein bisschen durcheinander, bin müde. Ihr versteht schon. Übrigens Vielen Dank an die, die helfen!
noßßa schrieb: > Andreas S. schrieb: >> Je nachdem, wie "RST*" auf dem Gerät implementiert ist, gibt es >> anschließend ein kleines Päuschen, in dem der eigentliche Reset >> ausgeführt wird. > > okay. Das ist ein Beispielcode für den 33220A, veröffentlicht von > Keysight. Du meinst, dass die Befehle in ihrer Auswirkung je nach Gerät > variieren können und ich somit für meinen konkreten Anwendungsfall eine > Verzögerung einbauen soll? Ja. > Hätte eigentlich erwartet, wenn Keysight den > Code als Vorlage zur Verfügung stellt, ist er allgemein anwendwabr. Willkommen in der Realität.
Im Datenblatt steht wie lange das Gerät braucht um Kommandos auszuführen. Siehe "Programming times", z.B. Change function (meas) - 30 ms für USB, usw. Das der Reset-Befehl länger dauern kann, könnte man sich denken, da passiert ja einiges. Vielleicht muss auf Relais gewartet werden usw. Die Kommunikation mit dem Gerät passiert mit dem USB-TMC-Protokoll. Darüber sitzt dann die VISA-Bibliothek und vereinfacht die Kommunikation, dass muss man mitbedenken. Wenn du nicht weißt wann und wie Fehler zurückgegeben werden, oder ob und wie ein Timeout eingestellt wird, ist es halt einfacher vorerst jedes Kommando einzeln zu senden, kurze Pausen einzulegen und versuchen alle Rückgaben im Programmcode auf Fehler zu prüfen. Und die SCPI-Kommandos solltest du vollständig angeben, manchmal übersieht man sonst Fehler. Also statt "SOUR:FREQ 5000" dann ":SOUR1:FREQ 5000". Also mit "Root" (erster Doppelpunkt) beginnen, und z.B. Kanäle angeben. Probiere es einmal nur mit einen Command Line-Projekt, und frage die IDN ab "*IDN?". Wenn das funktioniert sollte alles weitere einfach sein.
:
Bearbeitet durch User
noßßa schrieb: >> Daher ist dringend empfohlen, nach "RST*" eine Pause von ein paar 100 ms >> einzulegen. > > ich will nicht sagen, dass du unrecht hast. Ich habe bereits mehrere kommerziell erhältlichen Geräte mit SCPI ausgestattet. > Aber wenn ich deinen Ansatz > weiter verfolge, ergeben sich mir viele Fragen: Zunächst einmal die Gegenfragen: 1. Hast Du überhaupt schon einmal das normative Dokument zu SCPI a) recherchiert, b) gelesen, c) verstanden? 2. Hast Du überhaupt schon einmal die normativen Dokumente zu IEEE 488.2 bzw. IEC 60488-2 a) recherchiert, b) gelesen, c) verstanden? 3. Hast Du überhaupt das exakt zu Deinem Gerät passende SCPI-Referenzhandbuch a) recherchiert, b) gelesen, c) verstanden? 4. Hast Du überhaupt die Dokumentation zur USB-Geräteklasse USBTMC a) recherchiert, b) gelesen, c) verstanden? 5. Hast Du überhaupt die Dokumentation zu NI VISA und ggf. die Umsetzung in Form der entsprechenden HP/Agilent/Keysight-Treiber a) recherchiert, b) gelesen, c) verstanden? Ich vermute ja sehr stark, dass Du nichts davon getan hast. Aus 10.32.1 folgt zwar eigentlich ziemlich klar, dass "*RST" keinen kompletten Gerätereset durchführen und auch nicht den Zustand einer IEEE 488.1-Schnittstelle ändern soll ("shall not"). Allerdings bedeutet dies nicht, dass der Zustand nicht geändert werden darf ("must not"). Außerdem ist die Formulierung "The state of the IEEE 488.1 interface" wörtlich zu nehmen. Du verwendest jedoch USB, vermutlich über die USBTMC-Klasse. In der Dokumentation zum Keysight 33622A finden sich leider auch keine entsprechenden Hinweise. Ganz im Gegenteil werden dort sogar durch Kommata getrennte, mehrfache Kommandos mit "*RST" aufgeführt. Offenbar kommt es hier zu Abweichungen zwischen der Dokumentation und der konkreten Implementierung der Gerätefirmware. > Warum hat der Hersteller nicht auf die Problematik hingewiesen? Entweder ist das beim Schreiben der Dokumentation durchgerutscht, ein Implementierungsfehler oder Tradition. > Wie viel Zeit ist nötig (100 MS? soll ich lieber 100 Sekunden sagen? > od3er ein Jahr?) Das musst Du ggf. experimentell bestimmen. Bei USB gegenüber IEEE-488.1 kommt hinzu, dass möglicherweise (und damit fälschlicherweise!) eine erneute Enumeration auf dem USB ausgelöst wird. Deren zeitlicher Ablauf wird überwiegend durch den USB Host bestimmt und weniger durch das Gerät. Eigentlich müssten dann auf Applikationsebene die Geräte-Handles ungültig werden, aber womöglich hat da jemand einen Workaround im Gerätetreiber eingebaut. Ggf. kannst Du ja nach dem "*RST" und einer kleinen Wartezeit auch selbst das Gerät pollen und die ggf. auftretenden Fehler korrekt behandeln. > Wie kann ich sichergehen, dass andere Commands genug Zeit haben > respektive abgearbeitet werden? Grundsätzlich gibt es bei SCPI auch die sog. "queued execution" mehrere Kommandos. Inwiefern diese bei Deinem Messgerät implementiert ist, musst Du selbst schauen. Willst Du jegliche Überlappung vermeiden, musst Du nach jedem Kommando ggf. mit "OPC" bzw. "*OPC?" die sequentielle Ausführung sicherstellen. Hierbei gilt es unbedingt die Bemerkungen unter 4.1.3.3 zu beachten, insbesondere dass nach einigen Kommandos (z.B. "*RST") OCIS ohne Setzen von NOP und Setzen von OPC im SESR eingenommen wird! > Wenn tatsächlich die Zeit der > entscheidende Faktor ist: warum wird nicht eine Rückmeldung vom Gerät > erwartet, bevor der nächste Command gesendet werden darf (und nicht ein > einfacher Send Befehl)? Zum einen ist das Verhalten in den obigen Dokumenten genau spezifiziert, was in den meisten Fällen (IEEE 488.1, USBTMC, LXI, VXI) auch eine zuverlässige Flusskontrolle beinhaltet. Bei EIA-232 hängt es von den korrekt eingestellten Schnittstellenparametern ab; auch USB-Geräte, die nur einen internen USB-UART-Wandler statt einer USBTMC-Implementierung enthalten, kann es zu Problemen kommen. Es empfiehlt sich bei allen EIA-232- bzw. UART-basierten Geräteanbindungen, zu Beginn der Kommunikation oder nach einem (wie auch immer gearteten) Geräte-Reset den hostseitigen Empfangspuffer zu leeren. Ggf. kann sonst entweder mal ein einzelnes Zeichen oder bei manchen Geräten auch eine Meldung des Bootloaders, z.B. "*RESET*", oder Teile davon auftauchen. Wie lange man den Empfangspuffer beobachten und leeren sollte, hängt von der maximalen Dauer des Bootvorganges ab. Meistens reicht hier aber etwas in der Größenordnung von einer Sekunde. "Mittendrin", d.h. ohne ein Reset-Kommando, muss man aber keine Störungen befürchten.
Peter D. schrieb: > Probiere es einmal nur mit einen Command Line-Projekt, und frage die IDN > ab "*IDN?". Wenn das funktioniert sollte alles weitere einfach sein. Ich habe schon einmal ein älteres Netzgerät (EA-PS 9036-350) erlebt, welches einen fiesen Firmware-Fehler enthielt. Sobald man mehrmals hintereinander "*IDN?" abfragte, ohne zwischendurch ein anderes Kommando zu senden, stürzte der IEEE-488-Controller ab. Da ich beim Herantasten an ein neues SCPI-basiertes Gerät eigentlich immer eine Folge von mehreren "*IDN?" schicke, war ich um so erstaunter. Es kostete mich etliche Stunden Fehlersuche, bis klar war, dass wirklich die Gerätefirmware fehlerhaft war und nicht mein Testprogramm. Der Grund, warum ich diesen IDN-Test überhaupt durchführe, besteht darin, dass ich ja selbst auch Geräte mit SCPI entwickele. Und das allererste Kommando mit Rückgabewert, das ich in solch einem Fall teste, ist eben "*IDN?". Damit lassen sich auch sehr schön die entsprechenden Low-Level-Schichten testen, z.B. Übertragungsfehler.
vielen Dank für die Infos, hat mich sehr gefreut. zu den Normen: die gucke ich mir mal an. Die Frage ist auch, ob es als Anwender überhaupt notwendig ist, sich im Detail mit diesen Sachen auseinanderzusetzen? Denn eigentlich ist das ganze nur Mittel zum Zweck... Andreas S. schrieb: > Hierbei gilt es unbedingt die Bemerkungen > unter 4.1.3.3 zu beachten, insbesondere dass nach einigen Kommandos > (z.B. "*RST") OCIS ohne Setzen von NOP und Setzen von OPC im SESR > eingenommen wird! kannst du mir das nochmal nerklären? habe ich nicht ganz verstanden
https://stackoverflow.com/questions/5449956/how-to-add-a-delay-for-a-2-or-3-seconds welche Möglichkeit für ein Delay würdet ihr wählen?
noßßa schrieb: > zu den Normen: die gucke ich mir mal an. Die Frage ist auch, ob es als > Anwender überhaupt notwendig ist, sich im Detail mit diesen Sachen > auseinanderzusetzen? Denn eigentlich ist das ganze nur Mittel zum > Zweck... Du hast (mindestens) ein konkretes Problem, welches auf die Kommunikation mit dem Gerät zurückzuführen ist. Folglich sind die betreffenden Dokumente essentiell für die Beurteilung. > kannst du mir das nochmal nerklären? habe ich nicht ganz verstanden Das ist in den entsprechenden Dokumenten.
Ich habe das USB-TMC- und SCPI-Protokoll selbst für einen Microchip PIC18F2550 programmiert. Und mit libusb-1.0 und PureBasic für den PC. Zusätzlich noch das VXI-11-Protokoll für die LAN-Verbindung. Für USB-TMC ist hier meine Literaturliste, findest du alles im Internet. Die ersten zwei Bücher sind nicht notwendig:
1 | ;- -- Literaturliste zu den Referenzen in den Kommentaren im Quelltext: |
2 | ; Bruhns - 'USB in der Messtechnik' von Henry Bruhns, 2008 Franzis Verlag GmbH, ISBN 978-3-7723-5509-7 |
3 | ; UsbComplete - USB Complete - Fourth Edition 2009 - Jan Axelson |
4 | ; Usb20 - Universal Serial Bus Specification Revision 2.0, 2000 |
5 | ; UsbTmc - Universal Serial Bus Test And Measurement Class Specification (USBTMC) Revision 1.0, 2003 |
6 | ; Usb488 - Universal Serial Bus Test And Measurement Class, Subclass USB488 Specification (USBTMC-USB488) Revision 1.0, 2003 |
7 | ; IEEE4881 - IEEE Standard Digital Interface For Programmable Instrumentation, 1988 |
8 | ; IEEE4882 - IEEE Standard Codes, Formats, Protocols And Common Commands, 1988 |
9 | ; IEEE4882-92 - IEEE Standard Codes, Formats, Protocols And Common Commands for Use With IEEE Std 488.1-1987, 1992 |
10 | ; SCPI - Standard Commands For Programmable Instruments (SCPI), Version 1999.0 |
Bevor du die IDN nicht mit einem Beispielcode abfragen kannst, wird dir die Literatur vorerst nicht weiterhelfen. Bei C# und VISA kann ich dir leider nicht helfen, das verwende ich nicht.
Das von Peter D. genannte Buch von Henry Bruhns ist sehr leicht verständlich und inhaltlich sehr präzise. Herr Bruhns war vor seiner derzeitigen Tätigkeit an der HAW Hamburg bei Rohde&Schwarz maßgeblich an der Entwicklung von SCPI und den entsprechenden geräteseitigen Implementierungen beteiligt. Es ist aber nicht zwingend erforderlich, das Buch als toten Baum zu kaufen. Bei mehreren Buchhändlern (z.B. Amazon) kann man auch viele Auszüge aus dem Buch finden.
Angehängte Dateien:
-
1_Sekunde.PNG
33 KB
ich danke euch nochmal! Also das Programm läuft jetzt, habe an der Problemstelle jeweils eine Sekunde delay eingefügt. Ob die anderen Commands abgearbeitet werden, kann ich zum jetzigen Standpunkt nicht beurteilen. Zum Thema Literatur und Normen: ich gucke mir das an. Aber ich sehe mich momentan noch nicht zu einem intensivem Studium gezwungen
nochmal zur Verzögerung: warum ist sie notwendig, wenn ich OPC? verwende (OPC? - Operation complete query Returns an ASCII "+1" when all pending overlapped operations have been completed. )
Damit ist die Thematik, dass die Befehle sich überlappen und Zeit zum Abarbeiten bracuhen, vom Tisch...
außerdem die Frage: ich habe alle Einstellungen zurückgesetzt. Wenn ich das Programm laufen lasse, sind alle Einstellungen übernommen. Ich bekomme aber die Fehlermeldungen 786. Blick ins Handbuch ergibt: 786 Not able to delete a built-in arb waveform 786 Specified arb waveform already exists ´Kann damit nichts anfangen. Was will man mir sagen?
noßßa schrieb: > außerdem die Frage: ich habe alle Einstellungen zurückgesetzt. > Wenn ich das Programm laufen lasse, sind alle Einstellungen übernommen. > Ich bekomme aber die Fehlermeldungen 786. Blick ins Handbuch ergibt: > > 786 Not able to delete a built-in arb waveform > > 786 Specified arb waveform already exists > ´Kann damit nichts anfangen. Was will man mir sagen? kann das der Hinweis sein, dass wieder einige Commands verschluckt wurden?...
noßßa schrieb: > nochmal zur Verzögerung: warum ist sie notwendig, wenn ich OPC? verwende Weil *RST oft einen echten Reset des Gerätes ausführt. Und in der Zeit ist die Kiste nicht ansprechbar. Da wird dann auch Dein *OPC? nicht angenommen. Wie lange der Reset dauert hängt vom Gerät ab. Das MSOX3054T vor meine Nase braucht über eine Minute dafür, das hatte anscheinend einen Spielautomaten in der Familie. Das Vorgängergerät MSO6054A war nach 10 Sekunden am Bus erreichbar. Wenn Deine Kiste sowas wie "Preset" hat, dann nimm das zum Normieren. *IFC senden, Preset-Kommando schicken, und dann für die Messung passend einrichten.
Soul E. schrieb: > Weil *RST oft einen echten Reset des Gerätes ausführt. Und in der Zeit > ist die Kiste nicht ansprechbar. Da wird dann auch Dein *OPC? nicht > angenommen. so wie ich das verstanden habe, nutzt man OPC? gerade dann, wenn die Kiste nicht ansprechbar ist. Und das Gerät meldet sich, bis alles abgearbeitet wurde. Deswegen auch "wait for reset to complete". OPC? wird ja nicht einfach verschluckt. Sonst würde ja CLS auch nicht ankommen, da Reset noch arbeitet. Ich weiß nicht, ob OPC? innerhalb einer bestimmen Zeitspanne beantwortet werden muss. Sonst ist diese wahrscheinlich einfach zu lang. Hat noch jemand etwas zu 786? was ich damit anfangen kann?
Peter D. schrieb: > Für USB-TMC ist hier meine Literaturliste, findest du alles im Internet. ist zum´Teil schon mehr als zwei Jahrzehnte alt Andreas S. schrieb: > Grundsätzlich gibt es bei SCPI auch die sog. "queued execution" mehrere > Kommandos. Inwiefern diese bei Deinem Messgerät implementiert ist, musst > Du selbst schauen. Willst Du jegliche Überlappung vermeiden, musst Du > nach jedem Kommando ggf. mit "OPC" bzw. "*OPC?" die sequentielle > Ausführung sicherstellen. Hierbei gilt es unbedingt die Bemerkungen > unter 4.1.3.3 zu beachten, insbesondere dass nach einigen Kommandos > (z.B. "*RST") OCIS ohne Setzen von NOP und Setzen von OPC im SESR > eingenommen wird! das wäre für mich nochmal wi9chtig zu verstehe. Wie gesagt, ich gehe davon aus, dass mit OPC? auf die Abarbeitung von Reset etc gewartet wird
noßßa schrieb: > Sonst würde ja CLS auch nicht > ankommen, da Reset noch arbeitet. Woher weißt du, dass es abgearbeitet und nicht einfach unterschlagen wird?
noßßa schrieb: > das wäre für mich nochmal wi9chtig zu verstehe. Wie gesagt, ich gehe > davon aus, dass mit OPC? auf die Abarbeitung von Reset etc gewartet wird Nein, wie sich ja schon bei vielen Geräten zeigt, ist "*RST" oftmals nicht streng IEEE-488-konform implementiert, d.h. es erfolgt auch eine Beeinflussung der Kommunikationsschnittstelle, z.B. Neuinitialisierung und Löschen des Empfangspuffers. Bei anschließenden Pollen, um das Ende des Geräteresets mitzubekommen, müssen daher ggf. folgende Zustände berücksichtigt werden: 1. "OPC?" wird komplett verschluckt; Timeout beim Empfang der Antwort 2. "OPC?" wird teilweise verschluckt, d.h. als Kommando wird z.B. "PC?", "?" oder gar nur das Zeilen für das Zeilenende empfangen; folglich antwortet das Gerät dann mit einem Fehler, der auf ein unbekanntes Kommando hindeutet. Auch hier verhalten sich verschiedene SCPI-Implementierungen deutlich unterschiedlich. 3. Nach dem Reset befinden sich noch einzelne Zeichen im hostseitigen Empfangspuffer. Diese werden als fehlerhafte Antwort interpretiert. 4. Alles geht gut; "OPC?" liefert ohne Timeout eine "1". Bei anderen Kommandos, die kein resetähnliches Verhalten bewirken, besteht hingegen nicht die Gefahr, dass das Kommando falsch interpretiert oder die Antwort ausbleibt oder fehlerhaft ist. Vorausgesetzt natürlich, dass kein Fehler in der Firmware oder dem Stapel am hostseitigen Bibliotheksfunktionen vorliegt.
:
Bearbeitet durch User
vielen Dank für deine Ausführungen. Andreas S. schrieb: > Bei anderen Kommandos, die kein resetähnliches Verhalten bewirken, > besteht hingegen nicht die Gefahr, dass das Kommando falsch > interpretiert oder die Antwort ausbleibt oder fehlerhaft ist. also ist es unwahrscheinlich, dass die Fehlermeldung 786 daher rührt. Hast du vllt eine Idee?
Habe ich Lust, mir ein Programm anzusehen, das Du nur in so kleinen Schnipseln veröffentlichst, dass man daran kaum etwas erkennen kann? Nein.
Andreas S. schrieb: > Habe ich Lust, mir ein Programm anzusehen, das Du nur in so kleinen > Schnipseln veröffentlichst, dass man daran kaum etwas erkennen kann? > Nein. hast du überhaupt Lust, wenn ich dir das Programm zur Verfügung stelle, es dir anzugucken?
Angehängte Dateien:
-
Programming_times.PNG
37 KB
Peter D. schrieb: > Im Datenblatt steht wie lange das Gerät braucht um Kommandos > auszuführen. Siehe "Programming times", z.B. Change function (meas) - 30 > ms für USB, usw. > > Das der Reset-Befehl länger dauern kann, könnte man sich denken, da > passiert ja einiges. Vielleicht muss auf Relais gewartet werden usw. kann ich in irgendeiner Form ableiten, wie lange ein reset dauern kann?
im Datenblatt steht auch: Keysight 33210A, 33220A and 33250A Series compatible da das Codebeispiel für 33220A ist, hätte das ja auf anhieb klappen sollen
noßßa schrieb: > kann ich in irgendeiner Form ableiten, wie lange ein reset dauern kann? Gerät einschalten, Stopuhr drücken und warten bis es betriebsbereit erscheint.
Peter D. schrieb: > Die Kommunikation mit dem Gerät passiert mit dem USB-TMC-Protokoll. > Darüber sitzt dann die VISA-Bibliothek und vereinfacht die > Kommunikation, dass muss man mitbedenken. hast du da eine gute Graphik, die die ganzen Zusammenhänge veranschaulicht?
noßßa schrieb: > oder meinst du soetwas? Ja, eigentlich könnte man sogar noch ein paar Schichten einfügen, aber im Prinzip meinte ich das. Ich glaube die VISA-Software ist gut, wenn mehrere Instrumente hat, und die über eine Hersteller-Software gemeinsam steuern kann. Allerdings liest man von vielen Problemen im Internet, kommt mir zumindest so vor.
Peter D. schrieb: > Ich glaube die VISA-Software ist gut, wenn mehrere Instrumente hat, und > die über eine Hersteller-Software gemeinsam steuern kann. Allerdings > liest man von vielen Problemen im Internet, kommt mir zumindest so vor. Genau so ist es. Das, wovon man ziemlichen Abstand nehmen sollte, ist die auf VISA aufsetzende Schicht IVI. Damit beraubt man sich ziemlich der Möglichkeit, selbst noch SCPI-Kommandos zu verschicken, und muss sich stattdessen mit teils sehr, sehr fehlerhaft implementierten Bibliotheken und scheußlichen APIs herumplagen. VISA finde ich auch bei nur wenigen (z.B. n=1) gleichzeitig genutzten Messgeräten ganz praktisch, die man wahlweise über unterschiedliche Schnittstellen ansprechen kann. Das Wechseln der Schnittstelle ist dann recht einfach. Allerdings sollte man ggf. auch die Lizenzkosten berücksichtigen: https://www.ni.com/de-de/shop/software/products/ni-visa.html
http://zone.ni.com/reference/en-XX/help/370131S-01/ni-visa/comparisonni-visaandni-488apis/ hab dazu folgendes gefunden... kann damit nicht viel anfangen
noßßa schrieb: > gibt es unterschiede zw VISA und NI-VISA VISA ist der Standard, NI-VISA die Implementation von NI Es gibt noch andere Hersteller, die VISA verbauen.
Peter D. schrieb: > Usb488 - Universal Serial Bus Test And Measurement Class, Subclass > USB488 Specification (USBTMC-USB488) Revision 1.0, 2003 > ; IEEE4881 - IEEE Standard Digital Interface For Programmable > Instrumentation, 1988 > ; IEEE4882 - IEEE Standard Codes, Formats, Protocols And Common > Commands, 1988 > ; IEEE4882-92 - IEEE Standard Codes, Formats, Protocols And Common > Commands for Use With IEEE wo bekomme ich die Normen umsonst?
habe sie jetzt. aber wonach soll ich filtern?
wo ist überhaupt der Unterschied zw IEEE 488.2 und SCPI?
noßßa schrieb: > wo ist überhaupt der Unterschied zw IEEE 488.2 und SCPI? Das findet man alles in der entsprechenden Primärliteratur.
noßßa schrieb: > wo ist überhaupt der Unterschied zw IEEE 488.2 und SCPI? reicht das erstmal https://de.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments?wprov=sfti1 ?
ja hab jetzt alles. Bis auf Literatur für VISA. Macht es Sinn, wenn man sich einen Überblick über das Thema verschaffen möchte, das Ganze in Hardware (IEEE 488.1) und Software (IEEE $88.2, VISA; SCPI) zu unterteilen. Oder wie würdet ihr vorgehen?
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.