By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,400 Members | 903 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,400 IT Pros & Developers. It's quick & easy.

is there a problem on this simple code

P: n/a
basically what the code does is transmit data to a hardware and then
receive data that the hardware will transmit.

import serial
import string
import time
from struct import *
ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser
ser.close()
ser.open()

command = 67
message_no = 1
total_data = 2

item = 12000 #to warm-up the hardware
hexed = hex(item)
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum)) #serial transmit protocol
time.sleep(1)

item = 10000
no = 0
for item in range(10000, 30001, 250):
no = no +1
hexed = hex(item)
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))
data = ser.read(10)
(command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum) = unpack('10B', data) #serial receive
protocol
print no, command, msg_no, no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, checksum
time.sleep(1)

ser.close()
===========================
and here is some result after running the program on Idle Python 2.3
(enthought ed.)

1 70 168 6 0 0 0 0 0 0 12
2 70 2 6 0 0 0 0 0 0 178
3 70 3 6 0 0 0 0 0 0 177
4 70 4 6 0 0 0 0 0 0 176
5 70 5 6 0 0 0 0 0 0 175
6 70 6 6 0 0 0 0 0 0 174
7 70 7 6 0 0 0 0 0 0 173
8 70 8 6 0 0 0 0 0 0 172
9 70 9 6 0 0 0 0 0 0 171
10 70 10 6 0 0 0 0 0 0 170
11 70 11 6 0 0 0 0 0 0 169
12 70 12 6 0 0 0 0 0 0 168
13 70 13 6 0 0 0 0 0 0 167
14 70 14 6 0 0 0 0 0 0 166
15 70 15 6 0 0 0 0 0 0 165

==========================

the result i am expecting is for the data bytes (bytes 4-9) to change
its value since i am able to control the sensors which the data were
based. i am just asking for your opinion if there is something wrong
with this program, otherwise, it could be a hardware problem.

thanks in advance.
Jul 18 '05 #1
Share this Question
Share on Google+
38 Replies


P: n/a
hah, this code is anything but simple...

Jul 18 '05 #2

P: n/a
@sir harlin
so you are saying that there is nothing wrong in this simple program.
On 12 Mar 2005 07:39:31 -0800, Harlin Seritt <ha**********@yahoo.com> wrote:
hah, this code is anything but simple...

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #3

P: n/a

jrlen balane wrote:
basically what the code does is transmit data to a hardware and then
receive data that the hardware will transmit.

import serial
import string
import time
from struct import *
ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser
ser.close()
ser.open()

command = 67
message_no = 1
total_data = 2

item = 12000 #to warm-up the hardware
hexed = hex(item)
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum)) #serial transmit protocol
time.sleep(1)

item = 10000
no = 0
for item in range(10000, 30001, 250):
no = no +1
hexed = hex(item)
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))
What actually gets transmitted is "C\x01\x02\x10'\x83".
That's 18 bytes. Is the command supposed to be the ASCII
characters \x01 or a single byte whose value is 1?

data = ser.read(10)
(command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum) = unpack('10B', data) #serial receive
protocol
print no, command, msg_no, no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, checksum
time.sleep(1)

ser.close()
===========================
and here is some result after running the program on Idle Python 2.3
(enthought ed.)

1 70 168 6 0 0 0 0 0 0 12
2 70 2 6 0 0 0 0 0 0 178
3 70 3 6 0 0 0 0 0 0 177
4 70 4 6 0 0 0 0 0 0 176
5 70 5 6 0 0 0 0 0 0 175
6 70 6 6 0 0 0 0 0 0 174
7 70 7 6 0 0 0 0 0 0 173
8 70 8 6 0 0 0 0 0 0 172
9 70 9 6 0 0 0 0 0 0 171
10 70 10 6 0 0 0 0 0 0 170
11 70 11 6 0 0 0 0 0 0 169
12 70 12 6 0 0 0 0 0 0 168
13 70 13 6 0 0 0 0 0 0 167
14 70 14 6 0 0 0 0 0 0 166
15 70 15 6 0 0 0 0 0 0 165

==========================

the result i am expecting is for the data bytes (bytes 4-9) to change
its value since i am able to control the sensors which the data were
based. i am just asking for your opinion if there is something wrong
with this program, otherwise, it could be a hardware problem.

thanks in advance.


Jul 18 '05 #4

P: n/a
jrlen balane *TOP-POSTED*:
On 12 Mar 2005 07:39:31 -0800, Harlin Seritt <ha**********@yahoo.com>

wrote:
hah, this code is anything but simple...

--
http://mail.python.org/mailman/listinfo/python-list

@sir harlin
so you are saying that there is nothing wrong in this simple program.


No, he is saying that it is not simple IHHO. Neither are your
explanations IMHO. What does "(enthought ed.)" mean??

Some observations:

The variable message_no is set to 1 initially, but thereafter is set to
the message_no returned from the hardware -- 168 the first time. This
is at best very confusing. I'd suggest two separate variables,
to_hw_msg_no and from_hw_msg_no. Does the hardware reject a message
with a number that is not ((previous msg no + 1) % 256)?

You have a similar problem with "command"; initially 67 but then is set
to what comes back from the hardware i.e. 70. Again confusing, maybe
wrong, use 2 variables to_hw_command and from_hw_command.

Some suggestions:

(1) read the manual for the hardware interface

(2) look at all the variables you have; what are they for? E.g. "hexed"
is computed but never used. Clean out the irrelevant stuff and it may
become simple enough for delicate folk like Harlin to be able to read
it :-)

(3) are you sure you have the check-sum right? Using a hard-coded 0x46
(= 67 + 1 + 2) is dangerous! Recall command was 67 but then changes to
70! What does the manual say happens if the check-sum fails? It would
be sensible to compute the check-sum from the *ACTUAL* data that is
being sent: check_sum = 256 - (to_hw_command + to_hw_msg_no +
total_data + data_lo + data_hi) & 0xff -- but see next point.

(4) If the program is going to become more complicated, you should get
some structure into it. For example a function
bytes_to_hardware(command, msg_no, list_or_tuple_of_ints) would be a
good idea -- it would compute the data-length and the check_sum and do
the struct.pack(), ONCE.

Then you could have another function (say)
!def item_to_hardware(command, msg_no, item):
! bytes_to_hardware(command, msg_no, divmod(1tem, 256))

(5) Not only are the data values not changing, they appear to be all
zero; what does this mean?

(6) You are not validating the checksum coming back from the hardware;
the values printed out appear to be OK -- that is, they sum to zero
modulo 256; check the manual to see if this is the correct expectation!
-- but the point of having a CHECKsum is that you should CHECK it. It
may not be OK tomorrow.

(7) What does command=70 coming back from the hardware mean? Are there
"commands" that mean (a) invalid command received (b) failure in
message_number protocol (c) check_sum error in received message? If so,
augment your program to check for these. If not, or the h/w doesn't
respond appropriately when you send it a bad message, drop it down the
great white chute in your bathroom :-)

Jul 18 '05 #5

P: n/a

me********@aol.com wrote:

What actually gets transmitted is "C\x01\x02\x10'\x83".
No, that's repr(What actually gets transmitted)
That's 18 bytes. Is the command supposed to be the ASCII
characters \x01 or a single byte whose value is 1?


For a start, according to the OP's code, the command ('C' a.k.a. 67) is
first. The 1 is a meant to be a message number.

Secondly, the hardware smells like it's got an 8080 or 6502 inside. The
likelihood that it groks Python/C string representation is minimal.
Folk just don't send 18 bytes at 9600 bps when 6 bytes will do.

Jul 18 '05 #6

P: n/a
On 12 Mar 2005 17:35:50 -0800, "John Machin" <sj******@lexicon.net> wrote:

me********@aol.com wrote:

What actually gets transmitted is "C\x01\x02\x10'\x83".
No, that's repr(What actually gets transmitted)


If so, that's 6 bytes, not 18:
"C\x01\x02\x10'\x83" "C\x01\x02\x10'\x83" list("C\x01\x02\x10'\x83") ['C', '\x01', '\x02', '\x10', "'", '\x83'] len("C\x01\x02\x10'\x83") 6

OTOH, list(r"C\x01\x02\x10'\x83") ['C', '\\', 'x', '0', '1', '\\', 'x', '0', '2', '\\', 'x', '1', '0', "'", '\\', 'x', '8', '3'] len(r"C\x01\x02\x10'\x83")

18
That's 18 bytes. Is the command supposed to be the ASCII
characters \x01 or a single byte whose value is 1?


For a start, according to the OP's code, the command ('C' a.k.a. 67) is
first. The 1 is a meant to be a message number.

Secondly, the hardware smells like it's got an 8080 or 6502 inside. The
likelihood that it groks Python/C string representation is minimal.
Folk just don't send 18 bytes at 9600 bps when 6 bytes will do.


Regards,
Bengt Richter
Jul 18 '05 #7

P: n/a

Bengt Richter wrote:
On 12 Mar 2005 17:35:50 -0800, "John Machin" <sj******@lexicon.net> wrote:

me********@aol.com wrote:

What actually gets transmitted is "C\x01\x02\x10'\x83".


No, that's repr(What actually gets transmitted)


If so, that's 6 bytes, not 18:
>>> "C\x01\x02\x10'\x83" "C\x01\x02\x10'\x83" >>> list("C\x01\x02\x10'\x83") ['C', '\x01', '\x02', '\x10', "'", '\x83'] >>> len("C\x01\x02\x10'\x83") 6

OTOH, >>> list(r"C\x01\x02\x10'\x83") ['C', '\\', 'x', '0', '1', '\\', 'x', '0', '2', '\\', 'x', '1', '0',

"'", '\\', 'x', '8', '3']
>>> len(r"C\x01\x02\x10'\x83") 18
That's 18 bytes. Is the command supposed to be the ASCII
characters \x01 or a single byte whose value is 1?


For a start, according to the OP's code, the command ('C' a.k.a. 67)

isfirst. The 1 is a meant to be a message number.

Secondly, the hardware smells like it's got an 8080 or 6502 inside. Thelikelihood that it groks Python/C string representation is minimal.
Folk just don't send 18 bytes at 9600 bps when 6 bytes will do.


Regards,
Bengt Richter


The number of bytes transmitted is 6. However the length of the visual
representation of what was sent is 18. Mensator was confused by this,
as was apparent from his/her question "Is the command supposed to be
the ASCII characters \x01 or a single byte whose value is 1?". I tried
to explain this to him/her. However it's not apparent whether your post
is part of the problem or part of the solution. Enlightenment, please.

Jul 18 '05 #8

P: n/a

John Machin wrote:
me********@aol.com wrote:

What actually gets transmitted is "C\x01\x02\x10'\x83".
No, that's repr(What actually gets transmitted)


Drat, I always get burned by that.
That's 18 bytes. Is the command supposed to be the ASCII
characters \x01 or a single byte whose value is 1?
For a start, according to the OP's code, the command ('C' a.k.a. 67)

is first. The 1 is a meant to be a message number.
Yeah, that's what I meant.

Secondly, the hardware smells like it's got an 8080 or 6502 inside. The likelihood that it groks Python/C string representation is minimal.
That's what I was thinking. And maybe the replies he's seeing
from the hardware is an error message because it doesn't
understand what it's seeing (which could be due to other things).
A datascope would come in handy for this situation.
Folk just don't send 18 bytes at 9600 bps when 6 bytes will do.


