Labview does not run with SCPI commands

[wiebe@CARYA]

NI IO Trace might give insight... It's probably installed on your system. Never used it myself.

[SimonDietz]

Im using an ethernet connection.

Yes im using the drivers from this website but i think you only need the VXIplug&play driver?

[wiebe@CARYA]

---

@SimonDietz wrote:

Im using an ethernet connection.

---

Any hubs or routers that you can (temporarily) remove?

Also, try disabling the firewall (temporarily).

[billko]

I would suggest manually constructing the offending command, either in LabVIEW or through the NI-MAX I/O interface.  I've seen broken drivers from manufacturers before.  If you can get it to work manually, maybe you have to roll your own drivers.

[SimonDietz]

I removed all unnecessary things in my ethernet connection. Furthermore i managed to connect and communicate directly to the Analyzer with the LAN cable directly plugged in both devices. Nothing changed.... so i guess the problem is not on the hardware-connection side.

I also disabled the firewall temporarily... again it did nothing.

In the appendix you can see some commands i logged with the RsVISATraceTool. In line 0-3 everything works fine because i dont use specific SCPI commands. From line 4 i tried to write the "INSTrument ANLG" command. Although there is no error in the log, there is the typical error: "undefined header" on the audio analyzer.

[wiebe@CARYA]

Only think that sticks out is that the reply message has a \n attached, while the send messages don't.

Adding \n might have been done automatically for RS232, and somehow got lost for TCP\IP?

I'd definitely add \n termination of strings to the permutation of command strings you already have...  

[SimonDietz]

Still the error stays the same.

I dont think that the problem is caused by incorrect spelling because all the errors happen in LabVIEW too.

Like I wrote earlier: LabVIEW sends me errors messages as soon as i use a Block which represents a SCPI command. Thats why i guess that the error must be in an other level/layer of the remote control application but i dont know where else to look.

[rolfk]

---

wiebe@CARYA wrote:

I'd definitely add \n termination of strings to the permutation of command strings you already have...  

---

Semicolon also is supposed to work as SCPI command terminator. I added that in my earlier post (and generally always terminate SCPI strings with it, even if it is the only command in the string). Hasn't hurt with any device I tried to communicate with but likely saved a few headaches in the past from even having a chance to come up.

Other things to try out would be to prepend a colon to the command. I haven't really looked at the manual in detail. But while the command description may show a specific format, there might be an introductory section that explains how each SCPI command needs to be formatted and while that can be required, not every manual will always show in the command description the full syntax, supposedly for brevity and to not confuse the programmer having to implement a program based on this with to much details!! 🙄

And I know you said you set the device into SCPI mode but I would check that again. It obviously communicates and understands non-SCPI commands (the IEEE-488.2 commands) but not your SCPI. So that means basically it is not accepting SCPI at the moment or the format you send is not what it thinks should be SCPI. There isn't really much more than that left.

[wiebe@CARYA]

---

@SimonDietz wrote:

Still the error stays the same.

I dont think that the problem is caused by incorrect spelling because all the errors happen in LabVIEW too.

Like I wrote earlier: LabVIEW sends me errors messages as soon as i use a Block which represents a SCPI command. Thats why i guess that the error must be in an other level/layer of the remote control application but i dont know where else to look.

---

I didn't suggest the spelling was wrong. Just that an end termination character that is automatically attached for RS232 (maybe) isn't automatically attached for TCP\IP VISA resources.

Do you have other connection options? If a RS232 or USB or GPIB connection is working, you can rule out a lot.

[Yamaeda]

---

@SimonDietz wrote:

Hello there,

I have the problem that the R&S UPV Audio Analyzer does not understand the SCPI commands sent to it from an external PC (although a communication with the common commands works). As soon as I send a SCPI command to the audio analyzer, the error message: "-113, Undefined header" appears. For example:
I send: INSTrument ANLG (An SCPI command)
-> Error message on the analyzer: -113, Undefined header (INSTrument ANLG) (INSTrument ANLG).

---

It looks like the command is sent twice? And it looks like you're using R&S driver? What happens if you send the command with a simple Visa Write?

[Yamaeda]

Hello there,

I have the problem that the R&S UPV Audio Analyzer does not understand the SCPI commands sent to it from an external PC (although a communication with the common commands works). As soon as I send a SCPI command to the audio analyzer, the error message: "-113, Undefined header" appears. For example:
I send: INSTrument ANLG (An SCPI command)
-> Error message on the analyzer: -113, Undefined header (INSTrument ANLG) (INSTrument ANLG).