SCPI to COM

[MitjaStachowiak]

Hallo,
weiß jemand, wie ich in Freepascal SCPI-Commands an ein Gerät schicken kann, das an einem (virtuellen) COM-Port hängt?

[Edit:] In dem Modul Synaser gibt es die Klasse TBlockSerial, die direkt Methoden, wie SendString anbietet. Meint ihr, das wird für SCPI funktionieren?

Komplette Storry:
Ich möchte ein Hameg HM8115-2 Wattmeter ansteuern. Das Teil hat einen RS232 und einen USB-Anschluss. Ich nahm den USB, installierte den Treiber, aktivierte den virtuellen COM-Port und schon kann ein kleines Tool von Hameg die Daten abrufen, wenn ich COM 3 auswähle.

Ich dachte also, kein Problem, das in Lazarus auch abzufragen, ABER: Nach 8 Stunden Arbeit bin ich keinen Schritt weiter. Um die Daten abzufragen, gibt es kurze, Textbasierte Befehle (SCPI). Nun, wie sendet man SCPI-Commands über RS232 bzw. den virtuellen COM-Port? Es gibt da das VISA-Interface von National Instruments, dafür gibt es auch eine PAS-Unit: https://github.com/Laksen/FP-VISA

Als ich die eingebunden hatte, verlangte das Programm visa32.dll. Diese findet sich in einem VISA-Runtime: http://www.ni.com/download/ni-visa-run- ... 4/4231/en/ Habe das also auch noch installiert. Nun, bevor man die Verbindung connecten kann, will FP-VISA eine "address" haben. Dabei handelt es sich aber wohl nicht um die Nummer des COM-Ports, sondern um eine GPIB-Adresse. Das HM8115-2 hat aber keine GPIB-Adresse, das einzige, was ich dazu gefunden habe, ist ein "Measurement and Automation Explorer", in dem man diese einstellen können soll. Aber den Explorer gibt es nur in einem 600MB!!!-Großen Package

