LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

keithley 6517b initialise

Hallo ,

 

The program was working fine until recently i opened this after a gap of 2 months and the keithley initialise vi is not working . It gave me a warning that the expected dependancy was loaded from a different path but the connections are broken in the vi. And it does not work if i replace the vi . I have no clue why it stopped working all of a sudden.

 

Kindly help .

Thanks and best regards ,

DPS

Download All
0 Kudos
Message 1 of 7
(4,180 Views)

Did you create a project where you included your VIs? From a project you can easily resolve a conflict of loading the vi from a different path. Did you save either the project, the VI or the Keithley Init VI somewhere else? Were there other changes on your computer?

 

Is the Keithley VI itself still working? Does it have all it's connectors. Did you try rewiring your in- and outputs manually?

 

Please give some more information.

 

Best,

 

Anna

Anna Vogl
Certified LabVIEW Developer
Message 2 of 7
(4,120 Views)

Dear Anna ,

 

No i do not have a project with all the sub vi's. I used the sub vi from a previous copy i had , manually wired it and now the program is executable. But i am facing a command header error now (displayed on the instrument-although the program still runs) . I am unable to locate the source of this error. 

Any ideas on  how to locate in which part it is happening. Used the highlight execution and tried but of no help.

 

Thanks and best regards ,

DPS

0 Kudos
Message 3 of 7
(4,111 Views)

So no LabVIEW error occurs but you see the error on your Keithley, right?

If connection and genereal communication to the Keithley work (Did you try the *IDN? in the VISA Testpanel in MAX?), you problably have to contact Keithley support. We don't know what commands or headers your device expects.

 

You can use the other debug tools in LabVIEW (step by step execution) to see when the error occurs. Maybe we can still figure out what causes the error.

 

Best,

 

Anna

Anna Vogl
Certified LabVIEW Developer
Message 4 of 7
(4,095 Views)

I'm thinking there is more than one version of this driver on the computer and somehow, maybe a different project someone is working on has called it, adding that to the search path.  (This would indicate a systemic problem of developers not communicating with each other, but that's beyond the scope of this reply.)

 

When the dependencies change, LabVIEW gives you a chance to save that info.  Do you have it?  That's the easiest way to figure out where the originals are (short of the project conflict resolver whcih I see is not an option at this point).

 

Moving forward, keep everything in LabVIEW projects.  There are so many advantages to doing this that there are entire threads devoted to this one subject.  Pay attention when LabVIEW says it resolved dependency issues.  Save the info.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 5 of 7
(4,083 Views)

Dear Anna ,

 

yes the labview program and the device is working . I tested the idn query and also some basic control with labview example programs and they all work . Thanks for your ideas. I have to try the step by step execution to spot the error.

 

Best regards ,

 

DPS

0 Kudos
Message 6 of 7
(4,078 Views)

Dear Bill,

 

Yes. In fact there are 3 versions of the same driver at several places and I don't know whether another program is also calling this vi . (mostly i think is used by other programs also) . I dont remember being asked to save such information. Thanks for your tip. Ill keep that in mind.

 

thanks and best regards ,

 

DPS

0 Kudos
Message 7 of 7
(4,072 Views)