SCIP VISA / Verbindung über USB mit Funktionsgenerator

Was steht denn in Globls.vi so drin?

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)

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.

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.

Probiere eine Pause nach jedem Senden im Code einzufügen, vielleicht so 
100 ms oder mehr.

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

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.

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.

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.

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.

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.

Habe ich Lust, mir ein Programm anzusehen, das Du nur in so kleinen 
Schnipseln veröffentlichst, dass man daran kaum etwas erkennen kann? 
Nein.

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

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.

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 
?