Jul 18 '05 #9

P: n/a
On 12 Mar 2005 20:12:19 -0800, "John Machin" <sj******@lexicon.net> wrote:

Bengt Richter wrote:
On 12 Mar 2005 17:35:50 -0800, "John Machin" <sj******@lexicon.net>

wrote:
>
>me********@aol.com wrote:
>>
>> What actually gets transmitted is "C\x01\x02\x10'\x83".
>
>No, that's repr(What actually gets transmitted)


If so, that's 6 bytes, not 18:
>>> "C\x01\x02\x10'\x83"

"C\x01\x02\x10'\x83"
>>> list("C\x01\x02\x10'\x83")

['C', '\x01', '\x02', '\x10', "'", '\x83']
>>> len("C\x01\x02\x10'\x83")

6

OTOH,
>>> list(r"C\x01\x02\x10'\x83")

['C', '\\', 'x', '0', '1', '\\', 'x', '0', '2', '\\', 'x', '1', '0',

"'", '\\', 'x', '8', '3']
>>> len(r"C\x01\x02\x10'\x83")

18
>
>> That's 18 bytes. Is the command supposed to be the ASCII
>> characters \x01 or a single byte whose value is 1?
>
>For a start, according to the OP's code, the command ('C' a.k.a. 67)is >first. The 1 is a meant to be a message number.
>
>Secondly, the hardware smells like it's got an 8080 or 6502 inside.The >likelihood that it groks Python/C string representation is minimal.
>Folk just don't send 18 bytes at 9600 bps when 6 bytes will do.
>


Regards,
Bengt Richter


The number of bytes transmitted is 6. However the length of the visual
representation of what was sent is 18. Mensator was confused by this,
as was apparent from his/her question "Is the command supposed to be
the ASCII characters \x01 or a single byte whose value is 1?". I tried
to explain this to him/her. However it's not apparent whether your post
is part of the problem or part of the solution. Enlightenment, please.


Sorry for jumping in with a largely irrelevant comment. I didn't look
at the code, just sought to illustrate the 6/18 thing further, in a kneejerk reaction.
Though BTW FWIW the visual sequence of glyphs representing the data was more a str output
than repr, I guess:
repr("C\x01\x02\x10'\x83") '"C\\x01\\x02\\x10\'\\x83"' str("C\x01\x02\x10'\x83")

"C\x01\x02\x10'\x83"

Sorry, no enlightenment ;-)

Regards,
Bengt Richter
Jul 18 '05 #10

P: n/a
the hardware is a school project that uses a microcontroller for "light dimming"
the message command "67" will tell the microcontroller (PIC16F877) to
do a command (to control the intensity of a lamp)
the message command "70" should tell the GUI that the microcontroller
has started transmitting.
the message sent by the GUI is different from the message sent by the
microcontroller
(but i guess sir John is right, i think i should use different
variable for the data transmitted and data received)
i am currently developing this part of the project which implements
the serial communication
i've fixed the command and total_data since i know beforehand that
this will be its value.
to simplify the program, i have also fixed the message_no since the
microcontroller will still accept the transmitted data as long as the
checksum == 0.

anymore suggestion???...
==================================================
command = 67
message_no = 1
total_data = 2
item=10000
for item in range(10000, 30001, 250):
ser.open()
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))
data = ser.read(10)
(command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum) = unpack('10B', data) #serial receive
protocol
print command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum
ser.flushInput()
ser.close()

===================================
i've rewritten the code and deleted some unnecessary entries, now the
problem is :
21 6 64 64 192 0 0 0 175 70
70 2 6 64 64 192 0 0 0 114
70 11 6 64 64 192 0 0 0 105
0 0 104 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114
128 128 103 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114
16 208 246 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114

===================================
the received data does not always start with the command "70",
is this ok??? since i can always search first for the command "70"
before i read the remaining 9 bytes, then calculate first for the
checksum before finally accepting the received data.

am i making sense here?! please help me...
Jul 18 '05 #11

P: n/a
this is not working, what is wrong with this code?? what it "should"
do is find first the command "70" then read the remaining 9 bytes once
the command was found:

rx_data1=0
while (rx_data1 != 0x46):
rx_data1 = ser.read(1)
(rx_command) = unpack('1B', rx_data1)

rc_data2=ser.read(9)
(rx_msg_no, rx_no_databyte, temp1, temp2, pyra1, pyra2, voltage,
current, rx_checksum) = unpack('9B', data)
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum
===================================

this replaces this chunk from the original code:
data = ser.read(10)
(command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum) = unpack('10B', data) #serial receive
protocol
print command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum

===================================

thanks again
Jul 18 '05 #12

P: n/a
On Sun, 13 Mar 2005 14:56:55 +0800, jrlen balane <nb******@gmail.com>
declaimed the following in comp.lang.python:
to simplify the program, i have also fixed the message_no since the
microcontroller will still accept the transmitted data as long as the
checksum == 0.
Ah, but DOES the checksum = 0?

I notice you haven't been testing the received data checksum, or
you would have noticed that it sums ALL bytes from the command
introducer to just before the checksum value.

From the middle of your data listing:
70 2 6 64 64 192 0 0 0 114
print -(70 + 2 + 6 + 64 + 64 + 192) & 0xFF 114 print -(70 + 2 + 6 + 64 + 64 + 192 + 114) & 0xFF 0


That would seem to imply that the checksum you should be sending
ALSO incorporates all bytes. This time, from your code...
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))
You are calculating a checksum that is not including the
message_no and total_data fields. What happens if you use:

checksum = -(command + message_no, + total_data +
data_lo, data_hi) & 0xFF

21 6 64 64 192 0 0 0 175 70
70 2 6 64 64 192 0 0 0 114
70 11 6 64 64 192 0 0 0 105
0 0 104 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114 the received data does not always start with the command "70",
is this ok??? since i can always search first for the command "70"
Ah, but /can/ you search for the first 70... Notice how your
first line of data ENDED with a 70. If you treat that as the
command/response introducer, and then read 9 more bytes, you will be
reading
70 message number
2 data length
6 data1
64 data2
64 ?
192 ?
0 ?
0 ?
0 checksum

Off-hand, I'd have to wonder if you are losing bytes during your
processing -- is there any active hardware handshaking on that serial
port (9600bps is getting rather fast for no handshaking).
70 11 6 64 64 192 0 0 0 105
0 0 104 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114
Note how the first line I've quoted is a valid response with message
number 11. Then, look at the next line -- "0 0 104", if you assume the
104 is a checksum, it would be consistent with a message string of "70
12 6 64 64 129 0 0 0 104". Message number of 12, an incrementing
sequence, but you've lost 7 bytes. You then have seven bytes that start
a response, but are missing the last three, before getting a full line
with message number 2 (which seems to be rcvd#+1, if you are sending a
constant 1).
before i read the remaining 9 bytes, then calculate first for the
checksum before finally accepting the received data.

am i making sense here?! please help me...
I have the feeling you should modularize down to a function to
retrieve a response that makes use of the data length... In pseudo-code
(since I don't know the serial module in use):

def getPacket():
data = []
checksum = 0
(message_code, sequence_no, data_length) = serial.read(3)
checksum = message_code + sequence_no + data_length
for d in range(data_length):
data.append(serial.read(1))
checksum += data[d]
checksum += serial.read(1)
if (-checksum & 0xFF) != 0:
#bad packet -- raise an exception?
return (message_code, sequence_no, data_length, data)
#don't need to return checksum, it has been tested already

For completeness, a send probably should be created also...

def sendPacket(message_code, sequence_no, data=None):
#don't need data_length, as that would be computed from the
#length of data itself; 0 for [] or None, otherwise len(data)
If you are losing data from lack of handshaking and data
overrun, you may need to make the getPacket routine into a thread (and
maybe another thread for sending), so it can just do continuous reading,
and for every valid response sequence put it onto a Queue, where the
main thread can extract it when it is ready to process the contents.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Jul 18 '05 #13

P: n/a
On Sun, 13 Mar 2005 15:12:24 +0800, jrlen balane <nb******@gmail.com>
declaimed the following in comp.lang.python:
this is not working, what is wrong with this code?? what it "should"
Insufficient data... What is it /doing/ that makes you say it
"is not working".
do is find first the command "70" then read the remaining 9 bytes once
the command was found:
See my prior response, where you had a line ending a 70,
followed by a valid line starting with 70... If you were reading for the
first 70, and then took 9 more bytes, you were reading garbage -- the
code is doing exactly what you asked for.
rx_data1=0
while (rx_data1 != 0x46):
rx_data1 = ser.read(1)
(rx_command) = unpack('1B', rx_data1)
Isn't this unpack rather redundant -- assuming ser.read(1) only
reads one byte, then rx_data1 and rx_command would be identical.

rc_data2=ser.read(9)
(rx_msg_no, rx_no_databyte, temp1, temp2, pyra1, pyra2, voltage,
current, rx_checksum) = unpack('9B', data)
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum
Are your data arguments in the correct order? On your previous
message, the slots for voltage and current were coming back as 0, 0
while temp1 and temp2 had non-zero values.

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Jul 18 '05 #14

P: n/a

jrlen balane wrote:
the hardware is a school project that uses a microcontroller for "light dimming" the message command "67" will tell the microcontroller (PIC16F877) to
do a command (to control the intensity of a lamp)
the message command "70" should tell the GUI that the microcontroller
has started transmitting.
the message sent by the GUI is different from the message sent by the
microcontroller
(but i guess sir John is right, i think i should use different
variable for the data transmitted and data received)
i am currently developing this part of the project which implements
the serial communication
i've fixed the command and total_data since i know beforehand that
this will be its value.
to simplify the program, i have also fixed the message_no since the
microcontroller will still accept the transmitted data as long as the
checksum == 0.
(1) But it's NOT zero after the first time around! (2) How do you know
what it will accept? Guessing or reading the manual? If the checksum is
not zero, then what happens? Please quote the exact section from the
manual.

anymore suggestion???...
YES: show the whole program; you have left out the initialisation part.
==================================================
command = 67
message_no = 1
total_data = 2
item=10000
for item in range(10000, 30001, 250):
ser.open()
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))
data = ser.read(10)
(command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum) = unpack('10B', data) #serial receive
protocol
print command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum
ser.flushInput()
ser.close()

===================================
i've rewritten the code and deleted some unnecessary entries, now the
problem is :
21 6 64 64 192 0 0 0 175 70
70 2 6 64 64 192 0 0 0 114
70 11 6 64 64 192 0 0 0 105
0 0 104 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114
128 128 103 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114
16 208 246 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114

===================================
the received data does not always start with the command "70",
is this ok??? since i can always search first for the command "70"
before i read the remaining 9 bytes, then calculate first for the
checksum before finally accepting the received data.

am i making sense here?! please help me...


As Dennis has told you, searching is pointless. You are losing data
now. Before you weren't losing data. Until you fix that problem,
fiddling with anything else is pointless. You have stopped doing
sleep() -- why? You are now doing ser.open() and ser.flushInput() and
ser.close() on *each* time around the loop -- why? I'd strongly suggest
you put these back the way they were. THEN do what I told you to do:
use a separate tx_command and rx_command. The first time through the
loop, command is set to 70 from the received data, and then the second
time around, you SEND 70, not 67!!! Fix that, and then show us what you
get. DON'T try searching for a 70. Don't thrash around trying multiple
changes at once -- make changes one at a time so you can see the
effects.

