I am trying to use a Keithley 2015 THD DMM to measure THD of an audio circuit. Unfortunately the only driver i can find comes from the tektronix website and was made for LV 5.1.1. I have started with the instrument driver creation wizard and things seem to be going in the right direction but I have never created an instrument driver before and was wondering if anyone has had any experience creating a driver for this particular instrument... any advice / assistance would be greatly appreciated. i would like to accomplish this using a gpib-enet/100 in LV 2016 on a Windows 7 machine.
Solved! Go to Solution.
Yeah thats been the path ive been taking, however it was a little difficult to pick which template to use since its kind of a DMM and also a signal generator. Thanks for the suggestion of using the 2000 as an example. I was using the 2400 series driver as an example already but didnt know about the 2000. Im slightly tempted to see if there is a way to convert the LV 5.1.1 driver to 2016 but it seems like it just might not be possible/practical to span that far of a gap.
p.s. im also new to scpi just to make it really fun.
thanks again for the suggestion of using the 2000 driver as an example. it all went pretty smoothly, the only problem i am having is doing the multiple dist / amplitude sweep. i developed my own and also used the example from the manual on page 2-45 but no matter what way i do it i always end up with data from the previous run or with non-updated info from the data buffer. When i run the example from the manual because of the *rst at the beginning i always get all 0's as my read data, however if i run the scpi command outp:list:data? a second time then i get the measurements that were actually taken. If i take out the *rst then i get the readings from the previous run until i send outp:list:data? again. Also just as a minor annoyance/humorous glitch i have found my 2015 returns a label of volts:dc when returning a value for thd percent. anyone else have either of these these issues before? i have uploaded a vi i created from the example in the manual.
Thanks for posting your code for reference. One of your sub VIs (Error Query.vi) did not open for me in LabVIEW 2016, but I believe I understand what you're attempting.
Since you have the Keithley 2000 driver which you know works, I would recommend running this same Sweep function from that driver and doing an I/O trace. Then, using your code, do an I/O trace as well and compare the calls that were made. This would be able to show you where you start obtaining incorrect and duplicate information and should tell you how to alter your code.
the error query can be removed and it wont make any difference. I really just used the 2000 driver as a structure model...it doesnt work for the 2015 directly and as far as i know the 2000 doesnt have a sweep source and measure operation. My question is why does the new data not make it into the data buffer when using the example from the manual on page 2-45? Also, why does it work when i re-send the final command of the example utp:list:data? .... it seems to me that this is a timing issue but im not well versed enough in scpi to correct it. i have also tried using the waitSRQ vi after the initial write and before the read but that also does not seem to work. I am not getting any errors it just doesnt seem to be working correctly. I have attached the vi without the error query so anyone should be able to run in on 2016. i have also attached the vi with the necessary re-send that should not have to be run. any help would be greatly appreciated.
Ok so i figured it out. The solution was simple in the end but the manual only hinted at it. I needed to add a wait for srq after the manual example up to the INIT; command, then send another write to the instrument of : outp:list:data? after the waitSRQ vi, that updates the buffer data to the most recent readings. Zoe, that trace I/O was really helpful in some other issues i had in creating other parts of this driver, i didnt know that could be done, thanks for the tip.
Glad to hear that you were able to figure out the necessary commands from the manual and the I/O trace was able to help you with other issues! Good luck with the rest of your driver development.