Ubuntu pyvisa: Verbindung zum USB-seriellen Gerät

[Christoph M. (mchris)]

Ich versuche, ein SCPI-Gerät über die serielle Schnittstelle zu steuern:

import pyvisa

# Define the serial resource address (update this with your actual device port)
instrument_address = 'ASRL/dev/ttyUSB0::INSTR'

# Create a PyVISA resource manager
rm = pyvisa.ResourceManager()
rm.list_resources()

print(rm)

"rm.list_resources()" zeigt aber kein Gerät an. Woran könnte das liegen?

[Harald K. (kirnbichler)]

Und wo wird Dein String "instrument_address" ausgewertet? Wo wird der 
pyvisa bekanntgegeben?

[Christoph M. (mchris)]

>Und wo wird Dein String "instrument_address" ausgewertet? Wo wird der
>pyvisa bekanntgegeben?

Zum Testen nehme ich einen Arduino Nano mit diesem Beispiel:

https://github.com/Vrekrer/Vrekrer_scpi_parser/blob/master/examples/SCPI_Dimmer/SCPI_Dimmer.ino

Im Terminal meldet er sich:

*IDN?
Vrekrer,SCPI Dimmer,#00,v0.5.0

[Christoph M. (mchris)]

OK, ich bin ein Stück weiter.
Mit dem Logik-Analysator zeigt sich, dass pyvisa das *IDN? Kommando 
absendet.
Nutzt man das Terminal-Programm in der Arduino-IDE, ist das 
Terminierungszeichen "0x0A" und der Arduino antwortet mit dem korrekten 
Identifikaitonstring.

Nimmt man hingegen das pyvisa script unten, sind die 
Terminierungszeichen "0x0d, 0x0a" was den Arduino zu verwirren scheint. 
Wie kann man die Terminierung in pyvisa umstellen?

#!/usr/bin/env python3

import pyvisa

# Define the serial resource address (update this with your actual device port)
instrument_address = 'ASRL/dev/ttyUSB0::INSTR'

# Create a PyVISA resource manager
rm = pyvisa.ResourceManager()

# Open the serial instrument with correct parameters
instrument = rm.open_resource(
    instrument_address,
    baud_rate=115200,  # Match your instrument's baud rate
    data_bits=8,
    parity=pyvisa.constants.Parity.none,
    stop_bits=pyvisa.constants.StopBits.one,
    timeout=5000  # Timeout in milliseconds
)

rm.list_resources()

# Send the *IDN? command and print the response
try:
    idn = instrument.query('*IDN?')
    print(f'Instrument IDN: {idn.strip()}')
finally:
    instrument.close()

[Christoph K. (backdraft007)]

https://pyvisa.readthedocs.io/en/1.8/resources.html#termination-characters

[Christoph M. (mchris)]

> Christoph K. (backdraft007)
> 17.03.2025 11:53

Danke. Mittlerweile läuft es. Allerdings war es ein Doppelfehler, die 
bekanntlich besonders schwer zu finden sind: Einerseits das Problem mit 
den Endzeichen und zweitens braucht der Arduino-Nano etwas Zeit um zu 
starten, wenn man die serielle Schnittstelle neu öffnet. Deshalb muss 
unbedingt eine Wartezeit vor der Anfrage "*IDN?" eingebaut werden.

Here you go:

#!/usr/bin/env python3

# test USB SCPI Commands with an Arduino as Instrument
#
# Arduino test side:
# https://github.com/Vrekrer/Vrekrer_scpi_parser/blob/master/examples/SCPI_Dimmer/SCPI_Dimmer.ino
#
# 250317 mchris


import pyvisa
import time

# Define the serial resource address (update this with your actual device port)
instrument_address = 'ASRL/dev/ttyUSB0::INSTR'

# Create a PyVISA resource manager
rm = pyvisa.ResourceManager()

# Open the serial instrument with correct parameters
instrument = rm.open_resource(
    instrument_address,
    baud_rate=115200,  # Match your instrument's baud rate
    data_bits=8,
    parity=pyvisa.constants.Parity.none,
    stop_bits=pyvisa.constants.StopBits.one,
    timeout=5000  # Timeout in milliseconds
)

# Set read and write termination to carriage return (CR)
instrument.read_termination = '\n'  # '\n' represents line feed
instrument.write_termination = '\n'