Do you have a part number for the manual which describes the 67 and 70
"commands" and the check-sum? Is the manual on the internet anywhere?

Jul 18 '05 #15

P: n/a
the assembly program for the microcontroller is created by a
classmate. he based the protocol for the serial program from a
protocol he found in the internet. unfortunately, i can't find the
fpdf file, guess i'll just ask him later when he comes back.

On 13 Mar 2005 03:28:43 -0800, John Machin <sj******@lexicon.net> wrote:

jrlen balane wrote:
the hardware is a school project that uses a microcontroller for

"light dimming"
the message command "67" will tell the microcontroller (PIC16F877) to
do a command (to control the intensity of a lamp)
the message command "70" should tell the GUI that the microcontroller
has started transmitting.
the message sent by the GUI is different from the message sent by the
microcontroller
(but i guess sir John is right, i think i should use different
variable for the data transmitted and data received)
i am currently developing this part of the project which implements
the serial communication
i've fixed the command and total_data since i know beforehand that
this will be its value.
to simplify the program, i have also fixed the message_no since the
microcontroller will still accept the transmitted data as long as the
checksum == 0.


(1) But it's NOT zero after the first time around! (2) How do you know
what it will accept? Guessing or reading the manual? If the checksum is
not zero, then what happens? Please quote the exact section from the
manual.

anymore suggestion???...


YES: show the whole program; you have left out the initialisation part.
==================================================
command = 67
message_no = 1
total_data = 2
item=10000
for item in range(10000, 30001, 250):
ser.open()
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))
data = ser.read(10)
(command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum) = unpack('10B', data) #serial receive
protocol
print command, msg_no, no_databyte, temp1, temp2, pyra1, pyra2,
voltage, current, checksum
ser.flushInput()
ser.close()

===================================
i've rewritten the code and deleted some unnecessary entries, now the
problem is :
21 6 64 64 192 0 0 0 175 70
70 2 6 64 64 192 0 0 0 114
70 11 6 64 64 192 0 0 0 105
0 0 104 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114
128 128 103 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114
16 208 246 70 2 6 64 64 192 0
70 2 6 64 64 192 0 0 0 114

===================================
the received data does not always start with the command "70",
is this ok??? since i can always search first for the command "70"
before i read the remaining 9 bytes, then calculate first for the
checksum before finally accepting the received data.

am i making sense here?! please help me...


As Dennis has told you, searching is pointless. You are losing data
now. Before you weren't losing data. Until you fix that problem,
fiddling with anything else is pointless. You have stopped doing
sleep() -- why? You are now doing ser.open() and ser.flushInput() and
ser.close() on *each* time around the loop -- why? I'd strongly suggest
you put these back the way they were. THEN do what I told you to do:
use a separate tx_command and rx_command. The first time through the
loop, command is set to 70 from the received data, and then the second
time around, you SEND 70, not 67!!! Fix that, and then show us what you
get. DON'T try searching for a 70. Don't thrash around trying multiple
changes at once -- make changes one at a time so you can see the
effects.

Do you have a part number for the manual which describes the 67 and 70
"commands" and the check-sum? Is the manual on the internet anywhere?

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #16

P: n/a
Bengt Richter wrote:
Sorry for jumping in with a largely irrelevant comment. I didn't look
at the code, just sought to illustrate the 6/18 thing further, in a kneejerk reaction.
Though BTW FWIW the visual sequence of glyphs representing the data was more a str output
than repr, I guess:
>>> repr("C\x01\x02\x10'\x83") '"C\\x01\\x02\\x10\'\\x83"' >>> str("C\x01\x02\x10'\x83")

"C\x01\x02\x10'\x83"


Actually, both of those have an additional repr() call
courtesy of the Python interactive console. The output
of str() on that string is unprintable, but the above
representation has already been repr()ed by Python for
consumption by fragile hyoo-mans...

-Peter
Jul 18 '05 #17

P: n/a
Dennis Lee Bieber wrote:
rx_data1=0
while (rx_data1 != 0x46):
rx_data1 = ser.read(1)
(rx_command) = unpack('1B', rx_data1)


Isn't this unpack rather redundant -- assuming ser.read(1) only
reads one byte, then rx_data1 and rx_command would be identical.


Brain fart... unpack converts the raw bytes to integer
values with the "B" format character. You're thinking
of what would happen with a "1c" format.

-Peter
Jul 18 '05 #18

P: n/a
@ sir Peter
so you mean that it is correct (at least on the unpack() part)

when i run this program on IDLE , Python 2.3 (enthought edition),
nothing is outputted on the shell, until i decide to close the shell,
wherein it tells me if i would like to kill a process...

import serial
import string
import time
from struct import *

ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser
ser.close()
ser.open()

command = 67
message_no = 1
total_data = 2

item = 10000

for item in range(10000, 30001, 250):
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))

rx_data1=0
while (rx_data1 != 0x46):
rx_data1 = ser.read(1)
(rx_command) = unpack('1B', rx_data1)

rx_data2=ser.read(9)
(rx_msg_no, rx_no_databyte, temp1, temp2, pyra1, pyra2, voltage,
current, rx_checksum) = unpack('9B', data)
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum

ser.close()
Jul 18 '05 #19

P: n/a
On Sun, 13 Mar 2005 10:46:52 -0500, Peter Hansen <pe***@engcorp.com> wrote:
Bengt Richter wrote:
Sorry for jumping in with a largely irrelevant comment. I didn't look
at the code, just sought to illustrate the 6/18 thing further, in a kneejerk reaction.
Though BTW FWIW the visual sequence of glyphs representing the data was more a str output
than repr, I guess:
>>> repr("C\x01\x02\x10'\x83")

'"C\\x01\\x02\\x10\'\\x83"'
>>> str("C\x01\x02\x10'\x83")

"C\x01\x02\x10'\x83"


Actually, both of those have an additional repr() call
courtesy of the Python interactive console. The output
of str() on that string is unprintable, but the above
representation has already been repr()ed by Python for
consumption by fragile hyoo-mans...

Ok,
print repr("C\x01\x02\x10'\x83")

"C\x01\x02\x10'\x83"

But note that _no_ str-type string is printable at all until you assume
that it is an encoding identifying a glyph sequence and you (re)encode/interpret
for a device (virtual or not) that has a font and can present the font
information visually to your eyes (or via some modulation of sensible
environment for other senses) ;-)

Regards,
Bengt Richter
Jul 18 '05 #20

P: n/a
why is it that here:

1)rx_data = ser.read(10)
(rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum) = unpack('10B', rx_data)
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum
type (rx_command) <type 'int'>

but here:

2)rx_data_command = ser.read()
(rx_command) = unpack('1B', rx_data_command)
type (rx_command)
<type 'tuple'>

how can i make rx_command of type 'int' if i am to use 2)?

@sir John
the reason why my first post all starts with '70' , which is what i
really wanted to happen, is that it is buffered. the microcontroller
sends data at a very fast rate, that the program just retrieve data
from the buffer. so basically, they are not "real time". but there are
also cases where the command is in other position. the good thing is,
it remains in that position throughout...

i want to make the program show data in "real time" so everytime i am
able to read data, i immediately use flushInput(), to erase data from
the buffer.

so i what i want to do now is to search for the rx_command first
('70') just so i know where my data should start.

the checksum will be validated, but first, i must know where my checksum is!
if (rx_checksum != -(temp1 + temp2 + pyra1 + pyra2 + voltage + current
+ rx_command + rx_message_no + rx_no_databyte) & 0xff):
#then discard message, loop again to search for rx_command

plase help...

On 13 Mar 2005 13:06:16 -0800, John Machin <sj******@lexicon.net> wrote:
Jan Rienyer Gadil wrote:
@ sir Peter
so you mean that it is correct (at least on the unpack() part)


No he doesn't mean that at all. All it means is that minor scuffles
have broken out among the spectators. Don't worry about them, batons &
water cannon will fix them; you concentrate on the football match :-)

when i run this program on IDLE , Python 2.3 (enthought edition),
nothing is outputted on the shell, until i decide to close the shell,
wherein it tells me if i would like to kill a process...


So you did some elementary debugging, like putting in some print
statements at various places, as shown below, and what happened?

import serial
import string


Redundant.
import time
from struct import *

ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser


What is the above line meant to do? It actually does nothing.
ser.close()
ser.open()

command = 67
message_no = 1
total_data = 2

item = 10000


Redundant.


print "DEBUG: before outer loop"

for item in range(10000, 30001, 250):


print "DEBUG: inside outer loop; item =", repr(item)
data_hi, data_lo = divmod(item, 0x100)
checksum = -(data_hi + data_lo + 0x46) & 0xff


You obviouly haven't taken the advice to generalise your checksum
calculation.
ser.write(pack('6B', command, message_no, total_data, data_lo,
data_hi, checksum))

rx_data1=0


print "DEBUG: before inner loop"
while (rx_data1 != 0x46):
rx_data1 = ser.read(1)
(rx_command) = unpack('1B', rx_data1)


print "DEBUG: inside inner loop; rx_data1 =", repr(rx_data1), ";
rx_command =", repr(rx_command)

And if you had have done that, you would/should have realised that you
have a:
!! CODING BUG !!
ser.read(1) will return a STRING, so even if you get the byte you are
looking for, rx_data1 will refer to 'F' == chr(70) == chr(0x46) ==
'\x46' none of which are == 0x46, and you will loop forever (if the
hardware is continuously outputting data) or hang waiting for data from
the hardware.

!! DESIGN BUG !!
HOWEVER, as Dennis and I have been trying to tell you, it is WRONG to
be looping trying to sync on the first character in the packet. You
need to fix your data loss problem, not try to kludge your way around
it. I'll say it again, but only once: go back to the code of your
original posting. That code was not losing data. Among whatever else is
needed to revert to the first-shown code, put back the sleep() between
iterations.
As advised earlier, make sure that you use separate rx_command and
tx_command so that you don't accidentally start sending 70 as the
command.
Then show us what happened.
rx_data2=ser.read(9)
(rx_msg_no, rx_no_databyte, temp1, temp2, pyra1, pyra2, voltage,
current, rx_checksum) = unpack('9B', data)


!! CODING BUG !!
You read into "rx_data2" but unpack from "data". The result, when you
reach it after fixing the earlier bug, will be either an exception or
an utter nonsense, depending on what "data" is bound to at the time (if
anything).
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2,

pyra1,
pyra2, voltage, current, rx_checksum


You obviously haven't taken the advice from Dennis and myself to
validate the packet you receive -- (1) checksum is OK (2)
rx_no_databyte == 6
ser.close()


HTH,
John

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #21

P: n/a

jrlen balane wrote:
why is it that here:

1)rx_data = ser.read(10)
(rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum) = unpack('10B', rx_data)
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum
type (rx_command) <type 'int'>

but here:

2)rx_data_command = ser.read()
Are you sure you have really have read() -- which will read all
available data -- or read(1) -- which will read just one byte???
(rx_command) = unpack('1B', rx_data_command)
type (rx_command)
<type 'tuple'>

how can i make rx_command of type 'int' if i am to use 2)?


