~~ using RS232 to SCPI (keithley), and noise comparisons/mods

[3roomlab]

hello SCPI-ers, im new to the new territory of SCPI-ing (on a used keithley 2015).
i recently learnt some python (from here and various pieces all over the web) to enable RS232 comms to this DMM beast.

while being able to see FETCh work, there have been other commands which i find wasnt being able to get thru. i hope some veterans will shed some light on issues or workarounds.

what has been working for me?
PC(WinXP SP3) --> python 2.7 --> PYSERIAL 2.7 --> USB(RS232) PL2303 --> K2015(DMM)
the max stable :FETCh rate (with 4.8kbps) is 17Hz approx

however, while i did not try everything, it seems, :FETCh is the only thing that works.

A) example this, doesnt change the ASCII out to float  -- ser.write(':FORMat:DATA DREAL')

B) and this :

ser.close()
ser.open()
ser.write(':DISP:ENAB 0')
time.sleep(1)
ser.write(':DISP:ENAB 1')
time.sleep(1)

error 120 happens (and the display does not flick off and on), and the next round of data FETCh results in strange reads. could it be that certain RS232 adapters dont work well? or there needs to be some pre-prepping commands to reset the DMM?

C) another example, i wanted to try to enable autozero (eg : for DMM noise logging). it doesnt seem to respond 

**update** solutions solved
A) on RS232, all comms are limited to ASCII (duh lol because it is RS232). the DREAL can only be used in GPIB mode
B) PROLIFIC xmit problem (recieve is ok)
C) PROLIFIC xmit problem (recieve is ok)

FTDI has no problems in XMIT but has significantly higher latency. for FTDI to work, higher delay timers have to be used in coding in order to WAIT FOR it to do its stuff lol

[3roomlab]

:NPLC? condition query scenario

Code: [Select]

import time
import serial
import array
# configure the serial connections
ser = serial.Serial(
port='COM3',
baudrate=4800,
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS,
xonxoff=True,
timeout=3,
rtscts=False,
dsrdtr=False
)

ser.close()
ser.open()
ser.isOpen()

while True :
#ser.write(':SENS:VOLT:DC:NPLC 10')
#time.sleep(0.5)
ser.write(':SENS:VOLT:DC:NPLC?\r')
time.sleep(0.2)
out=''
C2 = 0
C1 = ser.inWaiting()
AA1 = ''
print " SER",C1
#array.CC(c) = 0
while ser.inWaiting() > 0:
AA1 += ser.read(1)
C3 = ser.inWaiting()
TT = "{:+9.2f}".format(time.clock())
print TT,"- SER-",C1 ,"- SS-",C3 , "- AA1-", AA1, "-|"
#if AA1 != '' or '\r' :
# AA2 = bin(int(AA1))
# print "AA2", AA2
# AA2 = format(AA2, '08b')
# print "AA2", AA2
# AA3 = format(AA2, '08b')
# print AA1, AA2, AA3
#out=out.rstrip()
# print (time.time(),out)



else : exit()
 

screen grab

[3roomlab]

test log

999 samples capturing @ 2Hz, unit = used keithley 2015 (un-calibrated for 5++ years, zero maintenance done so far except for cleaning of banana sockets). NPLC = 1, window/aperture =1, filter = off, REL/autozero = off (manual zero-ing in xls), scale=100mV, RH = approx 70%, T_a = 28.5^oC. shorting main jack only with wire.

its much more noisier than what i expected by 2-3 times hmmm (Y scale is uV, X scale is seconds)

[3roomlab]

i think i have somewhat concluded my adventures into exploring SCPI via RS232.
i have included a block diagram of what i did to the python program, python examples on pyserial to SCPI seems to be not very popular, even in EEVblog/keithley-forums there is not many examples (see attached text file python example on a working sample, version 2 simplified with error tolerance)

