NI-Visa - Timeout during initialize of power supply

[sammy-e]

Hello, I'm having an issue initializing a power supply using the NI-Visa libraries. After creating the session, the 1st call to Initialize() always fails. If I call it once again, it always succeeds. Adding a delay between the session creation and the init call did not help.

An oddity is that running SPY causes the problem to go away. I tried this a few times while recording and never saw the timeout. However, once SPY was stopped the same timeout behavior could be seen again. Does SPY add some type of latency within the NI-Visa libraries?

Any suggestions or troubleshooting tips would be greatly appreciated. Below are some setup notes in no particular order. Thanks.

1.       Power supply: Lamda 40-85, Genesys 3.3kW
2.       Issue: Initialize() must be called twice before returning successful
3.       Visa error: Timeout expired before operation completed.
4.       Steps to recreate:
4.1.    Create session
4.2.    Call initialize, results in a timeout
4.3.    Call initialize, returns success
5.       Setup details:
5.1.    NI Visa libraries
5.2.    Visual Studio 2010, C#, .NET 4.0
5.3.    Reference libraries:
5.3.1. ivi.dcpwr.interop, runtime version v1.0.3705, version 2.0.0.0
5.3.2. ivi.driver.interop, runtime version v1.0.3705, version 1.0.0.0
5.3.3. ivi.sessionfactory.interop, runtime version v1.0.3705, version 1.0.0.0
5.4.    NI PXI Chassis, Windows XP
5.5.    GPIB interface

[Lars_L]

Hey Sammy,

Which specific driver are you using when you experience these initialization problems? Could you provide me with the download link so I know that we're on the same page? We actually have drivers for the Lambda Genesys series of power supplies on NIs Instrument Driver Network and these are also available on TDK-Lambda's website. I also want to ensure we know where you downloaded the drivers because manufacturers can sometimes upgrade a driver on their website and forget to notify us, leaving us with different revisions.

Here's what I'm seeing from Lambda's download page (link😞

Which one of these are you using?

Although NI-Spy is a fairly lean program, there is a very small amount of increased overhead that is added to your application while it is capturing. It is very rare but we do sometimes hear from customers that their application runs differently when it is logging.

One troubleshooting step you can try is to manually send the initialization command using the NI 488.2 Communicator in Measurement & Automation Explorer (MAX). To do this, just open up MAX (blue icon on your desktop) and right click on your instrument under your GPIB card and select Communicate with Instrument. Try sending the same initialization command that it is recording in NI Spy and see if the behavior still occurs.

Also, when you say it "fails" what exactly do you mean. Are you receiving an error message of some sort? Screenshots and NI-Spy files are always helpful.

Lars L

[sammy-e]

Lars,

Thanks for the input, I definitely appreciate the help. Here are some answers to your questions, if there's anything else that might shed some light, let me know.

I am using an older version of the IVI libraries (versions of individual files are in my original post). I'll give the new ones a try tomorrow. I downloaded and ran the "IEE (IEMD) including Multi-Drop"/"Gui Programs", with the same problem occurring.

I'll give the Communicator a try tomorrow as well.

By "fail", when the dcPwrSession.Initialize(...) method is called, an exception is thrown with the inner text being "Timeout expired before operation completed"

Below is the output from the SPY capture. Please note that I stopped recording before closing the session and that, as mentioned before, no error occurred while running the SPY capture.

1.  viOpenDefaultRM (0x04846708)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

2.  viParseRsrcEx (0x04846708, "GPIB0::6::INSTR", 1, 0, "INSTR", NULL, NULL)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

3.  viParseRsrcEx (0x04846708, "GPIB0::6::INSTR", 1, 0, "INSTR", NULL, NULL)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

4.  viOpenDefaultRM (0x0487CC30)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

5.  viOpen (0x0487CC30, "GPIB0::6::INSTR", 0, 2000, 0x0487CC78)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

6.  viClose (0x04846708)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

7.  viGetAttribute (GPIB0::6::INSTR (0x0487CC78), INTF_TYPE, 1)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

8.  viGetAttribute (GPIB0::6::INSTR (0x0487CC78), RSRC_CLASS, "INSTR")
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

9.  viGetAttribute (GPIB0::6::INSTR (0x0487CC78), INTF_TYPE, 1)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

10.  viGetAttribute (GPIB0::6::INSTR (0x0487CC78), INTF_TYPE, 1)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

11.  viWrite (GPIB0::6::INSTR (0x0487CC78), "SYST:ERR:ENAB.", 14, 14)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

12.  viWrite (GPIB0::6::INSTR (0x0487CC78), "*IDN?.", 6, 6)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.187       Call Duration 00:00:00.078
Status: 0 (VI_SUCCESS)

13.  viRead (GPIB0::6::INSTR (0x0487CC78), "LAMBDA,GEN40-85-IEMD,...", 4096, 45)
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:04.265       Call Duration 00:00:00.344
Status: 0 (VI_SUCCESS)

14.  DEBUG: Process cleanup of open sessions...
Process ID: 0x00000474         Thread ID: 0x00000770
Start Time: 15:38:10.812

[Lars_L]

Hey Sammy,

How did the testing with the newer versions of the driver go?

Do you know what firmware revision your instrument is running? Since the firmware on the device is largely the "brains" and determines how it responds to instrument queries, I'm curious what revision you have compared to what the device had that was used for the development of this driver. If you open up the readme from the driver on the Lambda website that I linked, you'll see that they always list which firmware revision was used during development. It looks like this one was tested with: 2.0-C

Since you only sent a text output of the capture I unfortunately can't see the full content of each message. If you save it as a .spy or a .capture file then it's easier to see what's going on. The device will usually reply with the firmware revision in response to the *IDN? query (line 13 of your capture).