unpack returns a tuple. In 1) you unpack it. In 2) you don't unpack it.

either do this:

(rx_command,) = unpack('1B', rx_data_command) # unpack tuple

or this:

rx_command = unpack('1B', rx_data_command)[0] # grab 1st element of
tuple

or, simply, to get what you want, just do this:

rx_command = ord(ser.read(1))

@sir John
the reason why my first post all starts with '70' , which is what i
really wanted to happen, is that it is buffered. the microcontroller
sends data at a very fast rate, that the program just retrieve data
from the buffer. so basically, they are not "real time". but there are also cases where the command is in other position. the good thing is,
it remains in that position throughout...
It wasn't doing that before; In the second posting with examples, there
were some that were a MIXTURE of (a) 70 as the first byte of 10 (b) 70
as the fourth byte of 10 (128 128 103 70 2 6 64 64 192 0)

i want to make the program show data in "real time" so everytime i am
able to read data, i immediately use flushInput(), to erase data from
the buffer.
How large is the buffer?

so i what i want to do now is to search for the rx_command first
('70') just so i know where my data should start.


OK, so NOW you are saying that the microcontroller is pumping out data
continuously, it's not one response to each of your "67" commands???

In that case what I'd suggest you do is to read 19 bytes from the
serial port (with time-out, I'd suggest; give up if you don't get 19
bytes returned), and for each k in range(9), test for:

(a) byte[k] == 70
(b) byte[k+2] == 6
(c) checksum(byte[k:k+10]) == 0

If you don't get a valid data packet, give up.

This should snatch one valid data packet (if there are any) from the
torrent.

Jul 18 '05 #22

P: n/a
@sir John
could you please show me how to do this exactly? it's in the "tip of
my toungue" but i just can get it, please...
On 14 Mar 2005 14:06:15 -0800, John Machin <sj******@lexicon.net> wrote:

jrlen balane wrote:
why is it that here:

1)rx_data = ser.read(10)
(rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum) = unpack('10B', rx_data)
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum
>> type (rx_command)

<type 'int'>

but here:

2)rx_data_command = ser.read()


Are you sure you have really have read() -- which will read all
available data -- or read(1) -- which will read just one byte???
(rx_command) = unpack('1B', rx_data_command)
>> type (rx_command)

<type 'tuple'>

how can i make rx_command of type 'int' if i am to use 2)?


unpack returns a tuple. In 1) you unpack it. In 2) you don't unpack it.

either do this:

(rx_command,) = unpack('1B', rx_data_command) # unpack tuple

or this:

rx_command = unpack('1B', rx_data_command)[0] # grab 1st element of
tuple

or, simply, to get what you want, just do this:

rx_command = ord(ser.read(1))

@sir John
the reason why my first post all starts with '70' , which is what i
really wanted to happen, is that it is buffered. the microcontroller
sends data at a very fast rate, that the program just retrieve data
from the buffer. so basically, they are not "real time". but there

are
also cases where the command is in other position. the good thing is,
it remains in that position throughout...


It wasn't doing that before; In the second posting with examples, there
were some that were a MIXTURE of (a) 70 as the first byte of 10 (b) 70
as the fourth byte of 10 (128 128 103 70 2 6 64 64 192 0)

i want to make the program show data in "real time" so everytime i am
able to read data, i immediately use flushInput(), to erase data from
the buffer.


How large is the buffer?

so i what i want to do now is to search for the rx_command first
('70') just so i know where my data should start.


OK, so NOW you are saying that the microcontroller is pumping out data
continuously, it's not one response to each of your "67" commands???

In that case what I'd suggest you do is to read 19 bytes from the
serial port (with time-out, I'd suggest; give up if you don't get 19
bytes returned), and for each k in range(9), test for:

(a) byte[k] == 70
(b) byte[k+2] == 6
(c) checksum(byte[k:k+10]) == 0

If you don't get a valid data packet, give up.

This should snatch one valid data packet (if there are any) from the
torrent.

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #23

P: n/a

jrlen balane wrote:
@sir John
could you please show me how to do this exactly? it's in the "tip of
my toungue" but i just can get it, please...


You've had far too much help already for a school project. Asking for
someone to write the code for you is "over the fence".

Jul 18 '05 #24

P: n/a
On 14 Mar 2005 17:04:13 -0800, "John Machin" <sj******@lexicon.net>
declaimed the following in comp.lang.python:

jrlen balane wrote:
@sir John
could you please show me how to do this exactly? it's in the "tip of
my toungue" but i just can get it, please...

You've had far too much help already for a school project. Asking for
someone to write the code for you is "over the fence".


The repetition /is/ getting tedious, isn't it...

At the least, getting a formal definition of the protocol the
microcontroller uses would be nice. If it is continuously sending "70"
status reports, WITHOUT handshaking (RTS/CTS), then I'd strongly
recommend making the reader code a separate thread -- hopefully one
won't lose bytes during other processing. When a valid status report is
found, put it onto a Queue, which the main code can read when ever it
finds time.

Heck, at this point in time... I'd remove everything involved
with /sending/ commands. Start with coding something that only reads the
status from the microcontroller (since it sounds like the controller is
always sending). When the reader works correctly, then start trying to
add the command writer.

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Jul 18 '05 #25

P: n/a
rx_data = ser.read(19)
byte[] = unpack('19B', rx_data)

for k in range(9):
if byte[k] == 70
if byte[k+2] == 6
if byte[k+9] ==
-(byte[k]+byte[k+1]+byte[k+2]+byte[k+3]+byte[k+4]+byte[k+5]+byte[k+6]+byte[k+7]+byte[k+8])
& 0xff
print byte[k:k+9]
====================================
what i am doing here is creating an array from based on the unpacked data
then i am searching for the array member that is equal to "70" since
it is going to be my reference. once i find it, i'll based my received
data from that point. then if the succeding tests are confirmed, i can
get my data.

please help....(again) :(
On Tue, 15 Mar 2005 08:05:04 GMT, Dennis Lee Bieber
<wl*****@ix.netcom.com> wrote:
On 14 Mar 2005 17:04:13 -0800, "John Machin" <sj******@lexicon.net>
declaimed the following in comp.lang.python:

jrlen balane wrote:
@sir John
could you please show me how to do this exactly? it's in the "tip of
my toungue" but i just can get it, please...


You've had far too much help already for a school project. Asking for
someone to write the code for you is "over the fence".


The repetition /is/ getting tedious, isn't it...

At the least, getting a formal definition of the protocol the
microcontroller uses would be nice. If it is continuously sending "70"
status reports, WITHOUT handshaking (RTS/CTS), then I'd strongly
recommend making the reader code a separate thread -- hopefully one
won't lose bytes during other processing. When a valid status report is
found, put it onto a Queue, which the main code can read when ever it
finds time.

Heck, at this point in time... I'd remove everything involved
with /sending/ commands. Start with coding something that only reads the
status from the microcontroller (since it sounds like the controller is
always sending). When the reader works correctly, then start trying to
add the command writer.

--
> ================================================== ============ <
> wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wu******@dm.net | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #26

P: n/a
did some editing:

rx_data = ser.read(19)
byte[0:18] = unpack('19B', rx_data)

for k in range(9):
if byte[k] == 70:
if byte[k+2] == 6:
if byte[k+9] ==
-(byte[k]+byte[k+1]+byte[k+2]+byte[k+3]+byte[k+4]+byte[k+5]+byte[k+6]+byte[k+7]+byte[k+8])
& 0xff:
print byte[k:k+9]
====================================
heres the error:
Traceback (most recent call last):
File "C:\Python23\practices\serialnewesttest2.py", line 28, in -toplevel-
byte[0:18] = unpack('19B', rx_data)
error: unpack str size does not match format

what i am doing here is creating an array from based on the unpacked data
then i am searching for the array member that is equal to "70" since
it is going to be my reference. once i find it, i'll based my received
data from that point. then if the succeding tests are confirmed, i can
get my data.

please help....(again) :(
Jul 18 '05 #27

P: n/a

jrlen balane wrote:
did some editing:

The error means that you received less than 19 bytes of data.
rx_data = ser.read(19) !rx_len = len(rx_data)
!print 'rx_len', rx_len byte[0:18] = unpack('19B', rx_data) !# trash the above, do this
!byte = [ord(x) for x in rx_data]
!print 'received', byte
!if rx_len < 10:
! print 'it is not pumping data out as fast as we assumed!'
! sys.exit(1) !for k in range(rx_len - 9): if byte[k] == 70:
if byte[k+2] == 6:
if byte[k+9] ==
-(byte[k]+byte[k+1]+byte[k+2]+byte[k+3]+byte[k+4]+byte[k+5]+byte[k+6]+byte[k+7]+byte[k+8]) & 0xff:
Yuk!

(1) use 'and'
(2) when you find yourself typing repetitive crap like that, your brain
should be shrieking "There must be a better way!!"

if byte[k] == 70 \
and byte[k+2] == 6 \
and sum(byte[k:k+10]) & 0xff == 0:
print byte[k:k+9] <<<<<<=== you probably mean 10, not nine ====================================
heres the error:
Traceback (most recent call last):
File "C:\Python23\practices\serialnewesttest2.py", line 28, in -toplevel- byte[0:18] = unpack('19B', rx_data)
error: unpack str size does not match format

what i am doing here is creating an array from based on the unpacked data then i am searching for the array member that is equal to "70" since
it is going to be my reference. once i find it, i'll based my received data from that point. then if the succeding tests are confirmed, i can get my data.

please help....(again) :(


Jul 18 '05 #28

P: n/a
will this be correct???
what i want to happen is saved every received data (6 data bytes) to
an array for each one.

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])

if time.sleep(300) == True:
temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

and after x minutes of of receiving data, the arrays will be emptied
of its contents.

thanks again for the help.
On 15 Mar 2005 02:13:40 -0800, John Machin <sj******@lexicon.net> wrote:

jrlen balane wrote:
did some editing:


The error means that you received less than 19 bytes of data.
rx_data = ser.read(19)

!rx_len = len(rx_data)
!print 'rx_len', rx_len
byte[0:18] = unpack('19B', rx_data)

!# trash the above, do this
!byte = [ord(x) for x in rx_data]
!print 'received', byte
!if rx_len < 10:
! print 'it is not pumping data out as fast as we assumed!'
! sys.exit(1)

!for k in range(rx_len - 9):
if byte[k] == 70:
if byte[k+2] == 6:
if byte[k+9] ==

-(byte[k]+byte[k+1]+byte[k+2]+byte[k+3]+byte[k+4]+byte[k+5]+byte[k+6]+byte[k+7]+byte[k+8])
& 0xff:


Yuk!

(1) use 'and'
(2) when you find yourself typing repetitive crap like that, your brain
should be shrieking "There must be a better way!!"

if byte[k] == 70 \
and byte[k+2] == 6 \
and sum(byte[k:k+10]) & 0xff == 0:
print byte[k:k+9] <<<<<<=== you probably mean 10,

not nine
====================================
heres the error:
Traceback (most recent call last):
File "C:\Python23\practices\serialnewesttest2.py", line 28, in

-toplevel-
byte[0:18] = unpack('19B', rx_data)
error: unpack str size does not match format

what i am doing here is creating an array from based on the unpacked

data
then i am searching for the array member that is equal to "70" since
it is going to be my reference. once i find it, i'll based my

received
data from that point. then if the succeding tests are confirmed, i

can
get my data.

please help....(again) :(


--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #29

P: n/a
ok heres the code, i'm trying on IDLE:

import sys
import serial
import sys, os
import serial
import string
import time
from struct import *

data_file = open('C:/Documents and Settings/nyer/Desktop/IRRADIANCE.txt', 'r')
data = data_file.readlines()

def process(list_of_lines):
data_points = []
for line in list_of_lines:
data_points.append(int(line))
return data_points

irradiance = process(data)

ser = serial.Serial()
ser.baudrate = 9600
ser.port = 0
ser

ser.open()
tx_command = 67
tx_no_databyte = 2
tx_message_no = 1
tx_len = len (irradiance)

for j in range (tx_len) :
start_time = time.time()

temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

current_time = time.time()

while( current_time >= start_time + 300):

data_hi, data_lo = divmod(irradiance[j], 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no
+ tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no,
tx_no_databyte, data_lo, data_hi, tx_checksum))

rx_data = ser.read(19)
rx_len = len(rx_data)
byte = [ord(x) for x in rx_data]

if rx_len < 10:
#print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10])
& 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])
print temp1, temp2, pyra1, pyra2, voltage, current