print("wait till Arduino has started ..")
time.sleep(2)
print("list resources: ")
print(rm.list_resources())


print("get instrument identification:")
# Send the *IDN? command and print the response
try:
    idn = instrument.query('*IDN?')
    print(f'Instrument IDN: {idn.strip()}')
finally:
    instrument.close()

[Christoph M. (mchris)]

Könnte man einen Arduino als einfaches SCPI Messgerät nutzen?

Wenn man statt *IDN? ein read ADC im obigen Pythonscript implementiert, 
kann man zumindest die ADC-Werte lesen.

print("get values:")

try:
    for n in range(1,10):
        value = instrument.query('ADC:READ 0')
        print(f'adc value: {value.strip()}')    
finally:
    instrument.close()

Was spricht dafür oder dagegen das SCIP-Format zu verwenden?
IN der Implementierung sieht es einigermaßen umständlich aus:

/*

  ADC Control Commands

    Read ADC:
    ADC:READ <channel>

        Example: ADC:READ 0 to read from analog channel 0

    Set ADC Resolution:
    ADC:RES <bits>

        Example: ADC:RES 10 to set 10-bit resolution

    Configure ADC Reference:
    ADC:REF <reference>

        Example: ADC:REF INT for internal reference

  GPIO Control Commands

    Set Pin Mode:
    GPIO:MODE <pin>,<mode>

        Example: GPIO:MODE 13,OUT to set pin 13 as output

    Digital Write:
    GPIO:WRITE <pin>,<state>

        Example: GPIO:WRITE 13,1 to set pin 13 HIGH

    Digital Read:
    GPIO:READ <pin>

*/

void setup() {
  Serial.begin(115200); // Initialize Serial communication
  delay(1000);
  //Serial.println("scpi ready");
}

void loop() {
  //delay(1000);
  //Serial.println("hello");
  if (Serial.available()) {

    String command = Serial.readStringUntil('\n'); // Read incoming command
    //String command = Serial.readString(); // Read incoming command
    //Serial.println(command);
    command.trim(); // Remove whitespace and newline characters

    if (command.startsWith("ADC:READ")) {
      int channel = command.substring(9).toInt();
      int adcValue = analogRead(channel);
      Serial.println(adcValue);
    }
    else if (command.startsWith("ADC:RES")) {
      int bits = command.substring(8).toInt();
#if defined(ESP32)
      analogReadResolution(bits);
#endif
    }
    else if (command.startsWith("ADC:REF")) {
      if (command.substring(8).equals("INT")) {
        analogReference(INTERNAL);
      } else if (command.substring(8).equals("EXT")) {
        analogReference(EXTERNAL);
      } else {
        Serial.println("ERROR: Invalid ADC reference");
      }
    }
    else if (command.startsWith("GPIO:MODE")) {
      int commaIndex = command.indexOf(',');
      int pin = command.substring(10, commaIndex).toInt();
      String mode = command.substring(commaIndex + 1);

      if (mode.equals("OUT")) {
        pinMode(pin, OUTPUT);
      } else if (mode.equals("IN")) {
        pinMode(pin, INPUT);
      } else {
        Serial.println("ERROR: Invalid GPIO mode");
      }
    }
    else if (command.startsWith("GPIO:WRITE")) {
      int commaIndex = command.indexOf(',');
      int pin = command.substring(11, commaIndex).toInt();
      int state = command.substring(commaIndex + 1).toInt();

      if (state == 0 || state == 1) {
        digitalWrite(pin, state);
      } else {
        Serial.println("ERROR: Invalid GPIO state");
      }
    }
    else if (command.startsWith("GPIO:READ")) {
      int pin = command.substring(10).toInt();
      int pinState = digitalRead(pin);
      Serial.println(pinState);
    }
    else if (command.startsWith("*IDN?")) {
      Serial.println(F("Arduino Peripherial Control"));
    }
    else {
      Serial.println(F("ERROR: Unknown command"));
    }
  }
}

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

Im Prinzip geht das durchaus. Ich bastele gerade an einem solchen 
Projekt und habe hier ein paar Wavgat UNO (Arduino Klone) rumliegen, die 
einen LGT8F328P haben - der kommt sogar mit einem DAC. Im Moment benutze 
ich den Vrekrer SCPI Parser, will das aber noch umstellen und dann 
weitere Befehle ergänzen.

[Christoph M. (mchris)]

