Basic SCPI connection with BK Precision 880 only works Intermittently

[Austin-Downey]

General problem: I have a BK 880 LCR that I need to communicate with using LABVIEW. This is an SCPI-compatible device and I have written a very basic code using NI-VISA. Currently, I am just trying to query the instrument ID using the *IDN? command. However, this only works some times (1 out of 20) and the remainder of the time I get the error "VISA Read in Untitled " with the code "-1073807339".

Detailed background:

Here is the code,

Where COM4 is the LCR meter (BK Precision 880). Here is the error screen I get when I run this code

Here is my NI MAX screen showing my driver installs and the COM4 device. Maybe I don't have the right drivers?

Lastly, here is the *IDN? command in the BK 880 documentation. This complete documentation can be found here https://bkpmedia.s3.amazonaws.com/downloads/manuals/en-us/880_manual.pdf and the SCPI information starts on PDF page 48

I tried a few things in the LabVIEW code, like setting some of the serial bit and rate commands but nothing helped and I believe the device parameters listed in the NI MAX screen are the standard parameter values.

The LCR beeps at me when I send

*RST
*IDN?

But does not beep at me when I send just one of them.

Any help would be appreciated. 

[Austin-Downey]

I still can't figure it out but in NI-MAX if I open the VISA test panel and sent the LCR the IDN command I get a \r\n return function. Maybe this is the issue with my VISA-read command? I tried to implement a  \r\n char character but I still can't get it to work. 

In the VISA test panel, the INS command seems to work every time I send it. 

 

[Albert.Geven]

Hi

You said you tried with different init settings.

But did you change the  end character?

Default that is a LF or char 10 decimal or \n

This are 3 ways of describing the same character.

In a LabVIEW block diagram you should make visible the display style and select the \style than you see \s for space, \n for LF and \r for CR.

Normally you don't see these control characters only their effect.

Another thing is your *RST command. that can take quite a while to execute, and the Clr command in the beginning is also not always functional, so just try the *IDN?\r\n

[Austin-Downey · Accepted solution]

Albert, 

Thanks for the help. I did try quite a few combinations of end characters and formats. I was able to get it to work today by putting a pause statement. I think you were on the correct path with how low the *RST command takes but the basic *IDN command did not work until I added the pause. I don't know why the examples online didn't have a pause but this is what seems to be working for me. 

[Albert.Geven]

Hi

Well done

I saw a few days ago the same problem, After opening a VISA session an existing program reacted weird.

It has been running in LabVIEW 2017 and in the development-environment perfectly for a year with several changes to the main program but a build I made on an updated LV2018 SP1 f2 version with VISA 18.5 showed a problem just after initialization. I added a small delay of only 200 ms and the behavior became somewhat better but still data was lost.

I will research next week for the LabVIEW and VISA versions on the lab computer to verify eventual differences between the systems. There is no builder on that machine, but the development version worked OK without changes, so maybe we can track down what happens.

[cstorey]

*RST is a reset, kind of like cycling the power.  It often takes an instrument 1-2s to recover, and restore itself to a default setup.  During that time a lot of instruments will ignore any further commands.  So you would be best to do the *RST, delay 2s, send the *IDN?\n and then read the response.  In this case I doubt you will need to add a delay between writing the *IDN?\n and reading the response. 

[Austin-Downey]

I did need to add the delay for *IDN?. Without it, I would get an error in reading. The delay may need to be longer if an *RST was also sent but this, in either case, I needed it for both commands. The problem is nothing I found online said I needed the delay. 

[Minions]

The *RST command will not affect the *IDN? actual response; It will only delay receiving the response.  The *IDN? query does not care about the state of the instrument for its response.  If you are having a timing issue, the correct thing would be to extend the timeout rather than adding in delays.

If you change the order of commands and send the *IDN? the instrument should be able to respond accordingly then send the *RST command afterwards.

[Austin-Downey]

Even when just sending the *IDN with long time outs (30 seconds) I still had the same issue. Maybe my device is slow? Maybe the newer LabVIEW is too fast. These may be worth exploring in the future but I was able to build the code I needed to use the delay method.