current_time = time.time()

while theres no error in the output, there is also no response from
the hardware or maybe communication is off.

could somebody out there help me.

by the way, here is a working code: though here the data to be
transmitted is just incrementing and not read from a text file:

import serial
import string
import time
from struct import *
import os

ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser.timeout = 1
ser
ser.open()
tx_command = 67
tx_message_no = 1
tx_no_databyte = 2
item=10000
for item in range(10000, 30001, 10):

data_hi, data_lo = divmod(item, 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no +
tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no, tx_no_databyte,
data_lo, data_hi, tx_checksum))
#print tx_command, tx_message_no, tx_total_data, data_lo, data_hi,
tx_checksum
rx_data = ser.read(19)
rx_len = len(rx_data)
#print 'rx_len', rx_len
byte = [ord(x) for x in rx_data]
#print 'received', byte
if rx_len < 10:
print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
print byte[k:k+10]
===================================
outputs:
[70, 2, 6, 54, 197, 253, 230, 231, 211, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
....
....

On Wed, 16 Mar 2005 07:34:44 +0800, jrlen balane <nb******@gmail.com> wrote:
will this be correct???
what i want to happen is saved every received data (6 data bytes) to
an array for each one.

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])

if time.sleep(300) == True:
temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

and after x minutes of of receiving data, the arrays will be emptied
of its contents.

thanks again for the help.
On 15 Mar 2005 02:13:40 -0800, John Machin <sj******@lexicon.net> wrote:

jrlen balane wrote:
did some editing:


The error means that you received less than 19 bytes of data.
rx_data = ser.read(19)

!rx_len = len(rx_data)
!print 'rx_len', rx_len
byte[0:18] = unpack('19B', rx_data)

!# trash the above, do this
!byte = [ord(x) for x in rx_data]
!print 'received', byte
!if rx_len < 10:
! print 'it is not pumping data out as fast as we assumed!'
! sys.exit(1)

!for k in range(rx_len - 9):
if byte[k] == 70:
if byte[k+2] == 6:
if byte[k+9] ==

-(byte[k]+byte[k+1]+byte[k+2]+byte[k+3]+byte[k+4]+byte[k+5]+byte[k+6]+byte[k+7]+byte[k+8])
& 0xff:


Yuk!

(1) use 'and'
(2) when you find yourself typing repetitive crap like that, your brain
should be shrieking "There must be a better way!!"

if byte[k] == 70 \
and byte[k+2] == 6 \
and sum(byte[k:k+10]) & 0xff == 0:
print byte[k:k+9] <<<<<<=== you probably mean 10,

not nine
====================================
heres the error:
Traceback (most recent call last):
File "C:\Python23\practices\serialnewesttest2.py", line 28, in

-toplevel-
byte[0:18] = unpack('19B', rx_data)
error: unpack str size does not match format

what i am doing here is creating an array from based on the unpacked

data
then i am searching for the array member that is equal to "70" since
it is going to be my reference. once i find it, i'll based my

received
data from that point. then if the succeding tests are confirmed, i

can
get my data.

please help....(again) :(


--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #30

P: n/a
please post your suggestions? please ...
On Wed, 16 Mar 2005 08:33:23 +0800, jrlen balane <nb******@gmail.com> wrote:
ok heres the code, i'm trying on IDLE:

import sys
import serial
import sys, os
import serial
import string
import time
from struct import *

data_file = open('C:/Documents and Settings/nyer/Desktop/IRRADIANCE.txt', 'r')
data = data_file.readlines()

def process(list_of_lines):
data_points = []
for line in list_of_lines:
data_points.append(int(line))
return data_points

irradiance = process(data)

ser = serial.Serial()
ser.baudrate = 9600
ser.port = 0
ser

ser.open()
tx_command = 67
tx_no_databyte = 2
tx_message_no = 1
tx_len = len (irradiance)

for j in range (tx_len) :
start_time = time.time()

temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

current_time = time.time()

while( current_time >= start_time + 300):

data_hi, data_lo = divmod(irradiance[j], 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no
+ tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no,
tx_no_databyte, data_lo, data_hi, tx_checksum))

rx_data = ser.read(19)
rx_len = len(rx_data)
byte = [ord(x) for x in rx_data]

if rx_len < 10:
#print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10])
& 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])
print temp1, temp2, pyra1, pyra2, voltage, current

current_time = time.time()

while theres no error in the output, there is also no response from
the hardware or maybe communication is off.

could somebody out there help me.

by the way, here is a working code: though here the data to be
transmitted is just incrementing and not read from a text file:

import serial
import string
import time
from struct import *
import os

ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser.timeout = 1
ser

ser.open()
tx_command = 67
tx_message_no = 1
tx_no_databyte = 2
item=10000
for item in range(10000, 30001, 10):

data_hi, data_lo = divmod(item, 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no +
tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no, tx_no_databyte,
data_lo, data_hi, tx_checksum))
#print tx_command, tx_message_no, tx_total_data, data_lo, data_hi,
tx_checksum
rx_data = ser.read(19)
rx_len = len(rx_data)
#print 'rx_len', rx_len
byte = [ord(x) for x in rx_data]
#print 'received', byte

if rx_len < 10:
print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
print byte[k:k+10]
===================================
outputs:
[70, 2, 6, 54, 197, 253, 230, 231, 211, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
...
...

On Wed, 16 Mar 2005 07:34:44 +0800, jrlen balane <nb******@gmail.com> wrote:
will this be correct???
what i want to happen is saved every received data (6 data bytes) to
an array for each one.

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])

if time.sleep(300) == True:
temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

and after x minutes of of receiving data, the arrays will be emptied
of its contents.

thanks again for the help.
On 15 Mar 2005 02:13:40 -0800, John Machin <sj******@lexicon.net> wrote:

jrlen balane wrote:
> did some editing:
>

The error means that you received less than 19 bytes of data.

> rx_data = ser.read(19)
!rx_len = len(rx_data)
!print 'rx_len', rx_len
> byte[0:18] = unpack('19B', rx_data)
!# trash the above, do this
!byte = [ord(x) for x in rx_data]
!print 'received', byte
!if rx_len < 10:
! print 'it is not pumping data out as fast as we assumed!'
! sys.exit(1)
>
!for k in range(rx_len - 9):
> if byte[k] == 70:
> if byte[k+2] == 6:
> if byte[k+9] ==
>
-(byte[k]+byte[k+1]+byte[k+2]+byte[k+3]+byte[k+4]+byte[k+5]+byte[k+6]+byte[k+7]+byte[k+8])
> & 0xff:

Yuk!

(1) use 'and'
(2) when you find yourself typing repetitive crap like that, your brain
should be shrieking "There must be a better way!!"

if byte[k] == 70 \
and byte[k+2] == 6 \
and sum(byte[k:k+10]) & 0xff == 0:

> print byte[k:k+9] <<<<<<=== you probably mean 10,
not nine
> ====================================
> heres the error:
> Traceback (most recent call last):
> File "C:\Python23\practices\serialnewesttest2.py", line 28, in
-toplevel-
> byte[0:18] = unpack('19B', rx_data)
> error: unpack str size does not match format
>
> what i am doing here is creating an array from based on the unpacked
data
> then i am searching for the array member that is equal to "70" since
> it is going to be my reference. once i find it, i'll based my
received
> data from that point. then if the succeding tests are confirmed, i
can
> get my data.
>
> please help....(again) :(

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #31

P: n/a

jrlen balane wrote:

[from further down in the message]
could somebody out there help me.
You could try helping yourself. Insert some print statements at salient
points. [see examples below; you'll need to get the indentation
correct, of course] Try to understand what is happening.
ok heres the code, i'm trying on IDLE:

import sys
import serial
import sys, os
import serial
import string
import time
from struct import *

data_file = open('C:/Documents and Settings/nyer/Desktop/IRRADIANCE.txt', 'r') data = data_file.readlines()

def process(list_of_lines):
data_points = []
for line in list_of_lines:
data_points.append(int(line))
return data_points

irradiance = process(data)

ser = serial.Serial()
ser.baudrate = 9600
ser.port = 0
ser
I'll ask, for the 3rd time, what the @#$% is the above line meant to
achieve?

ser.open()
tx_command = 67
tx_no_databyte = 2
tx_message_no = 1
tx_len = len (irradiance)

for j in range (tx_len) :
start_time = time.time()

temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

current_time = time.time()
print 'before while stmt', j, start_time, current time

while( current_time >= start_time + 300):

print 'inside while stmt', j, start_time, current time

data_hi, data_lo = divmod(irradiance[j], 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no + tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no,
tx_no_databyte, data_lo, data_hi, tx_checksum))

rx_data = ser.read(19)
rx_len = len(rx_data)
byte = [ord(x) for x in rx_data]

if rx_len < 10:
#print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])
print temp1, temp2, pyra1, pyra2, voltage, current

current_time = time.time()
print 'after while stmt', j, start_time, current time


while theres no error in the output, there is also no response from
the hardware or maybe communication is off.


Jul 18 '05 #32

P: n/a
jrlen balane <nb******@gmail.com> wrote:
why is it that here:

1)rx_data = ser.read(10)
(rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum) = unpack('10B', rx_data)
print rx_command, rx_msg_no, rx_no_databyte, temp1, temp2, pyra1,
pyra2, voltage, current, rx_checksum
type (rx_command)<type 'int'>

but here:

2)rx_data_command = ser.read()
(rx_command) = unpack('1B', rx_data_command)
type (rx_command)

<type 'tuple'>

how can i make rx_command of type 'int' if i am to use 2)?


Did you get an answer to this? I couldn't see any responses. The answer
is either:

rx_command = unpack('1B', rx_data_command)[0]

or

(rx_command,) = unpack('1B', rx_data_command)
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jul 18 '05 #33