>Wavgat UNO (Arduino Klone) rumliegen, die einen LGT8F328P haben

Dein Code ist gut lesbar geschrieben. Gefällt mir gut.
Ich wusste gar nicht, dass es Arduino328-artige mit DAC gibt. Vermutlich 
ein chinesischer Clone. Den Hersteller konnte ich nicht finden.

>Im Moment benutze ich den Vrekrer SCPI Parser, will das aber noch umstellen und 
dann weitere Befehle ergänzen.

Wie möchtest du umstellen? Vielleicht lässt sich das Projekt so machen, 
dass man die Codebasis teilen kann.
Bezüglich der Peripherie sind auch die STM32L432KC nicht schlecht. Die 
haben 2x12 Bit DAC und sind vermutlich analog-technisch besser.

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

> Dein Code ist gut lesbar geschrieben. Gefällt mir gut.

Danke!

> Ich wusste gar nicht, dass es Arduino328-artige mit DAC gibt. Vermutlich
> ein chinesischer Clone. Den Hersteller konnte ich nicht finden.

Ja, ist chinesisch. Hier gibt es ein paar Infos und die passende 
Arduino-Bibliothek:

http://github.com/dbuezas/lgt8fx

Beim großen China-Markt gibt es die Boards schon um die 2,50€.

> Wie möchtest du umstellen? Vielleicht lässt sich das Projekt so machen,
> dass man die Codebasis teilen kann.

Ja, wäre eine Idee, ich will das Projekt bei Gelegenheit auf Github 
laden. Ich würde gerne eine eigene möglichst kompakte (wenig Flash, 
wenig RAM) C++ SCPI-Bibliothek schreiben (bin auch schon dabei), die 
sich möglichst am Standard orientiert (z.B. lange und kurze Form von 
Kommandos, keine Unterscheidung von Groß- und Kleinschreibung).

> Bezüglich der Peripherie sind auch die STM32L432KC nicht schlecht. Die
> haben 2x12 Bit DAC und sind vermutlich analog-technisch besser.

Ich habe mir ein STM32F429I Discovery Board genau für diesen Zweck 
besorgt :)

[Christoph M. (mchris)]

>Ja, wäre eine Idee, ich will das Projekt bei Gelegenheit auf Github
>laden.

Bin sehr gespannt ..

>Ich habe mir ein STM32F429I Discovery Board genau für diesen Zweck
>besorgt :)

Schade ist da, dass es nicht von STM32Duino unterstützt wird:
https://github.com/stm32duino/Arduino_Core_STM32

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

> Schade ist da, dass es nicht von STM32Duino unterstützt wird:
> https://github.com/stm32duino/Arduino_Core_STM32

Ja, das stimmt. Aber vielleicht lässt es sich als STM32F429ZI Generic 
Board ansprechen, oder über CMSIS:

https://docs.platformio.org/en/latest/boards/ststm32/disco_f429zi.html

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

Christoph M. schrieb:
> Bin sehr gespannt ..

https://github.com/xenos1984/OpenSCPI

[Christoph M. (mchris)]

Manuel H. (Firma: Universität Tartu)
>Ja, das stimmt. Aber vielleicht lässt es sich als STM32F429ZI Generic
Board ansprechen,

Das sollte gehen. Wenn es das Generic-Board gibt, kann man auf jeden 
Fall mit dem Arduino-Framework compilieren und laufen lassen. Es fehlen 
dann nur die Definitionen für die Peripherie das Discovery-Boards (z.B. 
die ON-Board LED ist dann nicht als LED_BUILTIN vorhanden, Display usw. 
)
Um den vollen Comfort zu erhalten, müssten im wesentlichen für das 
Discovery-Board nur die Dateien platform.txt und boards.txt angepasst 
werden.

Eine genauere Anleitung gibt es hier:
https://github.com/stm32duino/Arduino_Core_STM32/wiki/Add-a-new-variant-(board)


Etwas unschön ist beim STM32F429ZI Generic Board im Arduino-Framework 
ist, dass der Treiber für das Display fehlt. Deshalb wäre die 
Discovery-Board Auswahl nützlich. Es könnte sein, dass sich noch keiner 
erbarmt hat den Treiber einzupflegen und das Display ist ja eine der 
Hauptatraktionen des Discovery Boards.

https://blog.embeddedexpert.io/?p=2077