The timeout error that you're experiencing usually means that the instrument is not ready and doesn't reply in time for some reason. This can happen for a large number of reasons so you will need to continue troubleshooting by trying to send the commands manually (using the communicator) to see if it results in the same timeout.

Lars L

[sammy-e]

I tried the updated dll's, actually only "ivi.sessionfactory.interop.dll" was newer, but received the same behavior.

I also sent the "*IDN?" message using the communicator,but was unable to reproduce the behavior no matter how many times I queried the power supply. However, there is a discrepancy between sending the "Initiate" command from within code versus using the communicator and sending "*IDN?", so I am unsure how to replicate the same steps. My previous post detailed the SPY log in response to sending the "Initiate" command, while sending "*IDN?" results in:

1.  ibwrt(UD0, "*IDN?", 5 (0x5))
Process ID: 0x00000F58         Thread ID: 0x00000330
Start Time: 16:25:12.437       Call Duration 00:00:00.000
ibsta: 0x100       iberr: 0             ibcntl: 5(0x5)

2.  ibrd(UD0, "LAMBDA,GEN40-...", 2000 (0x7D0))
Process ID: 0x00000F58         Thread ID: 0x00000330
Start Time: 16:25:12.437       Call Duration 00:00:00.359
ibsta: 0x2100       iberr: 0             ibcntl: 45(0x2d)

My app uses VISA commands while the communicator uses "ibwrt", etc. How do I go about simulating the "Initiate" call while using the Communicator? My code is posted at the bottom of this reply for clarity.

An oddity that is that, after a failed attempt to initiate the device which results in a timeout exception, the communicator can be used to read the standard response to the "*IDN?" command. This is the case even if the "idQuery" boolean of the "initiate" method is set to false. If idQuery=true, how is the resulting name supposed to be read back? The initiate function does not have a return value or any way of passing by reference. I tried all four combinations of the two flags, "idQuery" and "Reset", but nothing seemed to change in any configuration.

In response to your question about the firmware version, I pulled this from the spy file: "LAMBDA,GEN40-85-IEMD,S/N:xxxxxxx,REV:2U:3.0-D-". The reply appears to be truncated so I'll double check the response on Monday once I'm at the computer with the SPY file.

Again, thank you for input and attention. If you have any suggestions, please let me know. It will be sometime next week until I will be able to perform any more troubleshooting unfortunately. Do you see anything wrong with the "Initiate" method call, especially the name used? I'm curious if I should use the full name instead of the alias, but if that is the case why does the "initiate" call work the 2nd time? Oh well, I'll give it a try. Thanks again.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

using Ivi.DCPwr.Interop;
using Ivi.SessionFactory.Interop;

namespace IviDcPower
{
    public partial class Form1 : Form
    {
        IIviDCPwr _DcPwrSession;
        IIviDCPwrOutput _IiviDcPwrOutput;

        public Form1()
        {
            InitializeComponent();
        }

        private void btnCreateSession_Click(object sender, EventArgs e)
        {
            try
            {
                IIviSessionFactory factory = new IviSessionFactoryClass();

                // Ask the session factory to create an instance of
                // the appropriate driver based on a logical name
                _DcPwrSession = (IIviDCPwr)factory.CreateDriver("ProgDCPS");
                addText("Session created");
            }
            catch (Exception ex)
            {
                addText(System.Reflection.MethodBase.GetCurrentMethod().ToString() + "\r\n" + ex.ToString());
            }
        }

        private void btnInitialize_Click(object sender, EventArgs e)
        {
            try
            {
                addText("Initializing...");
                _DcPwrSession.Initialize("ProgDCPS", cbQueryID.Checked, cbReset.Checked, "");
                if (_DcPwrSession.Initialized)
                {
                    // Use IIviDcPwrOutput class-compliant interfaces, interchangeable code
                    _IiviDcPwrOutput = _DcPwrSession.Outputs.get_Item("");
                    addText("Success");
                }
            }
            catch (Exception ex)
            {
                addText(System.Reflection.MethodBase.GetCurrentMethod().ToString() + "\r\n" + ex.ToString());
                addText("Failed (Exception)");
            }
        }

        private void addText(string text)
        {
            textBox1.Text = text + "\r\n\r\n" + textBox1.Text;
        }

        private void btnCloseSession_Click(object sender, EventArgs e)
        {
            try
            {
                _DcPwrSession.Close();
                addText("Session closed");
            }
            catch (Exception ex)
            {
                addText(System.Reflection.MethodBase.GetCurrentMethod().ToString() + "\r\n" + ex.ToString());
            }
        }
    }
}

[trock9]

Was any solution found to this problem? I am having similar problems.

[sammy-e]

Afraid not, we just implemented a 'retry' on failure work around.

[odubhain]

I have the same problem with Soresen/Ametek XG series supplies when initiating using VISA based VIs. It's mainly when sending IDN? queries and I had to put a retry in. If I send the GPIB commands directly in NI Max there is no problem. If I run execution in Highlighted mode, there is also no problem. No matter how I try to simulate the error on VISA Reads for these supplies, I get intermitent errors on the reads.

Looping the VISA Read is not a good solution as the XG buffer gets filled with extraneous data left over if a read was not completed before the next loop or command action. This causes some squirrely behavior further down the line when setting levels for voltage, currents, OVP and such.

Is there some way to create a native delay or repeated polling in the NI-VISA Read function without having to do this externally in LabView?

[sammy-e]

I never found a proper solution so we were stuck with the work around. After implementing the work around, I have not encountered any issues - though our control of the power supply is very simple so that may be the difference between our situations.

If you ever do find a fix, I would be ecstatic to hear about it so please share. Thank you.