chroma dc power 62000 init error

[svacek]

Have been using the Chroma 62000 series power supplies with Labview via USB for about a year now.  I occasionally experience a problem where the device wont respond to any init or config commands.  In the past, this usually only happens if the device sits idle for a period of time(typically 60 minutes or more).  Recently, our contract manufacturer has been seeing this issue occur after after just a minute or two of downtime between switching out UUT's in our test fixture.  When wetry to run the initiate.vi I get the following error:

"chr62000 Initialize.vi Driver Status: (Hex 0xBFFF003E) Could not perform operation because of I/O error. Elaboration: Attribute: IVI_ATTR_INSTRUMENT_MODEL VISA: (Hex 0xBFFF003E) Could not perform operation because of I/O error. [Error Code: -1073807298, User-defined error code.]"

I can open the Visa Test Panel in MAX and the device respond to queries.  However, the only way to restore normal operation in LabVIEW is to restart the PC.  

Anyone every come across similar issues?  Thoughts?

[yamadj]

Hello svacek,

It seems that there are a bunch of reasons why this error could be happening. I'm a bit unsure of what excatly is the cause but the first article seems pretty applicable.

Error -1073807298 with a Third Party Instrument Driver - http://digital.ni.com/public.nsf/allkb/B99D923DFC18555786256F15004B87B0?OpenDocument

Error -1073807298 Occurs after a VISA Read/Write - http://digital.ni.com/public.nsf/allkb/60DDFED7EFEFE7188625705700750821

Error -1073807298 When Using a Third-Party USB-Serial Adapter - http://digital.ni.com/public.nsf/allkb/0C2ABA463217342686256E2E006DF187

Something that would help everyone in the forums as well as me is trying to get an I/O trace of the error. If you can reproduce it reliably then we should be able to get a good trace of the error which you can attach.

Performing a Good NI I/O Trace Capture for Debugging/Troubleshooting - http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9

[svacek]

Update.    After some trial and error, I can reproduce the error as necessary...turn off the power supply and run the test sequence in TestStand.   I did get a recommendation from Chroma to make sure the windows wasnt shutting of the USB root hubs so I wnt in and disabled that option for each root hub.  

Here's my most recent observation:  once the I/O error occurs, it will continue to occur until the test sequence is closed and reloaded.  or...  untiI change the labview adapter, which reloads all of the code modules.  After performing wither of those two actions, operation returns to normal.

The test sequence steps have since been set to load dynamically and unload after step execution, but neither seems to help retstore correct operation following the I/O issue.

[yamadj]

Hey svacek,

Hey can you still reproduce this outside TestStand like just in LabVIEW?

If not how is your LabVIEW adapter configured? Is it set to Development Environment or Runtime Engine?

If your code works well in the Development Environment but not in the Runtime Engine, you might try mass compiling all of your code (including your driver) to force it all into the same version of LabVIEW.

[svacek]

Additional troubleshooting revealed that I can indeed reproduce the error in LabVIEW (outside of TestStand).  Same steps as before: Open the VI, Turn off the power supply, Run the VI, Turn the power supply ON.  The VI continues to error until I close all instances of LabView, then re-open.

One thing I did notice is, in the Drop down menu for the Instr Handle control, there are multiple "PS1" handles or sessions to choose from. "PS1", "PS1-1" , "PS1-2", "PS1(1)", "PS1(2)" ...Odd since we only have PS1 and PS2 connected to the machine.

[yamadj]

Hello svacek,

To me that sounds very much like your application or the driver itself is not closing references out properly; especially because we have duplicates of handles as you mentioned above.

Would it be possible for you to check your code and see if things are not closing out properly? An I/O trace can also be helpful in debugging that behavior since it'll probably throw out reference errors or something of similar nature in the trace.