What would cause an Error In when there is no Error sent forward?

[Anthony_F]

Hi ImpInTraining,

I will confirm Dennis Knutson previous statement that this error is being returned by the instrument.  I would double check the commands you are issuing to the instrument as this error is not generated internally by LabVIEW.

I would double check the software drivers and make sure that there are not newer versions published by Agilent

"Undefined header found in Agilent E4405B"

"Why does my ESG report errors when I try to download waveforms using a National Instruments GPIB ca...

"most multi-interface I/O capable instruments (GPIB & RS-232) require the user to actually select th...

"Open MAX and turn on NI-Spy."

[ImpInTraining]

I'm afraid not.  See here's the funny thing.  This RF Output Enable VI is proceeded by an RF Power VI, - and within that VI is the same Sub-VI, Error Query - at the tail end of it.  So it goes through that VI, reports no errors.  Goes through the RF Power VI, and suddenly there is an error being reported from the equipment - which strangely enough doesn't show up on the actual equipment.

I'm calling Agilent to help with this, since these drivers were provided by their company.  There's just something going on that I can't understand.

[ImpInTraining]

Thanks for the links... I'll look into those.  And as for the drivers and if newer versions exist, I just installed them last month - they were the newest versions at that time.  I'll look again, but I doubt there's been anything new added with regards to this signal generator.  

As for the commands being issued, they are Agilent drivers ... the commands issued are whatever they programmed in.  I assume it works in most conditions and that my situation is a fluke.  I note again, this Error Query sub-VI shows up in other drivers as well, and doesn't have the same problem.  I am wondering now if maybe I'm not using the driver correctly.  None of the input connectors show up as mandatory.  The only thing I'm adding in to Configure RF Output is a True boolean value to Enable RF Output connector, but there are other boolean values that are defaulted to enable.  Perhaps some of those should be set to false because the signal generator simply lacks the capability and I'm simply unaware.  

The other connections are listed as: Enable Modulation, Enable Auto Blanking, Enable Blanking, Enable Reverse Power Protection - all of them are enable as default.  That's the only thing I can think of as to why this might be sending an error back.

[Dennis_Knutson]

If this is the driver you are using, then why do you think it was written by Agilent? If that is not the driver you downloaded, post a link to the one you are using.

I think you also need to better understand what is happening. Each top level function in the driver calls the Error Query to verify if the instrument successfully processed all of the SCPI commands. The fact that the previous function does not report an error just means that the commands in that function are correct. You've already verified that the subVIs do not cause the error and you have all of the other SCPI commands. It's just a matter of executing those commands one at a time to isolate the cause. You can do this in MAX. You can do this in LabVIEW. Just by using the disable structure you can select which commands are sent. It's basic troubleshooting. Have you looked up the commands in the instrument manual and compared them to the LabVIEW code?

The reason that the driver is causing a fault could be because of several reasons. It's possible that your instrument is at a different firmware level than the instrument used to develop the driver and a SCPI command is different/no longer valid. It's possible the exact combination of commands you are using was never tested in development and was never valid. On the driver page, you can see which specific instrument the driver was tested with. You have never provided the model number of your instrument.

[ImpInTraining]

That is the driver, and the signal generator is N5183A.  Agilent techs will be calling me after lunch about this.  I'll be sure to keep you all appraised of what we find out.

[ImpInTraining]

All of the commands in the driver seem authentic according to the manual.

[Broken_Arrow]

The attached Agilent "raw command sender" that I wrote 4 years worked fine for me. No Agilent drivers needed.

[ImpInTraining]

Finally got it fixed today.  Seems that bit of code was sending modulation commands (on or off) when my N5183A doesn't have modulator options installed.  So that's what was causing the error.  I removed that bit of the Configure RF Output.vi and streamlined it a tad for my specific equipment, and it's working without a hitch now.  🙂  Yay.