ZNC VNA marker access problem through LABview

[Vcl]

Hi,

I am working on Controlling and Automating Vector network Analyser. I am using ZNC VNA. I am able to communicate between PC and VNA through LAN. One of the measurements requires me to get the values of the S parameters for a whole frequency range and display it in a tabular fashion which can then be exported to excel.

So for this, I am using Marker Query response to extract details of marker. But I have stuck here where I am not able to read the marker details. I have configured marker format to mlog and other properties.

How do I initialize Marker Query Response to get marker value?Can any1 suggest me that where I am going wrong. Or Is there any example vi to do so?

Thanks in advance

[Bob_Schor]

You provided no LabVIEW code.  I didn't see this second Query when I answered your earlier question about using the functions on the GPIB Palette to design programs that mimic the code shown in the Product Manual -- is this what you are trying to do in LabVIEW?  If we have no idea what you have tried, we can only provide generic help like "Read the Manual, Try Doing the Examples".

Bob Schor

[rolfk]

Unless there is someone on this board that uses this exact device, AND happens to frequent this board to see your message, AND happens to feel like answering, you will likely not receive much of help with such generic information.

What is a marker? what sort of driver library do you use? where did you get it? have you a manual and did you read it?

If you got a LabVIEW instrument driver from somewhere, those instrument drivers often implement the most frequently used features of a device, especially for so complicated devices like network analyzers, but not every single feature. Most of these drivers are written by people who use this device in their work and they tend to implement what they need, which is seldom more than 10% of what such devices can do. And even if the driver was submitted to the NI instrument driver program, the people who verify such submissions can't go and rewrite such drivers. They can look if the common guide lines have been followed and require according changes or make them themselves but they can't extend such drivers just like that since that requires very specific domain knowledge and last but not least a physical device to actual work with.

If the functionality you want is not present in the driver you will have to obtain the Programming Reference Manual for your device and start digging into the commands you can send to it and the response format that it returns. Then you will need to extend the existing driver with the necessary functionality (if the device even supports it through its remote control interface, some devices really don't support everything through programming means that you can do on their front panel) and if you feel like wanting to return something to the community so others like you can profit from a better driver, you can even resubmit the new extended driver or at least post it somewhere online. A lot of the available instrument drivers are based on such submissions, and if everyone only wants to consume and never gives back, there won't be many such drivers.