ser.write(':SENS:VOLT:DC:NPLC 10\r')
ser.write(':ABOR\r')
ser.write(':SYST:AZER:STAT ON\r')
ser.write(':INIT\r')
(the above lines can be added for K2015 to state AUTOzero = ON and NPLC = 10

i think as a python noob if i could do it, somebody else could use it and form their own version for what ever they are trying to log/measure. the 29999 sample ( (@1.5Hz) bean counter plot (using opencalc), NPLC 10, autozero on, filter off, 100mV. nearly a bell curve.) is using a further evolved version, including error avoidance and delay self adjustment (as said in the block diagram). so it could log on and on and on as long as RAM permits. there is a small quirk to xlwt though, it seems once saving starts, there seem to be a memory leak which will cause the reading latency to increase until it affects the cycle to cycle FETCH timing and crash, while it is possible to override the errors, the timing consistency will be affected. so extremely long logs will be interesting and possibly challenging (days? weeks?)

tools used for the coding
1) python 2.7
2) pyserial 2.7
3) xlwt (for writing to xls file format)

what is not needed in this ? --> pyVISA? keithley drivers? keithley utilities? ALL NO
you need to however read the manual in detail (even though it is not in detail enough to properly explain the SCPI syntaxes in some areas). i know sounds like something is wrong with not needing what lotsa people are already using (VISA? GPIB?), but that is esp true if you dont wanna spend that much $$$ on GPIB interface. each pc is upwards of USD$100, as oppose to USD10-30 RS232 (amazon has the 4 port FTDI for about USD$47). i am not sure how many ports can a PC hold? COM29? COM99?

in this exploration adventure, i have also discovered (or felt that...) that the various RS232 interfaces may have been somewhat crippled to a low speed. while GPIB are high speed specified, RS232 are not little mice, does implementing high speed RS232 require hefty license fee?

(in my over excitement to ask questions about SCPI/GPIB/RS232/logging, i have also posted in
https://www.eevblog.com/forum/projects/is-this-a-real-ns-lm399-%28from-polida-ebay%29/
https://www.eevblog.com/forum/testgear/keithley-2015-measurements-with-computer-display/msg772298/#msg772298
if you are beginner in trying SCPI, there is sadly not much to read, but hopefully this will help resolve some RS232 questions

and this is the thread that started it all
https://www.eevblog.com/forum/testgear/dmm-adc-noise-comparison-testing-project/
)

exit()

(i should be able to try more samples when i have cleaned up the DMM and compare the noise bell curve, NOW that would be interesting if changing fresh components will decrease overall internal noise, and it is my curiosity in the first place when i saw the DMM noise thread, and possibly, what else could you possibly improve to reduce noise even further?)

[3roomlab]

a little bit of update

post recapping, burning in plots of (input shorted) noise bell. 1NPLC @ 5Hz (9999 samples per plot) autozero = on, 100mV DMM scale, filter = off.
on initialization, the noise curve centres around +2.5uV (mean calculated)
as time goes, the bell shifts about -0.4uV per hour toward zero downwards (see plots 11 - 22 - 33)
mean calculated at start approx 2.397uV, mean deviation 0.53uV
mean calculated at 3rd jpg approx 0.447uV, mean deviation 0.5uV

by the time the logging reached the 5th set of logs (pic 44.jpg), mean calculated = approx 0.112uV, mean deviation 0.498uV. 1 very interesting finding i observed is that, this DMM seems to love to work well when hot, in the region of 40^oC (external box case temp). and so i used a towel to experiment (increasing the temp) impeding heat dissipation thru the metal case (still on going). with the case on i think the inside have to be really hot, i guesstimate 50^oC ++.

**edit : throughout the logs there are consistent 1uV-ish spikes and i wonder where they might come from. anyone can give me a clue how to kill more noise to log more "silently" ? mod/add more bypass caps ? shield the input/sense direct from the PCB to socket?

[3roomlab]

example of noise drifting as i shifted the position of the covering towel