P: n/a
On Wed, 16 Mar 2005 09:47:01 +0800, jrlen balane <nb******@gmail.com>
declaimed the following in comp.lang.python:
please post your suggestions? please ...
Since we don't have your hardware, nor have you been able supply
the formal documentation of the protocol in use, all we can do is
comment on coding styles and obvious errors in the code... If there is
an flaw in the implementation of the protocol, we have no way to tell.
import sys
import serial
import sys, os
import serial
How about cleaning that up... You've imported serial twice, and
sys twice.
data_file = open('C:/Documents and Settings/nyer/Desktop/IRRADIANCE.txt', 'r')
data = data_file.readlines()

def process(list_of_lines):
data_points = []
for line in list_of_lines:
data_points.append(int(line))
return data_points

irradiance = process(data)
Well, this is legal, though confusing to stuff a function
definition between lines of the main program. Common is to put the
"def"s after the "imports" (though defining "constants" may be okay in
there)

If "process" is only used once, it might not even be worth the
"def"...

ser = serial.Serial()
ser.baudrate = 9600
ser.port = 0
ser Delete that -- you've been told that it is meaningless for days
now... If you don't want to take advice, why ask?

ser.open()
tx_command = 67
tx_no_databyte = 2
tx_message_no = 1
tx_len = len (irradiance)

for j in range (tx_len) :
start_time = time.time()

temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

current_time = time.time()

while( current_time >= start_time + 300):
If current time is < start+300, the entire loop will be skipped
-- a condition that is quite likely to happen unless you have a /very/
slow machine.
data_hi, data_lo = divmod(irradiance[j], 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no
+ tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no,
tx_no_databyte, data_lo, data_hi, tx_checksum))

rx_data = ser.read(19)
rx_len = len(rx_data)
byte = [ord(x) for x in rx_data]

if rx_len < 10:
#print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10])
& 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])
print temp1, temp2, pyra1, pyra2, voltage, current
All these are lists, do you really mean to print the entire list
each time, or only the most recent data value?
current_time = time.time()

while theres no error in the output, there is also no response from
the hardware or maybe communication is off.

could somebody out there help me.
by the way, here is a working code: though here the data to be
transmitted is just incrementing and not read from a text file:

import serial
import string
import time
from struct import *
import os

ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser.timeout = 1
ser

ser.open()
tx_command = 67
tx_message_no = 1
tx_no_databyte = 2
item=10000
for item in range(10000, 30001, 10):

data_hi, data_lo = divmod(item, 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no +
tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no, tx_no_databyte,
data_lo, data_hi, tx_checksum))
#print tx_command, tx_message_no, tx_total_data, data_lo, data_hi,
tx_checksum
rx_data = ser.read(19)
rx_len = len(rx_data)
#print 'rx_len', rx_len
byte = [ord(x) for x in rx_data]
#print 'received', byte

if rx_len < 10:
print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
print byte[k:k+10]
===================================
outputs:
[70, 2, 6, 54, 197, 253, 230, 231, 211, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
...
...


And please trim... You don't need to quote the same text over
and over... We've all seen it by now, or can retrieve it using the
message headers.

-=-=-=-=-=-=-=-=-=-=-=-=-
"""
EVERYTHING THAT FOLLOWS IS THE RESULT OF "FREE ASSOCIATION"
THINKING. NONE OF IT HAS BEEN TESTED FOR CORRECTNESS OF
SYNTAX OR SEMANTICS -- IT SHOULD BEST BE CONSIDERED PSEUDO-
CODE, GIVING A GUIDELINE FROM WHICH TO PROCEED WITH REAL
DEVELOPMENT
"""

import serial #I don't have this, and don't have your hardware,
#so this is all guesswork, and untested
import os
import sys
import time
import threading
import Queue

DATA_FID = r"C:\\Documents and Settings\\nyer\\Desktop\\IRRADIANCE.txt"
#I definitely don't have a "nyer" user <G>

class DeviceHandler(object):
def _checksum(packet):
# compute checksum from packet (which should be a list)
return -sum(packet) & 0xFF

def _Reader(self):
# worker code for the reader /thread/, continuous
# loop, reading response packets and putting them
# (or some error message string) onto the queue
while 1:
# accept first three as response code, message count
# and data length
response = ord(self._ser.read(1))
count = ord(self._ser.read(1))
length = ord(self._ser.read(1))
# get the data bytes
data = []
for x in range(length):
data.append(ord(self._ser.read(1)))
# get the message checksum
check = ord(self._ser.read(1))
# format it all as a packet list
packet = [response, count, length] + data
packet = packet.append(check)
# check for out of sequence packet
if count != self._RX_count:
# notify via queue, then reset expected counter
self._queue.put("Receive packet number is out of
sequence")
self._RX_count = count
# confirm checksome and notify if needed
if _checksum(packet) != 0:
self._queue.put("Receive packet checksum is invalid")
# put the packet, regardless of validity, onto queu
self._queue.put(packet)
self._RX_count += 1 & 0xFF #quick & dirty modulo 256

def __init__(self, port, rate, queue):
# initialize handler instance
self._TX_count = 0
self._RX_count = 0
self._ser = serial.Serial()
self._ser.port = port
self._ser.baudrate = rate
self._ser.open()
self._queue = queue
self._reader = threading.Thread(target=self._Reader())
# make the reading thread a daemon, so it won't block
# main program from exiting
self._reader.setDaemon(True)
self._reader.start()

def close(self):
self.ser.close()

def sendPacket(self, Command=0x00, Data = None):
# format a packet list from input data
packet = [Command, self._TX_count, len(Data)] + Data
# append checksum
packet.append(self._checksum(packet))
# convert to string format -- all data better be
# 0x00 - 0xFF
output = "".join([chr(x) for x in packet])
self._ser.write(output)
# increment output counter
self._TX_count += 1 & 0xFF

# MAIN PROGRAM STARTS HERE
fdata = open(DATA_FID, "r")

# create response transfer queue, and serial port handler instance
myQ = Queue.Queue()
myDevice = DeviceHandler(port = 0, rate = 9600, queue = myQ)

for ln in fdata:
# NOTE: no TIMING of command output is performed, they
# go out as fast as the response queue can be emptied
# reset response data array
temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

# extract all responses that have been received up to now
# note: this is NOT a loop until empty, only for whatever
# was available at the start of this pass
for i in range(myQ.qsize()):
resp = myQ.get_nowait()
if type(resp) is types.StringType:
print "Bad response packet: %s" % resp
elif resp[2] != 6 or resp[0] != 0x70:
print "Unexpected response:"
print " Code = %s\tCount = %s\tLength = %s" % (resp[0],
resp[1],
resp[2])
print " Data = ",
for j in range(resp[2]):
print resp[j + 3],
print "\tChecksum = %s" % resp[resp[2] +3]
else:
# capture data field
temp1.append(resp[3])
temp2.append(resp[4])
pyra1.append(resp[5])
pyra2.append(resp[6])
voltage.append(resp[7])
current.append(resp[8])
# display current data
print "Code = %s\tcount = %s\tLength = %s" % (resp[0],
resp[1],
resp[2])
print "temp1 = %s\ttemp2 = %s" % (resp[3], resp[4])
print "pyra1 = %s\tpyra2 = %s" % (resp[5], resp[6])
print "voltage = %s\tcurrent = %s" % (resp[7], resp[8])
print "\tchecksum = %s" % resp[9]

# process one input data value
dvalue = int(ln)
(d_high, d_low) = divmod(dvalue, 0x100)

# send the packet
myDevice.sendPacket(Command = 0x67, Data = [d_high, d_low])

#what do you want to do with the arrays that built up, as they get
#reset on the next loop pass
print "temp1", temp1
print "temp2", temp2
print "pyra1", pyra1
print "pyra2", pyra2
print "voltage", voltage
print "current", current

# end of input file, close file and exit
# NOTE: does not wait for response data to catch up
fdata.close()
myDevice.close()

-=-=-=-=-=-=-=-=-=-=-

Explore that and see if you can understand the modularization
(minimal) and processing logic.

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Jul 18 '05 #34

P: n/a
a simple question regarding threading and timer:

if i put my timer control inside the thread, will the thread be exited
every time there is a timer event???

please help...

def someThreadHere()
...
someTimer.start(3000)
....

def someTimerEvent()
.....

On Wed, 16 Mar 2005 07:38:09 GMT, Dennis Lee Bieber
<wl*****@ix.netcom.com> wrote:
On Wed, 16 Mar 2005 09:47:01 +0800, jrlen balane <nb******@gmail.com>
declaimed the following in comp.lang.python:
please post your suggestions? please ...

Since we don't have your hardware, nor have you been able supply
the formal documentation of the protocol in use, all we can do is
comment on coding styles and obvious errors in the code... If there is
an flaw in the implementation of the protocol, we have no way to tell.

import sys
import serial
import sys, os
import serial
How about cleaning that up... You've imported serial twice, and
sys twice.
data_file = open('C:/Documents and Settings/nyer/Desktop/IRRADIANCE.txt', 'r')
data = data_file.readlines()

def process(list_of_lines):
data_points = []
for line in list_of_lines:
data_points.append(int(line))
return data_points

irradiance = process(data)
Well, this is legal, though confusing to stuff a function
definition between lines of the main program. Common is to put the
"def"s after the "imports" (though defining "constants" may be okay in
there)

If "process" is only used once, it might not even be worth the
"def"...

ser = serial.Serial()
ser.baudrate = 9600
ser.port = 0
ser Delete that -- you've been told that it is meaningless for days
now... If you don't want to take advice, why ask?

ser.open()
tx_command = 67
tx_no_databyte = 2
tx_message_no = 1
tx_len = len (irradiance)

for j in range (tx_len) :
start_time = time.time()

temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

current_time = time.time()

while( current_time >= start_time + 300):
If current time is < start+300, the entire loop will be skipped
-- a condition that is quite likely to happen unless you have a /very/
slow machine.
data_hi, data_lo = divmod(irradiance[j], 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no
+ tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no,
tx_no_databyte, data_lo, data_hi, tx_checksum))

rx_data = ser.read(19)
rx_len = len(rx_data)
byte = [ord(x) for x in rx_data]

if rx_len < 10:
#print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10])
& 0xff == 0:
#print byte[k:k+10]

temp1.append(byte[k+3])
temp2.append(byte[k+4])
pyra1.append(byte[k+5])
pyra2.append(byte[k+6])
voltage.append(byte[k+7])
current.append(byte[k+8])
print temp1, temp2, pyra1, pyra2, voltage, current
All these are lists, do you really mean to print the entire list
each time, or only the most recent data value?
current_time = time.time()

while theres no error in the output, there is also no response from
the hardware or maybe communication is off.

could somebody out there help me.
by the way, here is a working code: though here the data to be
transmitted is just incrementing and not read from a text file:

import serial
import string
import time
from struct import *
import os

ser = serial.Serial()

ser.baudrate = 9600
ser.port = 0
ser.timeout = 1
ser

ser.open()
tx_command = 67
tx_message_no = 1
tx_no_databyte = 2
item=10000
for item in range(10000, 30001, 10):

data_hi, data_lo = divmod(item, 0x100)
tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no +
tx_no_databyte) & 0xff
ser.write(pack('6B', tx_command, tx_message_no, tx_no_databyte,
data_lo, data_hi, tx_checksum))
#print tx_command, tx_message_no, tx_total_data, data_lo, data_hi,
tx_checksum
rx_data = ser.read(19)
rx_len = len(rx_data)
#print 'rx_len', rx_len
byte = [ord(x) for x in rx_data]
#print 'received', byte