> https://github.com/xenos1984/OpenSCPI
Vielen Dank. Sieht interessant aus.
Beim ersten drüber schauen fällt mir das Python-Beispiel auf der 
PC-Seite auf: Bei den Beispielen ist es immer gut, wenn es sehr einfache 
und dann die etwas anwenderfreunlichen, komplizierten Beispiele gibt. 
Das einfache Beispiel sollte aus nicht mehr als 10 Zeilen bestehen, bei 
dem die grundlegende Funktion sichtbar wird. Also z.B. lesen eines 
Wertes vom ADC und dann print. Viele Ersteller von Github-Repostitories 
neigen dazu, möglichst die gesamte Funktionalität mit allen 
API-Funktionen in ein Beispiel zu stecken. Das führt dann dazu, dass man 
das wesentliche Prinzip der Bibliothek nicht auf einen Blick erkennen 
kann.

Hier mal am Beispiel eines ADC1115 ADC:
== einfach ==
https://github.com/RobTillaart/ADS1X15/blob/master/examples/ADS_minimum/ADS_minimum.ino

== kompliziert ==
https://github.com/RobTillaart/ADS1X15/blob/master/examples/ADS_high_speed_differential/ADS_high_speed_differential.ino

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

Christoph M. schrieb:
> Das sollte gehen. Wenn es das Generic-Board gibt, kann man auf jeden
> Fall mit dem Arduino-Framework compilieren und laufen lassen. Es fehlen
> dann nur die Definitionen für die Peripherie das Discovery-Boards (z.B.
> die ON-Board LED ist dann nicht als LED_BUILTIN vorhanden, Display usw.
> )
> Um den vollen Comfort zu erhalten, müssten im wesentlichen für das
> Discovery-Board nur die Dateien platform.txt und boards.txt angepasst
> werden.

Ja, das stimmt, wobei sich damit zumindest für's erste wohl leben lässt.

> Eine genauere Anleitung gibt es hier:
> https://github.com/stm32duino/Arduino_Core_STM32/wiki/Add-a-new-variant-(board)

Leider ist der Teil "Define a specific board" ganz unten noch Baustelle 
:D Aber das Board einzupflegen wäre sicher nicht schlecht.

> Etwas unschön ist beim STM32F429ZI Generic Board im Arduino-Framework
> ist, dass der Treiber für das Display fehlt. Deshalb wäre die
> Discovery-Board Auswahl nützlich. Es könnte sein, dass sich noch keiner
> erbarmt hat den Treiber einzupflegen und das Display ist ja eine der
> Hauptatraktionen des Discovery Boards.
>
> https://blog.embeddedexpert.io/?p=2077

Ja, das ist schon hübsch. Ich hatte mir auch überlegt, das Display als 
Live-Anzeige für die gemessenen bzw. ausgegebenen Daten zu benutzen.

> Beim ersten drüber schauen fällt mir das Python-Beispiel auf der
> PC-Seite auf: ...

Ja, da hast du natürlich vollkommen Recht. Den Skript hatte ich erst 
einmal nur für mich selbst geschrieben, um zu testen, ob die gemessenen 
Daten überhaupt Sinn ergeben. Die "richtigen" Anwenderbeispiele, 
komplett mit Kommentaren, sollen noch folgen :)

[Christoph M. (mchris)]

Gerade habe ich noch mal etwas genauer über SCPI gelesen.
Es gibt wohl eine Art Standard-Kommandos, die alle Geräte implemtiert 
haben sollten. *IDN? ist auf jeden Fall eines davon.

https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

Ja, richtig. Darüber, was diese Standard-Kommandos tun (sollen), 
schweigt sich der 800 Seiten lange SCPI Standard aber aus - und verweist 
auf IEEE 488.2 / IEC 60488-2, wo diese Kommandos definiert sind. 
Generell basiert SCPI auf IEEE 488.2 und viele Grundlagen sind 
stattdessen dort definiert, darunter Dinge wie Zeichensatz, 
Befehlsformat, Datenformate, Einheiten für Messgrößen...

Das ist auch ein Grund, warum ich statt Vrekrer lieber eine eigene 
SCPI-Bibliothek implementieren möchte, die bereits alle notwendigen 
Standard-Kommandos behandelt, und außerdem einen Parser für die IEEE 
488.2 Datenformate und Einheiten enthält, den man direkt einbinden kann, 
statt im Sketch mit Zeichenketten zu arbeiten.