LabVIEW
Labview does not run with SCPI commands
Solved!
- last edited on by
Content Cleaner
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).
I have the same problem with LabVIEW. As soon as i use a block there which represents a SCPI command(marked red in the picture) an error occurs.
I have already changed the Remote Language to SCIP in the Audio Analyzer settings (Utilities->Config Panel). Basically a connection already works, because I get a feedback with a common command like "*IDN?" and a window "Remote Operation Active" opens on the display of the analyzer.
I've been stuck on this problem for a week and I'm not getting anywhere.
So I would be very happy about an answer.
Hi Simon,
@User002 wrote:
So the problem is not with LabVIEW, but with your device!
No matter which software (or computer) you use the device always responds with an "error -113".
Does the R&S give this error for all SCPI commands? (I don't mind commands like "*IDN?", but all that stuff like "STATUS:…", see chapter 7 in the manual.)
Usually the device's menu structure follows the SCPI commands.
Can you select ANLG on the device thought the menu?
Maybe the command is "INST1:SEL ANLG"?
I'd definitely omit the uncapitalized characters. I think they should be optional, but the device might not play nice, or they might actually need to be capitalized (e.g. they're only printed small to indicate that they are optional).
Search LabVIEW like a graph! 
According to this manual here: https://www.rohde-schwarz.com/webhelp/upv_onlinemanual_en_1/Content/0a01b598082d47be.htm
the syntax is:
INSTrument<n1> <generator_type>
If you write INST or Instrument shouldn't matter, and it says that a missing <n1> parameter is interpreted as meaning 1 but what if you try:
INST1 ANLG;
Some SCPI instruments are quite picky in how they want the non minimalized form of the command written. Some accept any number of characters after the upper case part (which is the mandatory part to identify the command), some only accept either the short form or the full form and some require everything to be uppercase, despite the convention to document the SCPI commands with uppercase letters for the mandatory part (short form) and lowercase letters for the optional part (long form) of the command.
I even have had devices who would only work if the entire command was either long or short form but not if parts were in one form and others in the other.
Hi,
I can select Instrument -> analog on the device in the menu.
In addition to that i can track the changes i make on the Audio Analyzer with the "Local SCPI Recorder" as SCPI code so that there is no spelling mistake. (In the picture you can see that i changed some options in the Generator config window and on the right side the Local SCPI Recorder wrote SCPI commands in parallel.
On the bottom left in the picture you can see the error which occurs.
If the vendor's software doesn't work, something else must be wrong.
How are you communicating? GIPB, RS232, Ethernet?
Perhaps the cable is broken or too long? Wrong baud rate, parity, etc. maybe?
EDIT: This would be weird, as you do get communication, but if only short messages work correctly, time outs, baud rates, cable length, etc could be a factor. 7 or 8 character bits might mean letters are send over correctly, but spaces won't. I'm guessing here. As you're seeing weird, unexpected things, the problem probably is weird and unexpected. Suspect anything.
EDIT2: USB2Serial converters or Ethernet2Serial converters could cause problems too. If you have any complexity going on, now is the time to tell.
