Re: Exact integer-valued floats
On Sep 22, 2012, at 7:06 PM, Dave Angel wrote: > On 09/22/2012 05:05 PM, Tim Roberts wrote: >> Dennis Lee Bieber wrote: >>> On 22 Sep 2012 01:36:59 GMT, Steven D'Aprano wrote: For non IEEE 754 floating point systems, there is no telling how bad the implementation could be :( >>> Let's see what can be found... >>> >>> IBM 360: Same as Sigma-6 (no surprise; hearsay is the Sigma was >>> designed by renegade IBM folk; even down to using EBCDIC internally -- >>> but with a much different interrupt system [224 individual interrupt >>> vectors as I recall, vs the IBM's 7 vectors and polling to find what >>> device]). >> The Control Data 6000/Cyber series had sign bit and 11-bit exponent, with >> either a 48-bit mantissa or a 96-bit mantissa, packed into one or two >> 60-bit words. Values were not automatically normalized, so there was no >> assumed 1 bit, as in IEEE-754. > > And it's been a long time (about 39 years), but as I recall the CDC 6400 > (at least) had no integer multiply or divide. You had to convert to > float first. The other oddity about the CDC series is it's the last > machine I've encountered that used ones-complement for ints, with two > values for zero. > > Well, for what it is worth… the DEC Laboratory INstrument Computer (LINC-8, sort of a forced acronym because I believe they were built to specs issued by Lincoln Labs.) and the later DEC PDP-12 (which incorporated the LINC-8 instruction set, along with the PDP-8 basic set) also did ones-complement integer arithmetic. I never used a LINC-8, but I worked for several years around PDP-12s. (They also had a build-in CRT and a MUX'd analog-to-digital converter with CPU instructions for driving both directly.) As I remember, they maxed out at 32k (12-bit) words of RAM. I don't know when they were discontinued, but there were still some PDP-12s in use as late as 1988 when I lost track. -Bil > -- > > DaveA > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a TimedRotatingFileHandler not to put two dates in the same file?
On Oct 24, 2012, at 10:22 AM, David M Chess wrote: > >> This works great, splitting the log information across files by date, as > >> long as the process is actually up at midnight. > >> > >> But now the users have noticed that if the process isn't up at midnight, > >> they can end up with lines from two (or I guess potentially more) dates in > >> the same log file. > >> > >> Is there some way to fix this, either with cleverer arguments into the > >> TimedRotatingFileHandler, or by some plausible subclassing of it or its > >> superclass? > > Tx, > DC (After a VERY brief scan of the logging cookbook and modules.) I don't think you have any choice but brute force. If the program wasn't up at midnight, then somehow it got restarted. You will have to add logic to the restart code (or to the program itself that gets run as it initializes). Something like: Does a log file exist? -> No -> First run; create log file & continue | Yes | Read backwards looking for date change, copy lines after change to new file, delete from old file. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
On Nov 7, 2012, at 11:51 PM, Andrew Robinson wrote: > On 11/07/2012 04:00 PM, Steven D'Aprano wrote: >> Andrew, it appears that your posts are being eaten or rejected by my >> ISP's news server, because they aren't showing up for me. Possibly a side- >> effect of your dates being in the distant past? > Date has been corrected since two days ago. It will remain until a reboot > Ignorance, though, might be bliss... > >> Every now and again I come across somebody who tries to distinguish between >> "call by foo" and "pass by foo", but nobody has been able to explain the >> difference (if any) to me. > I think the "Call by foo" came into vogue around the time of C++; Eg: It's in > books like C++ for C programmers; I never saw it used before then so I > *really* don't know for sure… > Just as an aside - there is a famous quote from Niklaus Wirt, who, when asked how he pronounced his name, is said to have replied: "Well you can call me by name, Veert, or you can call me by value, Worth." That would have been sometime in the early 60s, when he was at Stanford. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with module PyVisa
On Nov 9, 2012, at 3:43 PM, Jean Dubois wrote: > > The error may be obvious but finding this file and how to install it > is not unfortunately. > It seems I have to install it from the National Instruments site but > Debian Linux doesn't seem to be supported... > and I doubt whether just copying this file will be sufficient to make > PyVisa work. > I wonder whether there might be another way to communicate via USB > with a Keithley programmable power supply using Python. > > best regards, > Jean > > > > -- > http://mail.python.org/mailman/listinfo/python-list I've been using pyserial quite successfully to control a USB-to-serial converter. That is, controlling a couple of RS232 serial devices via the USB port through a KeySpan USB-to-Serial converter. Pyserial seems to make communication through the USB port quite transparent, at least on my OS-X system. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Subprocess puzzle and two questions
I need to time the operation of a command-line utility (specifically nslookup)
from within a python program I'm writing. I don't want to use python's timeit
function because I'd like to avoid python's subprocess creation overhead. That
leads me to the standard UNIX time function. So for example, in my bash shell,
if I enter:
$ time nslookup www.es.net 8.8.4.4
I get:
Server: 8.8.4.4
Address:8.8.4.4#53
Non-authoritative answer:
www.es.net canonical name = www3.es.net.
Name: www3.es.net
Address: 128.55.22.201
real 0m0.069s
user 0m0.006s
sys0m0.004s
The first lines are the result of an nslookup of the IP address of "www.es.net"
using the server at 8.8.4.4 (Google's public DNS server b).
The last three lines are what I'm after: the real elapsed wall-clock time, the
time spent in user space and the time spent in kernel space.
However, if I try the same operation in the python interpreter using
subprocess.Popen like so:
>>> import subprocess
>>> result = subprocess.Popen(['time', 'nslookup', 'www.es.net', '8.8.4.4'],
>>> shell = False, stdout = subprocess.PIPE, stderr =
>>> subprocess.PIPE).communicate()
>>> print result
('Server:\t\t8.8.4.4\nAddress:\t8.8.4.4#53\n\nNon-authoritative
answer:\nwww.es.net\tcanonical name =
www3.es.net.\nName:\twww3.es.net\nAddress: 128.55.22.201\n\n', '0.06
real 0.00 user 0.00 sys\n')
And the timing information I'm after has been truncated to two digits after the
decimal. It appears that Popen is applying a default format. If I do explicit
formatting:
>>> time = result[1].lstrip().split(' ')[0]
>>> formatted_time = '{: >7.3f}'.format(float(time))
>>> print formatted_time
0.060
I get three digits, BUT that third digit isn't real, the format operation has
simply appended a zero. So:
1) how can I recover that third digit from the subprocess?
2) is there a more pythonic way to do what I'm trying to do?
python 2.7, OS-X 10.8.2
Thanks in advance -
Bill Wing
--
http://mail.python.org/mailman/listinfo/python-list
Re: Subprocess puzzle and two questions
On Nov 14, 2012, at 9:22 AM, Roy Smith wrote: > In article , > William Ray Wing wrote: > >> On Nov 13, 2012, at 11:41 PM, Roy Smith wrote: >> >>> In article , >>> [email protected] wrote: >>> I need to time the operation of a command-line utility (specifically nslookup) from within a python program I'm writing. >>> >>> Ugh. Why are you doing this? Shelling out to nslookup is an incredibly >>> slow and clumsy way of doing name translation. What you really want to >>> be doing is calling getaddrinfo() directly. >>> >>> See http://docs.python.org/2/library/socket.html#socket.getaddrinfo for >>> details. >>> -- >> Because, unless I'm badly mistaken (very possible), getaddrinfo doesn't let >> me specify the server from which the name is returned. I'm really not after >> the name, what I'm REALLY after is the fact that a path exists to the name >> server I specify (and how long it takes to respond). In the "good old days" >> I >> would just have ping'd it, but these days more and more DNS boxes (and >> servers of all sorts) are shutting off their ping response. >> >> Thanks, Bill > > Oh, my. You're using DNS as a replacement for ping? Fair enough. In > that case, all you really care about is that you can connect to port 53 > on the server... > > import socket > import time > s = socket.socket() > t0 = time.time() > s.connect(('8.8.8.8', 53)) > t1 = time.time() > print "it took %f seconds to connect" % (t1 - t0) > -- > http://mail.python.org/mailman/listinfo/python-list Now THAT looks better. Simpler, cleaner, (longer, taller, stronger, faster, cheaper… :-) Thanks, Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Script for Colorizing Traceroute Output
Don't forget that most firewalls don't decrement) the time-to-live number, and unless you REALLY know what to look for, are invisible. -Bill On Nov 17, 2012, at 10:04 AM, Jordan Bylsma wrote: > I'm looking into writing a python script that colorizes particular hops when > using traceroute. Anyone run across something like this? I don't think it > would be extremely difficult to write but some example code would help. > > Basically particular hops in traceroute output would match a table as either > a router, firewall or layer 3 switch and be colorized accordingly. > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Script for Colorizing Traceroute Output (apologies for top-post)
On Nov 17, 2012, at 10:04 AM, Jordan Bylsma wrote: > I'm looking into writing a python script that colorizes particular hops when > using traceroute. Anyone run across something like this? I don't think it > would be extremely difficult to write but some example code would help. > > Basically particular hops in traceroute output would match a table as either > a router, firewall or layer 3 switch and be colorized accordingly. > -- > http://mail.python.org/mailman/listinfo/python-list Don't forget that most firewalls don't decrement) the time-to-live number, and unless you REALLY know what to look for, are invisible. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Puzzling error msg.
So far in my experience with Python, it's error messages have been clear, concise, and quite good at fingering my errors. However, the message below has me stumped. The routine in question has been running for weeks with no problems, then yesterday I got the following: Traceback (most recent call last): File "./Connection_Monitor.py", line 146, in Google_up, Google_summary, Google_RTT, Google_stddev = Google.connection_test() File "/Users/wrw/Dev/Python/Connection_Monitor/Version2.2/WorkingCopy/network.py", line 101, in connection_test # IndexError: list index out of range The routine is pasted in below: def connection_test(self): self.network_up = True self.error = None ping_result = subprocess.Popen(['ping', '-qc6', self.target_IP], stderr = subprocess.PIPE, stdout = subprocess.PIPE).communicate()[0] found_0 = '0 packets received' in ping_result found_1 = '1 packets received' in ping_result if found_0 == True or found_1 == True: self.network_up = False self.ping_summary = 'No route to host' self.ping_RTT = 'NA' self.ping_stddev = 'NA' return self.network_up, self.ping_summary, self.ping_RTT, self.ping_stddev # That particular command line generates 6 ping packets in quiet mode (summary only) and the amount of text returned, even when the ping fails is minimal. My puzzle two-fold. First: how could that code generate an "index our of range" error, and second: line 101 (the one fingered by the error message) is the line following the return statement, the one that contains the # character. I've seen that sort of line slippage when I forgot a ":", but that doesn't seem to be the case here. Python 2.7.3 from Python.org, running on Mac OS-X 10.8.2. For what it is worth, the definitions of the rest of the class variables follow (pretty simple minded): def __init__(self, target_name): lan_status = '' wan_status = '' path_status = '' ping_summary = '' ping_RTT = '' ping_stddev = '' target_error = '' network_up = True target_error, initial_route, hop_count, target_IP = find_initial_route(target_name) self.target_error = target_error self.initial_route = initial_route self.hop_count = hop_count self.gateway = initial_route[0] self.target_name = target_name self.target_IP = target_IP self.hop_count = hop_count self.lan_status = lan_status self.wan_status = wan_status self.path_status = path_status self.network_up = network_up self.ping_summary = ping_summary self.ping_RTT = ping_RTT self.ping_stddev = ping_stddev -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzling error msg.
On Dec 3, 2012, at 1:12 PM, Steven D'Aprano wrote: > On Mon, 03 Dec 2012 12:37:42 -0500, wrw wrote: > >> So far in my experience with Python, it's error messages have been >> clear, concise, and quite good at fingering my errors. However, the >> message below has me stumped. The routine in question has been running >> for weeks with no problems, then yesterday I got the following: >> >> Traceback (most recent call last): >> File "./Connection_Monitor.py", line 146, in >>Google_up, Google_summary, Google_RTT, Google_stddev = > Google.connection_test() >> File "/Users/wrw/Dev/Python/Connection_Monitor/Version2.2/WorkingCopy/ > network.py", >> line 101, in connection_test >># >> IndexError: list index out of range > > Are you running Python with the -x option? If so, then I understand that > the line number (and subsequent line of code) reported in tracebacks may > sometimes be off by one. > Steven, thanks for looking at this. No, I'm not using -x and the .py and .pyc files are as they should be. (Notice in the traceback that the files were in the "Version2.2/WorkingCopy/" directory. I'm pretty careful about version control.) I've added a bunch of print statements and I'll just have to wait until it fails again - hopefully soon. > > > By the way, in connection_test you have the following: > >>def connection_test(self): >>found_0 = '0 packets received' in ping_result >>found_1 = '1 packets received' in ping_result >>if found_0 == True or found_1 == True: > [...] > > Of course that's not correct. You should write: > > [byte] > Of course the whole thing is silly. The right way to test booleans for > their boolean value is just: > > if found_0 or found_1: > > "flag == True" is the same as "flag". > > OK - point taken wrt testing booleans. > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Puzzling error msg.
On Dec 3, 2012, at 1:27 PM, Ian Kelly wrote: > On Mon, Dec 3, 2012 at 10:37 AM, wrote: > if found_0 == True or found_1 == True: > > Not related to your problem, but this line would be more pythonic as: > > if found_0 or found_1: > Thanks Ian - yes, Steven pointed out the same thing. Point well taken. > My puzzle two-fold. First: how could that code generate an "index our of > range" error, and second: line 101 (the one fingered by the error message) is > the line following the return statement, the one that contains the # > character. I've seen that sort of line slippage when I forgot a ":", but > that doesn't seem to be the case here. > > It may indicate a discrepancy between the source and the code that is > actually running. Python doesn't keep the source in memory; when a traceback > needs to be generated it opens the relevant files and reads the designated > lines at run-time. If that source is incorrect, then you get inaccurate > tracebacks. This could happen in a couple of ways. > > 1) Your .pyc or .pyo files are out-of-date, and Python doesn't realize it due > to incorrect file modification times. Try deleting the cached bytecode files > and recompiling and see if your problem goes away (or at least gives you a > better stack trace). > > 2) It sounds like this is a long-running process, so perhaps the source code > has been changed at some point since the process started. In that case, > merely restarting the process should be sufficient to fix the stack trace. > It is a long-running process, and because of exactly that point I'm pretty careful about source code management. You will notice that the original traceback contained the code link: "Version2.2/WorkingCopy/network.py". In other words, I'm pretty careful about segregating my development copies from the code I leave running. > As for the actual error, assuming that the method's source accurately > reflects what was running, the only code I see there that I think could > generate the error is the ".communicate()[0]" bit. As far as I know, > Popen.communicate should always return a 2-tuple, but perhaps you've somehow > run into a case where it returned an empty tuple instead. If you can > reproduce the error, you might try logging the result of the .communicate() > call to see what is actually returned when the error occurs. I was kind of afraid it might be something like that. I've added some print statements and I'll just have to wait for it to fail again (hopefully soon). Thanks again, Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] problem with usbtmc-communication
On Dec 4, 2012, at 7:14 AM, Jean Dubois wrote:
> The following test program which tries to communicate with a Keithley
> 2200 programmable power supply using usbtmc in Python does not work as
> expected. I have connected a 10 ohm resistor to its terminals and I
> apply 0.025A, 0.050A, 0.075A en 0.1A,
> I then measure the current and the voltage en write them in a file
> De data produced looks like this:
> 0.00544643 0.254061; first current value is wrong, voltage value is
> correct
> 0.0250807 0.509289; second current value is wrong, but it corresponds
> to the first, second voltage is correct
> 0.0501099 0.763945; 3rd current value is wrong, but it corresponds to
> the second, 3rd voltage is right
> 0.075099 1.01792; 4th current value is wrong, it corresponds to the
> 3rd, 4th voltage is right
>4th correct current value is missing
>
> But is should be (numerical inaccuracy taking into account)(these data
> were produced by a similar octave-program):
> 0.0248947 0.254047
> 0.0499105 0.509258
> 0.0749044 0.764001
> 0.0998926 1.01828
>
> Here is the python-program:
> #!/usr/bin/python
> import time
> import os
> import sys
> measurementcurr=''
> measurementvolt=''
> timesleepdefault=1
> filename ='mydata.txt'
> usbkeith = open('/dev/usbtmc1','r+')
> usbkeith.flush()
> usbkeith.write("*IDN?\n")
> #strip blank line:
> identification=usbkeith.readline().strip()
> print 'Found device: ',identification
> usbkeith.write("SYST:REM" + "\n")
> usbkeith.write(":SENS:VOLT:PROT 1.5\n")
> keithdata = open(filename,'w')
> #start first measurement
> usbkeith.write(":SOUR:CURR 0.025\n")
> usbkeith.write(":OUTP:STAT ON\n")
> time.sleep(timesleepdefault)
> usbkeith.write(":MEAS:CURR?\n")
> time.sleep(timesleepdefault)
> measurementcurr=usbkeith.readline()
> print 'Measured current 1: ',measurementcurr
> usbkeith.write("MEAS:VOLT?\n")
> time.sleep(timesleepdefault)
> measurementvolt=usbkeith.readline()
> print 'Measured voltage 1: ',measurementvolt
> keithdata.write(measurementcurr.strip()+' '+measurementvolt)
> #start second measurement
> usbkeith.write("SOUR:CURR 0.050\n")
> time.sleep(timesleepdefault)
> usbkeith.write("MEAS:CURR?\n")
> time.sleep(timesleepdefault)
> measurementcurr=usbkeith.readline()
> print 'Measured current 2: ',measurementcurr
> usbkeith.write("MEAS:VOLT?\n")
> time.sleep(timesleepdefault)
> measurementvolt=usbkeith.readline()
> print 'Measured voltage 2: ',measurementvolt
> keithdata.write(measurementcurr.strip()+' '+measurementvolt)
> #start 3rd measurement
> time.sleep(timesleepdefault)
> usbkeith.write("SOUR:CURR 0.075\n")
> time.sleep(timesleepdefault)
> usbkeith.write("MEAS:CURR?\n")
> time.sleep(timesleepdefault)
> measurementcurr=usbkeith.readline()
> print 'Measured current 3: ',measurementcurr
> usbkeith.write("MEAS:VOLT?\n")
> time.sleep(timesleepdefault)
> measurementvolt=usbkeith.readline()
> print 'Measured voltage 3: ',measurementvolt
> keithdata.write(measurementcurr.strip()+' '+measurementvolt)
> #start 4th measurement
> time.sleep(timesleepdefault)
> usbkeith.write("SOUR:CURR 0.1\n")
> time.sleep(timesleepdefault)
> usbkeith.write("MEAS:CURR?\n")
> time.sleep(timesleepdefault)
> measurementcurr=usbkeith.readline()
> print 'Measured current 4: ',measurementcurr
> usbkeith.write("MEAS:VOLT?\n")
> time.sleep(timesleepdefault)
> measurementvolt=usbkeith.readline()
> print 'Measured voltage 4: ',measurementvolt
> keithdata.write(measurementcurr.strip()+' '+measurementvolt)
> usbkeith.write(":OUTP:STAT OFF\n")
> print "Goodbye, data logged in file:"
> print filename
> usbkeith.close()
> keithdata.close()
>
> can anyone here what is going wrong and how to get it right?
>
> thanks
> jean
> --
> http://mail.python.org/mailman/listinfo/python-list
Just guessing here - it looks as though you are setting the current and THEN
turning the output on. That might be the correct sequence or it might not. If
not, it would explain the offset between that and the subsequent readings.
This is really a Keithley problem, not a Python problem.
-Bill
--
http://mail.python.org/mailman/listinfo/python-list
Re: problem with usbtmc-communication
On Dec 4, 2012, at 11:12 AM, Jean Dubois wrote: > On 4 dec, 15:33, [email protected] wrote: >> On Dec 4, 2012, at 7:14 AM, Jean Dubois wrote: >> >> >> >>> The following test program which tries to communicate with a Keithley >>> 2200 programmable power supply using usbtmc in Python does not work as Is usbtmc a software layer (library of some sort) or some sort of hardware adapter? >>> expected. I have connected a 10 ohm resistor to its terminals and I >>> apply 0.025A, 0.050A, 0.075A en 0.1A, >>> I then measure the current and the voltage en write them in a file >>> De data produced looks like this: >>> 0.00544643 0.254061; first current value is wrong, voltage value is >>> correct >>> 0.0250807 0.509289; second current value is wrong, but it corresponds >>> to the first, second voltage is correct >>> 0.0501099 0.763945; 3rd current value is wrong, but it corresponds to >>> the second, 3rd voltage is right >>> 0.075099 1.01792; 4th current value is wrong, it corresponds to the >>> 3rd, 4th voltage is right >>>4th correct current value is missing >> >>> But is should be (numerical inaccuracy taking into account)(these data >>> were produced by a similar octave-program): >>> 0.0248947 0.254047 >>> 0.0499105 0.509258 >>> 0.0749044 0.764001 >>> 0.0998926 1.01828 >> >>> Here is the python-program: >>> #!/usr/bin/python >>> import time >>> import os >>> import sys >>> measurementcurr='' >>> measurementvolt='' >>> timesleepdefault=1 >>> filename ='mydata.txt' >>> usbkeith = open('/dev/usbtmc1','r+') >>> usbkeith.flush() >>> usbkeith.write("*IDN?\n") >>> #strip blank line: >>> identification=usbkeith.readline().strip() >>> print 'Found device: ',identification >>> usbkeith.write("SYST:REM" + "\n") >>> usbkeith.write(":SENS:VOLT:PROT 1.5\n") >>> keithdata = open(filename,'w') >>> #start first measurement >>> usbkeith.write(":SOUR:CURR 0.025\n") >>> usbkeith.write(":OUTP:STAT ON\n") >>> time.sleep(timesleepdefault) >>> usbkeith.write(":MEAS:CURR?\n") >>> time.sleep(timesleepdefault) >>> measurementcurr=usbkeith.readline() >>> print 'Measured current 1: ',measurementcurr >>> usbkeith.write("MEAS:VOLT?\n") >>> time.sleep(timesleepdefault) >>> measurementvolt=usbkeith.readline() Without knowing anything about the usbtmc hardware/software it is hard to make real recommendations, but it seems pretty clear that you are being stepped on by a buffer problem of some sort. I'm VERY suspicious of using of readline() as a way of getting the data out of the usbtmc thingy. That makes python treat the Keithley as a file-like object and there are way too many ways the file pointer may not be where you think it is. I note that in your Octave example you are reading characters rather than lines. It seems to me that you have two choices here, either do the equivalent in python or dig through the Keithley documentation to find the hex codes that usbtmc is presumably translating your commands into. If you can find those, and if you are interested, I can send you off-line the handler I wrote a couple of years ago that used a dictionary to translate English commands into hex, then assembled those with a checksum and sent the string out to a Keyspan usb to serial converter. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with usbtmc-communication
On Dec 5, 2012, at 3:38 PM, Jean Dubois wrote:
[byte]
>>
>> I note that in your Octave example you are reading characters rather than
>> lines. It seems to me that you have two choices here, either do the
>> equivalent in python or dig through the Keithley documentation to find the
>> hex codes that usbtmc is presumably translating your commands into. If you
>> can find those, and if you are interested, I can send you off-line the
>> handler I wrote a couple of years ago that used a dictionary to translate
>> English commands into hex, then assembled those with a checksum and sent the
>> string out to a Keyspan usb to serial converter.
>
> If you could show me how to "do the equivalent in Python" I'd
> appreciate that very much
>
> best regards,
> jean
> --
> http://mail.python.org/mailman/listinfo/python-list
OK - I've excerpted some of the relevant code (the original was much longer and
included a lot of error checking). Please understand that the comments were
for my own use, this was never intended to see the light of day (as it were).
Also, the structure grew from a situation where I only had to worry about a
single controller model - single relay model to one where I had to be able to
deal with two controllers and two relay models. This was all python 2.7 of
course.
cut on dotted line..
"""
serial_port = /dev/tty.KeySerial1, 2, 3, etc.
X10_controller = 1132B or TI103
Relay_model = UM506 or RBn04
Relay_address = B2
"""
import serial, string
def checksum256(st):
temp = reduce(lambda x,y:x+y, map(ord,st)) % 256
if temp < 9:
hex_temp = '0'+str(temp)
return hex_temp
hex_temp = hex(temp).upper()[2:]
return hex_temp
letr_address_dict = {'A':'\x46', 'B':'\x4E', 'C':'\x42', 'D':'\x4A',
'E':'\x41', 'F':'\x49', 'G':'\x45', 'H':'\x4D', 'I':'\x47', 'J':'\x4F',
'K':'\x43', 'L':'\x4B', 'M':'\x40', 'N':'\x48', 'O':'\x44', 'P':'\x4C' }
numb_address_dict = {'1':'\x4C', '2':'\x5C', '3':'\x44', '4':'\x54',
'5':'\x42', '6':'\x52', '7':'\x4A', '8':'\x5A', '9':'\x4E', '10':'\x5E',
'11':'\x46', '12':'\x56', '13':'\x40', '14':'\x50', '15':'\x48', '16':'\x58' }
cmd_dict = {'SoC':'\x63', 'All_Units_Off':'\x41',
'All_Lights_On':'\x43', 'ON':'\x45', 'OFF':'\x47', 'Dim':'\x49',
'Bright':'\x4B', 'All_Lights_Off':'\x4D', 'Rep_Cnt1':'\x41', 'Rep_Cnt2':'\x42'}
def relay(port, controller_model, relay_model, relay_address, command):
if controller_model == '1132B':
if relay_model == 'UM506' or relay_model == 'UM7206':
letr = letr_address_dict[relay_address[0]]
numb = numb_address_dict[relay_address[1]]
cmd = cmd_dict[command]
cmd_string = '\x63'+letr+numb+cmd+'\x42' # Start-of-Command +
address_letter + address_number + command + Rep-count
ser = serial.Serial(port, 9600, timeout=1) # Set up handle to
serial port
stat1 = ser.write('\x02')# Write attention to
PowerLink, stat = number of bytes written, not really an error return.
ack1 = ser.read(2) # Check to see if
PowerLink is ready
if ack1 == '\x06\r': # It returns ACK
(\x06\r) if it is
stat2 = ser.write(cmd_string)
ack2 = ser.read(19)
if command == 'ON' and ack2 == 'XN\\1\rXNE1\rXNE1\r' : status = 0
if command == 'OFF' and ack2 == 'XN\\1\rXNG1\rXNG1\r': status = 0
if command == 'ON' and ack2 != 'XN\\1\rXNE1\rXNE1\r' : status =
1
if command == 'OFF' and ack2 != 'XN\\1\rXNG1\rXNG1\r': status =
1
elif ack1 =='\x15': # PowerLink sends NAC
(hex 15) if it isn't.
print('Received NAK from X10 Control, is there too much X10
traffic on the line?\n')
else: print("Something's wrong with X10 control. Ack returned
was: " + ack1 + "\n")
stat3 = ser.close() # Close serial port
return(status)
-
some irrelevant stuff was here, snipped
-
elif controller_model == 'TI103':
if relay_model == 'UM506' or relay_model == 'UM7206':
letr = relay_address[0]
numb = relay_address[1]
if int(relay_address[1]) <= 9: numb = '0'+numb
# stat1 = ser.write('$>28001B02B02 BONBONCC#') # Tell TI103 to send
"On" to device B2
ser = serial.Serial(port, 9600, timeout=0.1) # Set up handle to
serial port
cmd_string = '$>28001'+letr+numb+letr+numb+'
'+letr+command+letr+command
ck_sum = checksum256(cmd_string)
cmd_string = cmd_string+ck_sum+'#'
stat2 = ser.write(cmd_string)
ack2 = ser.read(10)
if ack2 != '$<2800!4B#': print('Problem writing command string,
controller ACK =', ack2) # $<2800!4B# == success
Re: problem with usbtmc-communication
On Dec 6, 2012, at 8:50 AM, Jean Dubois wrote: [byte] > > It seems there is some misunderstanding here. What I meant with how > to "do the equivalent in Python" refered to "reading characters > rather than lines". > I have written working code myself for another Keithleu which does use > RS232 for communication. The problem now is specifically for the new > Keithley which doesn't allow RS232 but only USB-communication over > usbtmc. So if the "buffer-problem" could be changed by reading > characters that would be great. > > regards, > Jean > > > -- > http://mail.python.org/mailman/listinfo/python-list Sorry about the misunderstanding (and subsequent waste of bandwidth). However, if you will look at the serial reads and writes in that handler, you will see that it does things like "serial.read(n)" where "n" is an explicit number, the number of bytes to be read from the serial buffer. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with usbtmc-communication
On Dec 6, 2012, at 2:41 PM, Jean Dubois wrote: > On 6 dec, 15:50, [email protected] wrote: >> On Dec 6, 2012, at 8:50 AM, Jean Dubois wrote: >> >> [byte] >> >> >>> It seems there is some misunderstanding here. What I meant with how >>> to "do the equivalent in Python" refered to "reading characters >>> rather than lines". >>> I have written working code myself for another Keithleu which does use >>> RS232 for communication. The problem now is specifically for the new >>> Keithley which doesn't allow RS232 but only USB-communication over >>> usbtmc. So if the "buffer-problem" could be changed by reading >>> characters that would be great. >> >>> regards, >>> Jean >> >>> -- >>> http://mail.python.org/mailman/listinfo/python-list >> >> Sorry about the misunderstanding (and subsequent waste of bandwidth). >> However, if you will look at the serial reads and writes in that handler, >> you will see that it does things like "serial.read(n)" where "n" is an >> explicit number, the number of bytes to be read from the serial buffer. >> >> -Bill > I tried changing measurementcurr=usbkeith.readline() to > measurementcurr=usbkeith.read(1) > but this leads to trouble with the usbtmc-thing: > > Measured current 1: > Traceback (most recent call last): > File "./keith2200rev2.py", line 26, in >measurementvolt=usbkeith.read(1) > IOError: [Errno 110] Connection timed out > > and hereafter I need to restart the Keithley...:-( > > regards, > Jean > -- > http://mail.python.org/mailman/listinfo/python-list Several comments: 1) I can't be sure, but that would seem to be asking the Keithley to be providing 10,000 readings. I don't know about the GPIB bus (which this USBTMC library seems to be trying to emulate), but most serial devices expect to provide one answer per read-write handshake. That is, you send one read command and get one answer back. That answer may contain several bytes, but I'd be surprised it it contained 10,000. The typical cycle is something like send-an-initialize, read-status, send-mode-set-up, read-status, send trigger command, read-answer… lather and repeat. (Or some logical equivalent of all that). On the assumption that the USBTMC API handles most of that, I'd try usbkeith.read(n) where "n" is the number of decimal digits you expect to get back plus sign. - 2) I took a quick look at the Keithley and National Instruments web sites (where the documentation is at best, VERY poorly indexed and hard to search for). USBTMC *appears* to be a software layer designed to allow newer Tektronix and Keithley instruments to be driven using older software that drove GPIB equipment. To make matters worse, if I'm reading it right (I didn't study in detail) it appears to ALSO be providing a GPIB-like API to Windows versions of National Instruments LabView. 3) If I understand what you are trying to do, you want to go straight from python to the Keithley USB port, without detouring (USB-to-GPIB and GPIB back to USB). 4) I did find (but did not try to read in detail) the following link: http://www.ni.com/white-paper/4478/en which documents direct USB control of instruments. The python serial library provides quite transparent control of reading and writing to the USB interface. Maybe following this link will get you going. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: How to list a file which already created a 2 mins ago
On Dec 6, 2012, at 4:29 PM, Irmen de Jong wrote: > On 6-12-2012 17:49, moonhkt wrote: >> Hi All >> >> AIX.5.3 >> Python 2.6.2 >> >> File ftp to Machine A, need to rename then send to Machine B. >> >> How to list a file which already created a 2 mins ago ? If file aging >> more than 2 mins. I want to rename file to other file name. >> >> moonhkt >> > > ftplib.FTP > os.path.getmtime > os.rename > time.time > > Should be some pointers to get started. > > > Irmen > > -- > http://mail.python.org/mailman/listinfo/python-list The answer will depend on whether or not the AIX "ls" command includes a switch to list the file creation time. Some versions of UNIX (including OS X) have this, others don't. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with usbtmc-communication
On Dec 10, 2012, at 8:31 AM, Jean Dubois wrote:
[byte]
> As you can see this approach suffers from the same "buffer problem" as
> the approach with readline did. One now good argue as a workaround:
> get rid of the first data pair and add an extra measure command for
> the missing data pair, however this still does not explain why this
> problem is there in Python and not in Octave and I also fear I'll get
> more trouble when sending combined commands e.g. such as that to
> create a staircase current
> So my question is, how to modify the Python-code such that the first
> data pair is indeed the first data pair
>
> thanks,
> jean
>
> Here follows the new code:
> #!/usr/bin/python
> import time
> import os
> import sys
> measurementcurr=''
> measurementvolt=''
> timesleepdefault=5
> print "Enter a numofchar (11 = numofchar = int(raw_input())
> filename ='mydata.txt'
> usbkeith = open('/dev/usbtmc1','r+')
> usbkeith.flush()
> usbkeith.write("*IDN?\n")
It seems like a real leap of faith to be opening /dev/usbtmc1 as though it were
a file-oriented device. I've never heard of ANY instrument interface
implemented this way.
Where did you see example code that did that. Have you tried to access
/dev/usbtmc1 as though it were a serial device?
> #strip blank line:
> identification=usbkeith.readline().strip()
> print 'Found device: ',identification
> usbkeith.write("SYST:REM" + "\n")
> usbkeith.write(":SENS:VOLT:PROT 1.5\n")
> keithdata = open(filename,'w')
> usbkeith.write(":OUTP:STAT ON\n")
> for number, current_in in enumerate(('0.025', '0.050', '0.075',
> '0.100'), 1):
> usbkeith.write(":SOUR:CURR %s\n" % current_in)
> time.sleep(timesleepdefault)
> usbkeith.write(":MEAS:CURR?\n")
> measurementcurr=usbkeith.read(numofchar)
> print 'Measured current %d: ' % number, measurementcurr
> usbkeith.write(":MEAS:VOLT?\n")
> measurementvolt=usbkeith.read(numofchar)
> print 'Measured voltage %d: ' % number, measurementvolt
> keithdata.write(measurementcurr.strip()+' '+measurementvolt)
> usbkeith.write(":OUTP:STAT OFF\n")
> print "Goodbye, data logged in file:"
> print filename
> usbkeith.close()
> keithdata.close()
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: problem with usbtmc-communication
On Dec 11, 2012, at 1:58 AM, Jean Dubois wrote: > On 10 dec, 16:34, [email protected] wrote: >> On Dec 10, 2012, at 8:31 AM, Jean Dubois wrote: >> >> [byte] >>> As you can see this approach suffers from the same "buffer problem" as >>> the approach with readline did. One now good argue as a workaround: >>> get rid of the first data pair and add an extra measure command for >>> the missing data pair, however this still does not explain why this >>> problem is there in Python and not in Octave and I also fear I'll get >>> more trouble when sending combined commands e.g. such as that to >>> create a staircase current >>> So my question is, how to modify the Python-code such that the first >>> data pair is indeed the first data pair >> >>> thanks, >>> jean >> >>> Here follows the new code: >>> #!/usr/bin/python >>> import time >>> import os >>> import sys >>> measurementcurr='' >>> measurementvolt='' >>> timesleepdefault=5 >>> print "Enter a numofchar (11 =>> numofchar = int(raw_input()) >>> filename ='mydata.txt' >>> usbkeith = open('/dev/usbtmc1','r+') >>> usbkeith.flush() >>> usbkeith.write("*IDN?\n") >> >> It seems like a real leap of faith to be opening /dev/usbtmc1 as though it >> were a file-oriented device. I've never heard of ANY instrument interface >> implemented this way. >> Where did you see example code that did that. > I found examples in the usbtmc kernel driver documentation (the > examples there are given in C): > http://www.home.agilent.com/upload/cmc_upload/All/usbtmc.htm?&cc=BE&lc=dut > OK - I see where the examples came from, and I notice - int my_inst; my_inst=open(“/dev/usbtmc1”,O_RDWR); write(my_inst,”*RST\n”,5); close(my_inst); and similarly in another place - retval=write(myfile,"*IDN?\n",6); Note that both write commands contain a byte count of the number of characters to be written (\n counts as one character). Again, the read commands contain byte counts. I'm very suspicious that a write command with no byte count writes nothing, but does move a buffer pointer. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with usbtmc-communication
On Dec 11, 2012, at 3:48 PM, Jean Dubois wrote:
[byte]
>>
>> OK - I see where the examples came from, and I notice -
>>
>> int my_inst;
>> my_inst=open(“/dev/usbtmc1”,O_RDWR);
>> write(my_inst,”*RST\n”,5);
>> close(my_inst);
>>
>> and similarly in another place -
>>
>> retval=write(myfile,"*IDN?\n",6);
>>
>> Note that both write commands contain a byte count of the number of
>> characters to be written (\n counts as one character).
>> Again, the read commands contain byte counts. I'm very suspicious that a
>> write command with no byte count writes nothing, but does move a buffer
>> pointer.
>>
>> -Bill
>
> Does Python support/implement simular commands? Can I use
> usbkeith.write("*IDN?\n",6) and something simular for the reading
> commands?
>
> thanks,
> jean
> --
> http://mail.python.org/mailman/listinfo/python-list
Yes of course. BUT, that isn't really a python question, it depends on how the
device driver implements the function call.
-Bill
--
http://mail.python.org/mailman/listinfo/python-list
Re: Noob: Trying to run two python scrips on a pfsense/freeBSD for the OWL-Intuition-LC
On Jan 1, 2013, at 9:42 PM, [email protected] wrote: > Hi, > > I wrote couple of scrips to work with OWL-intution-LC home/office electricity > monitor. The concept of the first scrip (owl.py) to capture network multicast > from the OWL gateway and write to a .csv file has been taken from a > raspberrypi forum and further developed upon to work with sqlite. The second > scrip (responder.py)keeps checking a mail account for any email queries > received and responds with a detailed electricity report to the sender. > > I've been using owl.py since some days & works fine on the pfsense/freebsd, > it has been set to start on boot using shellcmd. The second scrip also works > when I execute manually from the shell, but it does not seems to start upon > boot how I did for owl.py. I cannot find anything in /var/log/system.log > about execution or failure of either scrips. > > This question may not exactly relate with python but any help would be > appreciated. > > Another Q I wanted to ask or rather confirm, I think python does not log > anything from scrip runtime/termination and that there is a log library that > needs to be used. I find using the log library adding bulk to the code and > for every line I suspect of failure in the code I would need to put in an > exception to create log ? Is there a better way of logging where it just logs > the reason on scrip termination ? I just want to log the msg it shows when > manually run in a shell. - Thanks. > -- > http://mail.python.org/mailman/listinfo/python-list Can't help with the mail script's failure to launch (although it may be because something in the script requires an environmental variable that hasn't been created when running in batch). But I can make a suggestion for logging. Operating systems have subtle differences, so this may not be a solution for you, but at least on OS-X (which at its heart is an amalgam of freebsd and netbsd), any print statement goes to the system log if the program is being run from batch rather than from an interactive terminal window. Thus, simple print statements scattered through the code should allow you to monitor the execution under normal circumstances. Of course, any abnormal termination will result in error messages in the same system log. -Bill -- http://mail.python.org/mailman/listinfo/python-list
Re: pyrudp
On Jan 30, 2013, at 7:14 PM, Chris Angelico wrote: > On Thu, Jan 31, 2013 at 11:04 AM, Jorge Alberto Diaz Orozco > wrote: >> I have restrictions in my system that does not allow me to use TCP, so I >> want to make a pipe over UDP imitating TCP behavior. >> I have control over both endpoints, and I´m writing both of them. >> I just don´t want to re-invent the wheel and I´m looking for a reliable UDP >> sockets implementation for Python so I can start from there. > > Then... I think the place to start is here: > > http://www.ietf.org/rfc/rfc793.txt > > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list I think you really ought to think about this long and hard. Although TCP started as a fairly simple-minded protocol designed to guarantee reliable delivery of packets in the order in which they were transmitted, it has evolved considerably over the years. It now incorporates concepts of "fairness" and a very sophisticated rate control system that is constantly probing available network bandwidth to be sure it isn't over driving or hogging the network connection. It would be easy to say: "I really don't need all that - all I'm doing is X." - but in reality you do, and getting reliable delivery over UDP really does require it all. Now, the good news is that because UDP-based protocols all run in user memory space (as opposed to TCP that runs privileged in kernel space) it is relatively straightforward for non-privledged users to write and test UDP transport schemes and this has become a fairly standard CS exercise at the graduate level. If I were in your shoes, I'd start Googling for the papers published on protocols like HURRICANE, ATAU, or even just the general subject of UDP transport protocols. Two places you might start are: http://www.ogf.org/documents/GFD.55.pdf and http://www.ornl.gov/~webworks/cppr/y2001/rpt/121150.pdf Most, if not all of these UDP schemes are in the public domain, have been written in high-level languages, and could be translated into python. -Bill -- http://mail.python.org/mailman/listinfo/python-list