Ich dachte mir: Kann doch nicht sein, dass man so viel Kram installieren muss, um ASCII-Commands über einen COM-Port zu schicken und habe mal bei Hameg angefragt. (Von anderen Herstellern bin ich es gewohnt, irgendwo im Treiber eine DLL zu finden und beim Support bekommt man dafür Headerunits in 10 verschiedenen Programmiersprachen und schon läuft's...) Hameg hat mir bislang nur ein .vi-File geschickt. Keine Ahnung, was ich damit soll - offensichtlich erwartet man von mir, noch eine Lizenz für LabView auftreiben zu können, das auch noch zu installieren um dann endlich ... ein paar Ascii-Daten abfragen und in eine Datei speichern zu können. Wirklich?

[Christian]

Schau dir am besten an was mit dem HAMEG Tool über die RS232 flattert und bau das nach wird weit einfacher sein.
http://www.heise.de/download/free-seria ... nitor.html

[Christian]

Übrigends wenn dir ne genauigkeit von 1mW reicht könnten Tinkerforge Komponenten deutlich günstiger sein.

[MitjaStachowiak]

Ah, das Tool sieht vielversprechend aus.

Wenn Synarser nicht geht, kann ich das damit untersuchen. Die Hameg-Geräte sind nur geliehen, daher möchte ich ungern per try-and-fail programmieren

[magnetron]

Hallo,
die mir bekannten Geräte mit einer Art SCPI über RS232 funktionieren gut mit Synaser.
Wichtig ist, dass die Schnittstellen-Einstellungen so sind, wie das Gerät sie haben möchte.
Die Queries werden mit ? abgeschlossen, gefolgt von CR, LF oder einer Kombination aus CR und LF (siehe Gerätedoku).

Ein denkbares Query wäre also z.B. POW?<CR>
Sowas kann mit Synaser mittels SendString und RecvString oder RecvTerminated o.ä. behandelt werden.
Zum Testen der prinzipielen Funktion reicht oft ein serial terminal.
Grüße, Stefan

[MitjaStachowiak]

Ok, dann poste ich mal etwas Beispielcode, wenn's geht.

[MitjaStachowiak]

Hmm, folgendes hat schon mal nicht funktioniert:

Code: Alles auswählen

 
 scpi := TBlockSerial.Create;
 scpi.Connect('COM3');
 scpi.Config(9600, 8, 'N', SB1, false, false);
 ShowMessage('Device: ' + scpi.Device + '   Status: ' + scpi.LastErrorDesc +' '+ Inttostr(scpi.LastError)+' ');  // Shows 'Device: \\.\COM3   Status: Device OK 0'
 scpi.SendString('BEEP1');
 scpi.SendString('BEEP');
 ShowMessage(scpi.RecvTerminated(1000, '?')); // Shows ''   
 

Wenn ich BEEP im Hameg-Tool eingebe, gibt das Gerät ein kurzen Ton ab, aber hier passiert nichts.

Free Serial Monitor geht nicht auf Windows 7 und in Virtual Box geht das Hameg-Tool nicht

Immerhin: Wenn ich das Hameg-Tool zeitgleich zu meinem Programm ausführe, liefert Showmessage entsprechende Fehler, also irgend etwas passiert da schon. Aber SCPI geht so leicht nicht.

[Mathias]

Ich bin momentan mit einem Arduino am basteln, da habe ich folgen Code für die Kommunikation.
Sehr wichtig sind dort die Sleep(1000);
Vielleicht braucht es bei dir dies auch.

Code: Alles auswählen

  ser := TBlockSerial.Create;
 
  {$IFDEF MSWINDOWS}
  ser.Connect('COM3');
  {$ELSE}
  ser.Connect('/dev/ttyUSB0');
  {$ENDIF}
  Sleep(1000);
  ser.Config(9600, 8, 'N', SB1, False, False);
 
  Memo1.Lines.Add('Device: ' + ser.Device + '   Status: ' + ser.LastErrorDesc + ' ' + IntToStr(ser.LastError));
  Sleep(1000);
  // hier kann man mit schreiben beginnen.

PS: Baud, Bit, etc. stimmen ?

[magnetron]

Das wird schon... Gemäß Handbuch muß das Gerät auf 1200Baud oder 9600 Baud konfiguriert werden,
das würde ich als erstes prüfen/einstellen.
Dann Wünscht sich das Gerät Xon-Xoff softflow (siehe Handbuch).
In Sinne von Synaser müsste es dann vermutlich heissen:

Code: Alles auswählen

 scpi.Config(9600, 8, 'N', SB1, true, false);

Dann möchte das Gerät Kommandos mit #13 abgeschlossen haben (Handbuch Abschnitt 7)

Beim Empfang vermute ich eher nicht, dass das Gerät ein ? als Abschluss sendet.
Insofern wäre RecvString fürs erste erfolgversprechender.

Es ist eine gute Idee, das ganze manuell mit einem serial-terminal auszuprobieren,
Gerät einstellen (9600), serial terminal einstellen (9600, 8N1, XonXoff) und dann senden und sehen was passiert.
Dazu einfach ins terminal "BEEP1" Enter eingeben (usw.) und die Antwort ansehen.

Danach könntest Du die Erkenntnisse in Deinen code einbauen, vielleicht in etwa so:

Code: Alles auswählen

 scpi.Connect('COM3');
 scpi.Config(9600, 8, 'N', SB1, TRUE, false);  // Gerät will XonXoff ? siehe Handbuch ?
 scpi.SendString('BEEP1'+#13);
 scpi.SendString('BEEP'+#13);
 ShowMessage(scpi.RecvString(1000)); //nicht für beep oder setup commands 

Wobei nach BEEP wohl eh keine Antwort zu erwarten ist, also vielleicht besser IDN? oder VAL? senden um sinnvolle Antworten zu erhalten.
Viel Erfolg, Stefan

[MitjaStachowiak]

Den Absatz habe ich übersehen. Im Handbuch steht leicht zu übersehen "Each command must use oDh (Enter) at its end". Ich hoffe, daran liegt's.
Bei Xon-Xoff hatte ich immer alle 4 Möglichkeiten durchprobiert
Sleeps hatte ich auch mal drin, aber der Gerätestatus scheint ja nach Config OK zu sein.

Vielen Dank schon mal, ich probier's gleich morgen aus.

[Edit:] Ja, es lag wirklich nur an dem Absatz, Sleep ist nicht notwendig. Au man, um das zu sehen, hätte ich erst mal Windows XP installieren müssen, um dieses Analysetool und das Hameg-Tool zum laufen zu bringen ... oder wahlweise herausfinden, warum es in VB nicht geht.

Dieser Code dud:

Code: Alles auswählen

 scpi := TBlockSerial.Create;
 scpi.Connect('COM3');
 scpi.Config(9600, 8, 'N', SB1, true, false);
 ShowMessage('Device: ' + scpi.Device + '   Status: ' + scpi.LastErrorDesc +' '+ Inttostr(scpi.LastError)+' ');
 scpi.SendString('BEEP1' + #13);
 scpi.SendString('BEEP' + #13);
 scpi.SendString('VAL?' + #13);
 ShowMessage(scpi.RecvTerminated(1000, #13)); 

Also noch mals: Vielen Dank!

[magnetron]

Super wenns nun klappt.
Dann kommt jetzt die eventuell schönere Arbeit den String-wirrwarr der zurückkommt
zu parsen und dann automatisierte Messungen zu machen.
Hochwertige Geräte mit dokumentierter Schnittstelle machen einfach Spass.

Hätte mich gewundert, wenns nicht mit Synaser geht, also viel Spass damit und
viele Grüße, Stefan

[af0815]

Eventuell ein Y-Kabel bauen und das Instrument mit einer Funktionsfähigen Software ansprechen und mit einem zweiten Rechner die Kommunikation passiv mitschneiden. Dann kann man in ruhe Analysieren was auf der Schnittstelle abgeht. Hardwaremässig geht meistens, man muss halt mehr investieren. Ich verwende meistens ZOC zum Testen (Sollte auch in der 30 Tage Version gehen).

[MitjaStachowiak]

Ich muss das hier noch mal eröffnen:

Das HAMEG-Gerät beginnt jede Antwort mit #19 und beendet jede Antwort mit #17. Ich horche byteweise auf den COM-Port:

Code: Alles auswählen

 
   c := Char(syn.recvByte(10));
   if (c <> #0) then messagebox(0, PChar(inttostr(Byte(c))), nil, 0);
 

Nun poppt für jedes empfangene Byte eine MessageBox auf, aber die #19 und #17 sind nicht dabei. In HTerm werden sie mir aber angezeigt. Jemand eine Idee, woran das liegen könnte?

Gehören sie zur FlowControl?

Das Problem ist: Wenn ich einen Befehl sende, bevor der Vorhergehende mit der Antwort begonnen hat, wird dieser Befehl ignoriert

[af0815]

Schau mal hier nach : https://de.wikipedia.org/wiki/Datenflus ... ON.2FX-OFF

Klingt verdammt nach XON/XOFF. Das kann von der Treiberschicht verwendet werden, dann siehst du es in der Applikation nicht mehr. Wenn solltest du keine Messagebox verwenden, da damit der Ablauf unterbrochen wird. Wenn du unbedingt was sehen willst, gib es fortlaufend zB. an ein Memo aus. Oder schreib es mit writeln / debugln auf die Konsole.

Was für Komponenten verwendest du für die Kommunikation und wie hast du die Schnittstelle parametriert ?!

[MitjaStachowiak]

Ja, es war wirklich die FlowControl. Ich verwende SynaSer - TBlockSerial. Seit ich die FlowControl-Parameter beide auf false gesetzt habe, bekomme ich die #19 und #17 angezeigt und habe es so gemacht, dass bis dahin kein weiterer Befehl gesendet wird.

Das andere Gerät (Metrawatt SPL 250_30) kann zwar mehrere Befehle hintereinander verarbeiten, aber nach manchen Befehlen muss man 60ms warten, sonst kommt ein Fehler. Man kann da auch eine FlowControl aktivieren, werde das bei Gelegenheit testen.