Error 2 when reading the code

[smallboy31@mail.ru]

Hello,

I have a Keithley 2002 which I would like to use to acquire reading at a high speed. 

I have found the attached Plug&Play drivers for the LabView and there is VI which is called Burst Mode. 

The problem is that the code is not working. The GPIB address is 100% correct so I don't understand what is the problem.

If anyone has any clue please let me know. 

Best regards,

Sergejs

[altenbach]

These libraries look almost prehistoric. 😮

You have only attached the drivers, but you are not telling us how you are calling them. Are all inputs correct? Can you show us a simplified version of the caller?

[smallboy31@mail.ru]

Hi altenbach,

Thanks for getting back <3.

This is true. After spending some more time I decided to omit using this old VI.

Instead I have created my own VI using Visa W and R commands and manual (keithley 2002).

There are no problems with the code anymore BUT the speed with which instrument acquires readings is much slower than I expected.

For instance at 1 PLC there is a roughly 0.07s delay between measurements and for 0.01 PLC the delay is 0.05s.

The 0.05s is too slow for me. I assume that problem is with the way I have created VI itself.

Can you please have a look at the attachments (sorry about the screen photo - that PC is in the lab, it has not internet and its W7 hehe).

Many thanks in advance!

Best regards,

Sergejs

[LVNinja]

One thing that may be slowing down is the File Saving Vi. 

You can open the file before the loop and just write the file during the loop and close it after the loop is over. 

The Write to spreadsheet file vi open and closes the file every loop iteration. 

[JÞB]

I see a few things that are questionable but first, clean up that nasty backward flowing file path wire!  (I just can't unsee that, and my eyeballs nearly bled!)

• Get rid of the remove whitespace.vi. It is not designed for speed and in fact is slow.
• For high throughput from that device you MUST NOT depend on the default TRIG:IMM. That causes the device to wait for each READ? before starting each measurement.  Go through the manual again for tips on how to acquire readings at high speed.  I know those paragraphs exist!
• 5 digits at 0.01 NPLC seems unlikely.  Period.  You will have to trade off resolution for speed.

[smallboy31@mail.ru]

Hi LVNinja and JÞB,

Thank you for getting back.

Before completely changing the acquisition method as was mentioned by JÞB, I have decided to implement your other possible solutions to see how they would improve the speed.

I hope I understood everything correct (if not please pardon my poor LV experience). I never had intentions to damage someones eyesight.

In essence, new architecture was edited as it can be seen in the attachment (photo).

The speed was improved from 0.05s to 0.04s only. 

I will now try to investigate if I should come back to my original idea of using Burst and SSTR methods to improve the acquisition speeds unless you will point anything else to me.

Again, thank you very much for your time! I appreciate your help.

Kind regards,

Sergejs

[LVNinja]

Try creating a vi without the file IO just to measure the reading time. 

My suggestion : Execute on a FOR loop instead of while (just for assessment purposes), run 100 times to measure an average time. That will give you the response time for the whole system, sending comand, instrument responding and reading the response. 

If that loops is still slower than you require, then you may be reaching the limit of your system (i'm not familiar with the speed limit of GPIB, so apologize my ignorance). 

[JÞB]

---

@LVNinja wrote:

Try creating a vi without the file IO just to measure the reading time. 

My suggestion : Execute on a FOR loop instead of while (just for assessment purposes), run 100 times to measure an average time. That will give you the response time for the whole system, sending comand, instrument responding and reading the response. 

If that loops is still slower than you require, then you may be reaching the limit of your system (i'm not familiar with the speed limit of GPIB, so apologize my ignorance). 

---

GPIB is faster than you think. The PHY layer is not going to be the issue.

I mentioned before that the device user manual has information in it on how to optimize measurement speed.  I know because I have used that device and had to carefully read those sections.  I don't have the need myself to review that information today.  

@OP YOU DO have the need to carefully review that device user manual today.  LVNinja's advice about creating a "Sandbox" vi to just test measurement speed is excellent!

Another tip.  Instead of attaching vis ... use snippets (edit >> select all,  edit >> create snippet from selection) and place that image inline on your posts. It will help us help you. 

BONUS KUDOS OFFER today only!  For the first poster that searches my profile for the tag related to a link ta posts containing a "Jing" video on creating snippets... try "JING how to" my tag cloud is a mess.

[LVNinja]

That's a nice tip !

[cstorey]

I've never done truly high speed measurements with a Keithley 2000, but the theory is always the same; use the instrument to store as many readings as possible, taken as fast as possible in the internal memory.   Then once the measurement is completed, transmit the readings to the PC. 

A quick glance at the manual - https://www.slac.stanford.edu/grp/cd/soft/epics/site/gpib/2002_900_01D.pdf  shows two good examples of how to do this.  It also mentions that the scanner cards only have 2 high speed channels, 5 & 10.  Are you using the scanner and those channels?  

Examples on page G-12 and G-14 shows the use of internal memory and reading back the memory or the stats on that memory after the measurement.

Post your snippet when complete. (Snippet How To)

Craig