if rx_len < 10:
print 'it is not pumping data out as fast as we assumed'
sys.exit(1)

for k in range (rx_len-9):
if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
print byte[k:k+10]
===================================
outputs:
[70, 2, 6, 54, 197, 253, 230, 231, 211, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
[70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
[70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
...
...


And please trim... You don't need to quote the same text over
and over... We've all seen it by now, or can retrieve it using the
message headers.

-=-=-=-=-=-=-=-=-=-=-=-=-
"""
EVERYTHING THAT FOLLOWS IS THE RESULT OF "FREE ASSOCIATION"
THINKING. NONE OF IT HAS BEEN TESTED FOR CORRECTNESS OF
SYNTAX OR SEMANTICS -- IT SHOULD BEST BE CONSIDERED PSEUDO-
CODE, GIVING A GUIDELINE FROM WHICH TO PROCEED WITH REAL
DEVELOPMENT
"""

import serial #I don't have this, and don't have your hardware,
#so this is all guesswork, and untested
import os
import sys
import time
import threading
import Queue

DATA_FID = r"C:\\Documents and Settings\\nyer\\Desktop\\IRRADIANCE.txt"
#I definitely don't have a "nyer" user <G>

class DeviceHandler(object):
def _checksum(packet):
# compute checksum from packet (which should be a list)
return -sum(packet) & 0xFF

def _Reader(self):
# worker code for the reader /thread/, continuous
# loop, reading response packets and putting them
# (or some error message string) onto the queue
while 1:
# accept first three as response code, message count
# and data length
response = ord(self._ser.read(1))
count = ord(self._ser.read(1))
length = ord(self._ser.read(1))
# get the data bytes
data = []
for x in range(length):
data.append(ord(self._ser.read(1)))
# get the message checksum
check = ord(self._ser.read(1))
# format it all as a packet list
packet = [response, count, length] + data
packet = packet.append(check)
# check for out of sequence packet
if count != self._RX_count:
# notify via queue, then reset expected counter
self._queue.put("Receive packet number is out of
sequence")
self._RX_count = count
# confirm checksome and notify if needed
if _checksum(packet) != 0:
self._queue.put("Receive packet checksum is invalid")
# put the packet, regardless of validity, onto queu
self._queue.put(packet)
self._RX_count += 1 & 0xFF #quick & dirty modulo 256

def __init__(self, port, rate, queue):
# initialize handler instance
self._TX_count = 0
self._RX_count = 0
self._ser = serial.Serial()
self._ser.port = port
self._ser.baudrate = rate
self._ser.open()
self._queue = queue
self._reader = threading.Thread(target=self._Reader())
# make the reading thread a daemon, so it won't block
# main program from exiting
self._reader.setDaemon(True)
self._reader.start()

def close(self):
self.ser.close()

def sendPacket(self, Command=0x00, Data = None):
# format a packet list from input data
packet = [Command, self._TX_count, len(Data)] + Data
# append checksum
packet.append(self._checksum(packet))
# convert to string format -- all data better be
# 0x00 - 0xFF
output = "".join([chr(x) for x in packet])
self._ser.write(output)
# increment output counter
self._TX_count += 1 & 0xFF

# MAIN PROGRAM STARTS HERE
fdata = open(DATA_FID, "r")

# create response transfer queue, and serial port handler instance
myQ = Queue.Queue()
myDevice = DeviceHandler(port = 0, rate = 9600, queue = myQ)

for ln in fdata:
# NOTE: no TIMING of command output is performed, they
# go out as fast as the response queue can be emptied
# reset response data array
temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

# extract all responses that have been received up to now
# note: this is NOT a loop until empty, only for whatever
# was available at the start of this pass
for i in range(myQ.qsize()):
resp = myQ.get_nowait()
if type(resp) is types.StringType:
print "Bad response packet: %s" % resp
elif resp[2] != 6 or resp[0] != 0x70:
print "Unexpected response:"
print " Code = %s\tCount = %s\tLength = %s" % (resp[0],
resp[1],
resp[2])
print " Data = ",
for j in range(resp[2]):
print resp[j + 3],
print "\tChecksum = %s" % resp[resp[2] +3]
else:
# capture data field
temp1.append(resp[3])
temp2.append(resp[4])
pyra1.append(resp[5])
pyra2.append(resp[6])
voltage.append(resp[7])
current.append(resp[8])
# display current data
print "Code = %s\tcount = %s\tLength = %s" % (resp[0],
resp[1],
resp[2])
print "temp1 = %s\ttemp2 = %s" % (resp[3], resp[4])
print "pyra1 = %s\tpyra2 = %s" % (resp[5], resp[6])
print "voltage = %s\tcurrent = %s" % (resp[7], resp[8])
print "\tchecksum = %s" % resp[9]

# process one input data value
dvalue = int(ln)
(d_high, d_low) = divmod(dvalue, 0x100)

# send the packet
myDevice.sendPacket(Command = 0x67, Data = [d_high, d_low])

#what do you want to do with the arrays that built up, as they get
#reset on the next loop pass
print "temp1", temp1
print "temp2", temp2
print "pyra1", pyra1
print "pyra2", pyra2
print "voltage", voltage
print "current", current

# end of input file, close file and exit
# NOTE: does not wait for response data to catch up
fdata.close()
myDevice.close()

-=-=-=-=-=-=-=-=-=-=-

Explore that and see if you can understand the modularization
(minimal) and processing logic.

--
================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #35

P: n/a
hi! could anyone give their input on my previous post about timer and
threading...]
pleaseee...

my program seemed to just run first the thread then when it encounters
error on the thread that's the time that other part of the program got
the chance to be executed
even the timer even is not executed while the thread is running
On Thu, 31 Mar 2005 05:39:11 +0800, jrlen balane <nb******@gmail.com> wrote:
a simple question regarding threading and timer:

if i put my timer control inside the thread, will the thread be exited
every time there is a timer event???

please help...

def someThreadHere()
...
someTimer.start(3000)
....

def someTimerEvent()
.....

On Wed, 16 Mar 2005 07:38:09 GMT, Dennis Lee Bieber
<wl*****@ix.netcom.com> wrote:
On Wed, 16 Mar 2005 09:47:01 +0800, jrlen balane <nb******@gmail.com>
declaimed the following in comp.lang.python:
please post your suggestions? please ...

Since we don't have your hardware, nor have you been able supply
the formal documentation of the protocol in use, all we can do is
comment on coding styles and obvious errors in the code... If there is
an flaw in the implementation of the protocol, we have no way to tell.

> import sys
> import serial
> import sys, os
> import serial


How about cleaning that up... You've imported serial twice, and
sys twice.
> data_file = open('C:/Documents and Settings/nyer/Desktop/IRRADIANCE.txt', 'r')
> data = data_file.readlines()
>
> def process(list_of_lines):
> data_points = []
> for line in list_of_lines:
> data_points.append(int(line))
> return data_points
>
> irradiance = process(data)


Well, this is legal, though confusing to stuff a function
definition between lines of the main program. Common is to put the
"def"s after the "imports" (though defining "constants" may be okay in
there)

If "process" is only used once, it might not even be worth the
"def"...
>
> ser = serial.Serial()
> ser.baudrate = 9600
> ser.port = 0
> ser

Delete that -- you've been told that it is meaningless for days
now... If you don't want to take advice, why ask?
>
> ser.open()
> tx_command = 67
> tx_no_databyte = 2
> tx_message_no = 1
> tx_len = len (irradiance)
>
> for j in range (tx_len) :
> start_time = time.time()
>
> temp1 = []
> temp2 = []
> pyra1 = []
> pyra2 = []
> voltage = []
> current = []
>
> current_time = time.time()
>
> while( current_time >= start_time + 300):
>

If current time is < start+300, the entire loop will be skipped
-- a condition that is quite likely to happen unless you have a /very/
slow machine.
> data_hi, data_lo = divmod(irradiance[j], 0x100)
> tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no
> + tx_no_databyte) & 0xff
> ser.write(pack('6B', tx_command, tx_message_no,
> tx_no_databyte, data_lo, data_hi, tx_checksum))
>
> rx_data = ser.read(19)
> rx_len = len(rx_data)
> byte = [ord(x) for x in rx_data]
>
> if rx_len < 10:
> #print 'it is not pumping data out as fast as we assumed'
> sys.exit(1)
>
> for k in range (rx_len-9):
> if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10])
> & 0xff == 0:
> #print byte[k:k+10]
>
> temp1.append(byte[k+3])
> temp2.append(byte[k+4])
> pyra1.append(byte[k+5])
> pyra2.append(byte[k+6])
> voltage.append(byte[k+7])
> current.append(byte[k+8])
> print temp1, temp2, pyra1, pyra2, voltage, current
>

All these are lists, do you really mean to print the entire list
each time, or only the most recent data value?
> current_time = time.time()
>
> while theres no error in the output, there is also no response from
> the hardware or maybe communication is off.
>
> could somebody out there help me.
>

