sub vi in main doesn't work but same sub as stand alone does work

[Donkey Rubarb]

Hi,

I wrote a program to get measurement data out of the Hp8753 Network analyser. In this program there's a sub-vi where in the Network Analyser receives a query for the type of sweep. The command therefore is Linfreq? ,Logfreq? ...
A lot of the time this subvi's keeps running (query in while loop), so it doens't come up with the type of sweep the Analyser is in.
Now say the Analyser is in Linsweep, this subvi will answer most of the time with 0 (= no analyser not in Linsweep mode), while if I enter this command at the same time in Max it gives 1 (yes analyser is in linsweep mode), or even if I copy the subvi in a new empty vi the result will be 1, STRANGE I think...
The subvi generates no error and
there's no connection problem or so...
Like I said the subvi and the EXACT same stand alone vi give totally different results, the input for the sub is Visa session in and error in but none of these
have wrong values....
Any idea why there's a conflict???

[JaredA]

Hello,

I'm a little confused by your posting and hoped that maybe you could clarify some things so that we can figure this out. I'm going to type what I believe to be true, and hopefully you can correct me where I am wrong.

You have a subVI in a program (is this an executable?). The subVI sends a command to your Network Analyzer, and you expect the Network Analyzer to return with the type of sweep it is executing. Is there an input to this subVI where you instruct which commands get sent to your instrument?

There is a while loop somewhere - in the subVI, or around the subVI? When you send the instrument the query to return the sweep mode it is in, it returns the wrong information. Are you sure that the instrument is receiving the command?

You are also ab
le to send this command in the Measurement and Automation Explorer. Are you communicating with your instrument with VISA calls?

Everything works fine if you copy the VI to a blank VI. But this VI is not within the actual program that you would like to use in the end? Is there still this while loop that's causing the VI to continuously run?

Speculating, it sounds like a timing issue where you are reading the response from the instrument before the command ever really gets executed. I'm sure that you can clear up a lot of my uncertainties with a few answers, so please do so.

Thanks.

[Donkey Rubarb]

Hi,

the program is not an exe., and there is no input to the subvi except for the error in and the GPIB adress.

The while loop is in the subvi, the while loop keeps looping until the network analyser returns a 1 to one of the querys (state of sweep mode).

I am almost shure that the network analyser receives the query's, otherwise the visa read wouldn't be executed correctly.I mean you would not receive any answer, in my case I receive the wrong answer.


If I copy the sub vi to an blank vi, it is excatly the same ( so also the while Loop) except that there is an empty 'error in' and I need to provide the GPIB adress, both of these weren't a problem in the sub vi.

Yes It might be a timing issue cause I fixed the vi with
including time to waits be
tween every read and write.
But still this doesn't explain why the subvi was not working ( actually it was working but came up with the wrong results) but the copied one Was working.

[JaredA]

Hello,

I now understand that the subVI has two inputs, the GPIB address and an error in cluster. So that doesn't seem like it could be any problem as you also suggest.

It's seems possible that since you have a while loop in this subVI, the data you are expecting to see coming out of this loop isn't right at all. If the output that displays the response from querying the instrument for the scan mode it is in is outside of the while loop, and then wired to the subVI terminal block, then you will not see that value until that while loop stops executing (assuming indexing is off).

If in the VI, as a stand-alone VI, you are watching the response from the instrument on an indicator that is inside the while loop, or if the while loop stops execut
ing as soon as that expected query gets executed, then you will see the expected response.
Can you guarantee that the while loop stops executing after your instrument finishes executing the query for the scan mode it is in?

Another think you might want to do is run the VI with the subVI in it with breakpoints set. This way you can step into the subVI and watch the execution of it as it executes the command. Then you can monitor the value being returned inside of the subVI instead of waiting to see the response that gets passed out of the subVI.

[Donkey Rubarb]

Hi,

I run both vi's in slow motion mode (with the Led ON),
and probes attached for read-out, what I see is that the stand-alone vi gives a good answer while the result from the sub-vi is wrong.

Altough this doesn't look like a timing issue, the problem was fixed by placing a wait of 1000msec between every visa read and write.

Is it possible that there is a conflict in the visa protocol for the subvi and that at the same time there's not for the stand-alone?