GPIB

[Aminnie]

Spoiler

Hi,

   I use GPIB card to communicate with PC and Keithley 2602. the driver used for them:

    1. Keithley 2602 : Ke26xxA[1].1.2.2.0

    2. GPIB card : ni488223.exe

  I download script commands first by reading scripts from tsp file. and run test cycles below:

       for(;

       {

         .....

          turnOnSMU(); --> script command to turn on SMU

          runSIMV();  --> here use command WriteString to download script.

          reportResult(); -> script command to report result.

          TurnOffSMU(); --> script command to turn off SMU

          .....

       }

and the problem commes after run around 8000 ~ 10000 times, the test cycle timing suddenly become long. e.g, from 25ms to around 165ms. and I find that:

 1. each command to download script (WriteString) become around 16ms (the original normal case is around 1ms). e.g, the command TurnOnSMU cosumes 16ms , it only download "smu.source.output = smu.OUTPUT_ON" by writestring command.

2.  if power off and power on keithley meter, the timing is still abnormal.

3.  if power off PC, then the timing will become normal.

4.  and I tried another PC2, the timing is abnormal even when I reboot PC and keithley meter both.

also, I use your sample program for c++ to test. and find if the timing is abnormal, then it will consumes 16ms for Writestring command.

void CSimpleSourceMeasureDlg:nBnClickedInitializeButton()
{
try
{
UpdateData(TRUE);

if (m_spDriver->Initialized)
{
m_spDriver->Close();
}

_bstr_t bstrOptions = "QueryInstrStatus=True";

m_spDriver->Initialize(LPCTSTR(m_strResourceDescriptor), VARIANT_TRUE, VARIANT_TRUE, bstrOptions);

//add here to test script command communication time. it will cost 16ms for abnormal case while 1ms for normal case.
int t1 = GetTickCount();

CString strLine;
strLine.Format("DEBUG = %d\n",0);
m_spDriver->System->DirectIO->WriteString((LPCTSTR)strLine, VARIANT_TRUE);

int t2 = GetTickCount();

CString str;
str.Format("DEBUG = 0: %d",t2-t1);
AfxMessageBox(str);

}
catch (_com_error& ex)
{
::MessageBox(NULL, COLE2T(ex.Description()), _T("Ke26XX Simple Source Measure"), MB_ICONERROR | MB_OK);
}
}

I have no idea about this  and could you help me ?

BR,

Amy

[Curt_C]

Hi,

I've used TSP with a Keithley 2601B.

I'm assuming that your not realy turning of the meter in your loop, but setting back to local mode.

for(;

       {

         .....

          turnOnSMU(); --> script command to turn on SMU 

          runSIMV();  --> here use command WriteString to download script.

          reportResult(); -> script command to report result.

          TurnOffSMU(); --> script command to turn off SMU

          .....

       }

that said, once you load your test script, you don't need to load it again unless you actually power off the meter.

Initialize to GPIB

Load Test Script

then

for (;;)

{

  RunScript

  Read printbuffer

}

Curt

[Aminnie]

Yes. It's just the sequence.

today, I reinstall the keithley driver , the latest version Ke26XXA (v1.4.5). and find:

1. PC1 : the timing issue disappears.  the communication command to download become normal around 1ms. It is normal whatever I quit the program and run the problem again.

2. PC2 : the timing is normal during running test cycle. but after quit the program, the timing become abnormal after restart the program again.(the script download command costs 16ms again).

I suspect the device driver of keithley conflict with some other hardware device drivers installed in PC2. How can I know the reason?

Thanks.

[Aminnie]

Sorry, for PC1 above, I reboot PC and reboot Keithley meter both, then start the program, the problem appears again. the communication command become very long. (16ms for 1 writestring command).

[Aminnie]

Hi,

I plan to install IO Layer and Ke26xx driver again. but when I install KIOL-850C05.exe, an error message pop up "This application requires National Instuments IVI compliance package.Please install NI-ICP then run this installer again.details:IVIStandardRootdir not found in the system registry."

where to find NI-ICP ?

[Dennis_Knutson]

Click the Support link at the top of the page. Search for IVI.

[JÞB]

I've never really gotten to the root cause but I do know from painful experience that Keithley devices really hate being initiallized frequently.  Reset the device all you want but, open the session once when your app starts and close it once when the app exits and you'll stop seeing this odd Keithley behavior.

[Aminnie]

I reinstall all of keithley device driver,GPIB and IO Layer . and find the GPIB communication command timing is abnormal. though I reinstall KE26XXA device driver again. it still does not work.

[c.jain]

Dear All,

I am fairly new to the labviw. I have written a program to communicate with the Princeton Reserch Systemes Delay generator DG-535 using GPIB. It works fine! however I have smll problem here. Once I establish the communication to DG535 using labview program it blocks the manual operation of the DG535. I can not access any channels untill I restart the DG535. I tried closing the labview program to see whether the communication is terminated and I can access the DG535 maually but it did not work. Anyone in this forum had the similar problem? whether it is normal or not. If it is not normal then what is the solution to stop the communication to DG535 via GPIB and reactivate the manual access without retarting the DG535.

Thank you very much in advance.

Best regrads

Chaithanya

[JÞB]

Oh those silly Standford Research System engineers,  Press the Keypad "Mode" key, labled:

<>

NUM

REM

in the center of the front panel to switch back to "Diet Mode"  (Lo-Cal, or "Local" operation.)  You may need to close the VISA session to un-address the instrument first.  those silly engineers butchered the IEEE 488 standard by designing the device to assume a remote lock with the REN handshake line active.

Its a good Idea to start you own thread when the topic changes.  The DG535 has little in common with the OP's Keithley unit.