> by the way, here is a working code: though here the data to be
> transmitted is just incrementing and not read from a text file:
>
> import serial
> import string
> import time
> from struct import *
> import os
>
> ser = serial.Serial()
>
> ser.baudrate = 9600
> ser.port = 0
> ser.timeout = 1
> ser
>
> ser.open()
> tx_command = 67
> tx_message_no = 1
> tx_no_databyte = 2
> item=10000
> for item in range(10000, 30001, 10):
>
> data_hi, data_lo = divmod(item, 0x100)
> tx_checksum = -(data_hi + data_lo + tx_command + tx_message_no +
> tx_no_databyte) & 0xff
> ser.write(pack('6B', tx_command, tx_message_no, tx_no_databyte,
> data_lo, data_hi, tx_checksum))
> #print tx_command, tx_message_no, tx_total_data, data_lo, data_hi,
> tx_checksum
>
>
> rx_data = ser.read(19)
> rx_len = len(rx_data)
> #print 'rx_len', rx_len
> byte = [ord(x) for x in rx_data]
> #print 'received', byte
>
> if rx_len < 10:
> print 'it is not pumping data out as fast as we assumed'
> sys.exit(1)
>
> for k in range (rx_len-9):
> if byte[k] == 70 and byte [k+2] == 6 and sum(byte[k:k+10]) & 0xff == 0:
> print byte[k:k+10]
> ===================================
> outputs:
> [70, 2, 6, 54, 197, 253, 230, 231, 211, 26]
> [70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
> [70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
> [70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
> [70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
> [70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
> [70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
> [70, 3, 6, 54, 197, 253, 230, 231, 210, 26]
> [70, 3, 6, 54, 197, 253, 230, 231, 211, 25]
> ...
> ...
>


And please trim... You don't need to quote the same text over
and over... We've all seen it by now, or can retrieve it using the
message headers.

-=-=-=-=-=-=-=-=-=-=-=-=-
"""
EVERYTHING THAT FOLLOWS IS THE RESULT OF "FREE ASSOCIATION"
THINKING. NONE OF IT HAS BEEN TESTED FOR CORRECTNESS OF
SYNTAX OR SEMANTICS -- IT SHOULD BEST BE CONSIDERED PSEUDO-
CODE, GIVING A GUIDELINE FROM WHICH TO PROCEED WITH REAL
DEVELOPMENT
"""

import serial #I don't have this, and don't have your hardware,
#so this is all guesswork, and untested
import os
import sys
import time
import threading
import Queue

DATA_FID = r"C:\\Documents and Settings\\nyer\\Desktop\\IRRADIANCE.txt"
#I definitely don't have a "nyer" user <G>

class DeviceHandler(object):
def _checksum(packet):
# compute checksum from packet (which should be a list)
return -sum(packet) & 0xFF

def _Reader(self):
# worker code for the reader /thread/, continuous
# loop, reading response packets and putting them
# (or some error message string) onto the queue
while 1:
# accept first three as response code, message count
# and data length
response = ord(self._ser.read(1))
count = ord(self._ser.read(1))
length = ord(self._ser.read(1))
# get the data bytes
data = []
for x in range(length):
data.append(ord(self._ser.read(1)))
# get the message checksum
check = ord(self._ser.read(1))
# format it all as a packet list
packet = [response, count, length] + data
packet = packet.append(check)
# check for out of sequence packet
if count != self._RX_count:
# notify via queue, then reset expected counter
self._queue.put("Receive packet number is out of
sequence")
self._RX_count = count
# confirm checksome and notify if needed
if _checksum(packet) != 0:
self._queue.put("Receive packet checksum is invalid")
# put the packet, regardless of validity, onto queu
self._queue.put(packet)
self._RX_count += 1 & 0xFF #quick & dirty modulo 256

def __init__(self, port, rate, queue):
# initialize handler instance
self._TX_count = 0
self._RX_count = 0
self._ser = serial.Serial()
self._ser.port = port
self._ser.baudrate = rate
self._ser.open()
self._queue = queue
self._reader = threading.Thread(target=self._Reader())
# make the reading thread a daemon, so it won't block
# main program from exiting
self._reader.setDaemon(True)
self._reader.start()

def close(self):
self.ser.close()

def sendPacket(self, Command=0x00, Data = None):
# format a packet list from input data
packet = [Command, self._TX_count, len(Data)] + Data
# append checksum
packet.append(self._checksum(packet))
# convert to string format -- all data better be
# 0x00 - 0xFF
output = "".join([chr(x) for x in packet])
self._ser.write(output)
# increment output counter
self._TX_count += 1 & 0xFF

# MAIN PROGRAM STARTS HERE
fdata = open(DATA_FID, "r")

# create response transfer queue, and serial port handler instance
myQ = Queue.Queue()
myDevice = DeviceHandler(port = 0, rate = 9600, queue = myQ)

for ln in fdata:
# NOTE: no TIMING of command output is performed, they
# go out as fast as the response queue can be emptied
# reset response data array
temp1 = []
temp2 = []
pyra1 = []
pyra2 = []
voltage = []
current = []

# extract all responses that have been received up to now
# note: this is NOT a loop until empty, only for whatever
# was available at the start of this pass
for i in range(myQ.qsize()):
resp = myQ.get_nowait()
if type(resp) is types.StringType:
print "Bad response packet: %s" % resp
elif resp[2] != 6 or resp[0] != 0x70:
print "Unexpected response:"
print " Code = %s\tCount = %s\tLength = %s" % (resp[0],
resp[1],
resp[2])
print " Data = ",
for j in range(resp[2]):
print resp[j + 3],
print "\tChecksum = %s" % resp[resp[2] +3]
else:
# capture data field
temp1.append(resp[3])
temp2.append(resp[4])
pyra1.append(resp[5])
pyra2.append(resp[6])
voltage.append(resp[7])
current.append(resp[8])
# display current data
print "Code = %s\tcount = %s\tLength = %s" % (resp[0],
resp[1],
resp[2])
print "temp1 = %s\ttemp2 = %s" % (resp[3], resp[4])
print "pyra1 = %s\tpyra2 = %s" % (resp[5], resp[6])
print "voltage = %s\tcurrent = %s" % (resp[7], resp[8])
print "\tchecksum = %s" % resp[9]

# process one input data value
dvalue = int(ln)
(d_high, d_low) = divmod(dvalue, 0x100)

# send the packet
myDevice.sendPacket(Command = 0x67, Data = [d_high, d_low])

#what do you want to do with the arrays that built up, as they get
#reset on the next loop pass
print "temp1", temp1
print "temp2", temp2
print "pyra1", pyra1
print "pyra2", pyra2
print "voltage", voltage
print "current", current

# end of input file, close file and exit
# NOTE: does not wait for response data to catch up
fdata.close()
myDevice.close()

-=-=-=-=-=-=-=-=-=-=-

Explore that and see if you can understand the modularization
(minimal) and processing logic.

--
================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #36

P: n/a
jrlen balane wrote:
hi! could anyone give their input on my previous post about timer and
threading...]
pleaseee...
A few bits of unrequested advice which might help you get
more and better responses (though the ones you have got
in the past already appear to be above and beyond the call
of duty, given your apparent lack of actually following
advice you are given):

1. It's most annoying that you are not taking even a bit
of time to "prune" the useless quoted material from your
messages (notice how I've done it in this one). From
a netiquette point of view, that's considered rude and reduces
the level of respect you will be shown.

1.5. Don't "top-post"! That's when you put your reply
*above* the material you are replying to, and it's very
frustrating and against widely followed conventions.
Take the time to prune quoted material to the minimum,
then add your comments inline as I've done in this
message, not all at the top.

1.6. Always start a new thread when you have a new request.
One reason you might not have got replies to this latest
request yet is that you posted it as a followup to the
previous thread. Many people have already done their
version of "hitting the 'k' key" and killed the thread,
meaning they won't see any additional messages that are
posted in reply to existing messages in this thread.

2. Pay closer attention to the requests you get from those
trying to help you. For example, you were asked a number
of times to clean up some of the unnecessary or confusing
or redundant code in the programs you were posting, but
you never bothered. Here it looks like you are not willing
to make an effort.

3. Trust that in this newsgroup, more than perhaps almost
any other, if you don't get a reply it's not because nobody
read your message, and begging will just annoy people. In
any event, be patient, then assume that your request was
inadequate in some way and don't just try reposting, try
instead to figure out what you did wrong and when you post
again, *improve* your request in some way. It might help
if you study and follow some of the advice in the essay at
http://www.catb.org/~esr/faqs/smart-questions.html .
my program seemed to just run first the thread then when it encounters
error on the thread that's the time that other part of the program got
the chance to be executed
even the timer even is not executed while the thread is running


I suspect the reason no one replied (and here I really hope
you'll refer to item 2. above), is that you didn't post
anything resembling working code, and out of context it's
unclear what you are talking about. There are dozens of
ways of interpreting your code and your request, and it's
impossible to guess exactly which you meant.

For example, it seems like you might have meant to say
"will the thread be executed" instead of "exited", but
I'm not sure.

And you don't show the imports you used, so nobody can
tell for sure whether you are referring to the "threading"
module and the "timer" module, or just to threading
and maybe timers in general. wxPython, for example,
also has a timer object.

More importantly, your code can't be executed, so
we're just shooting in the dark if we try to figure
out how you are getting "someTimerEvent" to execute,
if indeed it is a function. The "def" statements
don't have colons after them, so we're not even sure
you are asking about how to do something, or perhaps
you have code that is just not compiling because it
is syntactically incorrect.

In a nutshell, do the most you possibly can to help
us out, and you'll get timely and effective help.
Otherwise you may get silence, and "pleaseee" will
just sound like whining.

Please take this in the helpful spirit in which it
was intended.

-Peter
Jul 18 '05 #37

P: n/a
On Thu, 31 Mar 2005 10:56:07 -0500, Peter Hansen <pe***@engcorp.com>
declaimed the following in comp.lang.python:
jrlen balane wrote:
hi! could anyone give their input on my previous post about timer and
threading...]
pleaseee...

<snip>
1. It's most annoying that you are not taking even a bit
of time to "prune" the useless quoted material from your
messages (notice how I've done it in this one). From
a netiquette point of view, that's considered rude and reduces
the level of respect you will be shown.
I didn't even notice the posts myself, as I've got size filters
in place -- from when we were getting a lot of spam posting of binaries
and HTML; these posts were too large for my filters to let in. (Okay,
they /were/ also sent to my email address; I didn't reply there as the
CC: to the Python list was also visible -- I'd rather have handled the
stuff here)
1.6. Always start a new thread when you have a new request.
One reason you might not have got replies to this latest
request yet is that you posted it as a followup to the
Especially for a thread that is two weeks stale... <G>


More importantly, your code can't be executed, so
we're just shooting in the dark if we try to figure
out how you are getting "someTimerEvent" to execute,
if indeed it is a function. The "def" statements
don't have colons after them, so we're not even sure
you are asking about how to do something, or perhaps
you have code that is just not compiling because it
is syntactically incorrect.
To add to the pseudo-code (since there isn't enough there to
even code a test case, assuming one corrects the : matter), assuming it
is the "regular" timing module, the time /delay/ is NOT an argument of
the start() method, but rather of the instance creation. As I recall,
they are one-shots and not repeating timers. From a quick read, a timer
is, itself, a thread -- at the simplest level then, I would conclude
that a time is nothing more than a thread with the pseudo-code of:

sleep(delay)
eventFunction()
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Jul 18 '05 #38

P: n/a
i would just like to apologize for my mistake, rest assured everything
was taken in helpful way.
On Thu, 31 Mar 2005 17:40:06 GMT, Dennis Lee Bieber
<wl*****@ix.netcom.com> wrote:
On Thu, 31 Mar 2005 10:56:07 -0500, Peter Hansen <pe***@engcorp.com>
declaimed the following in comp.lang.python:
jrlen balane wrote:
hi! could anyone give their input on my previous post about timer and
threading...]
pleaseee...

<snip>

1. It's most annoying that you are not taking even a bit
of time to "prune" the useless quoted material from your
messages (notice how I've done it in this one). From
a netiquette point of view, that's considered rude and reduces
the level of respect you will be shown.


I didn't even notice the posts myself, as I've got size filters
in place -- from when we were getting a lot of spam posting of binaries
and HTML; these posts were too large for my filters to let in. (Okay,
they /were/ also sent to my email address; I didn't reply there as the
CC: to the Python list was also visible -- I'd rather have handled the
stuff here)
1.6. Always start a new thread when you have a new request.
One reason you might not have got replies to this latest
request yet is that you posted it as a followup to the


Especially for a thread that is two weeks stale... <G>


More importantly, your code can't be executed, so
we're just shooting in the dark if we try to figure
out how you are getting "someTimerEvent" to execute,
if indeed it is a function. The "def" statements
don't have colons after them, so we're not even sure
you are asking about how to do something, or perhaps
you have code that is just not compiling because it
is syntactically incorrect.

To add to the pseudo-code (since there isn't enough there to
even code a test case, assuming one corrects the : matter), assuming it
is the "regular" timing module, the time /delay/ is NOT an argument of
the start() method, but rather of the instance creation. As I recall,
they are one-shots and not repeating timers. From a quick read, a timer
is, itself, a thread -- at the simplest level then, I would conclude
that a time is nothing more than a thread with the pseudo-code of:

sleep(delay)
eventFunction()

--
> ================================================== ============ <
> wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wu******@dm.net | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

--
http://mail.python.org/mailman/listinfo/python-list

Jul 18 '05 #39

This discussion thread is closed

Replies have been disabled for this discussion.