Logged in users > User Diaries
Monitoring the Tristar TS-xx with a PI.
Bruce S:
Just received the first raspberry pi :) looks interesting.
This post helps too! Glad I'm not the only who got lost in the python world!
Basic, I can work with
SparWeb:
Simen,
Thanks for all the advice.
I will try the flushinput() to start. You would think "flush()" alone would flush the serial buffer if it's appended to "ser1.flush()", but this is Python after all... some eager beaver wrote a separate function for that.
I've encountered the process of "read it once, throw that away, read it a second time". That is a technique recommended in the PICAXE manual when using readADC commands. Once again our experience overlaps, but you've made discoveries that I haven't.
The device on the COM port is an Arduino, so yes, it's zipping along at 115200 baud. Because I'm using an Arduino, I have control over the format of the data it sends out. Currently I have it sending the 3 values of acceleration from an accelerometer, x, y, z (of course). The values are separated by commas and followed by a CR. I was able to write code to parse that. ...when the data actually comes in without errors, the program could parse it, I should say. When errors crept in, it became harder to deal with the mess. I'd much rather work on having clean input data!
I also have a device that I want to make work in conjunction with the Arduino, bringing the data into two serial ports at the same time. It also operates at 115200 baud, and it's the one sending in the hex formatted data. Making the two devices feed data into the computer simultaneously is the ultimate goal.
Last night I wrote a bunch more BASIC code for the alternate program, and got more of the user interface to work. That was a much more rewarding process, where I read the documentation (JBasic, if you're curious) organized the commands that I'd need to format the new graphics window, and the controls to go into it, layed them out in the existing program (which is already doing the serial read inputs and calculations), and bang: it worked on THE FIRST TRY. I went to bed early last night, feeling very smug.
I'll get back to Python, I promise, if only to show it won't win over me.
(It will probably perform much better than a free BASIC compiler will, if I finish the code)
A little inspiration from you is probably all I need.
-Steve
PS a teacher in my son's elementary school is experimenting with a Raspberry PI. His current project is to give it control over a remote control car. He and I snooped on the RC signals with my pocket-oscilloscope, and he's now able to transmit signals directly from the PI, which he's equipped with a small antenna. Later he wants to try lots of things like pre-programmed courses etc.
Simen:
The pyserial documentation are a bit fuzzy for us novices when it explain flushInput and flush; the flushinput flushes the serial buffer, while the flush command flushes 'file-like objects'. I think the 'readline()' are a file-like object? So, not the same as the serial input buffer.
Regarding the baud speed; when sending data at 115200 baud, there's a greater chance for errors creeping into the datastream, due to noise/interference from the environment through the cable etc. If you are plagued with errors/noise, and have control over the sending unit; try to lower the baudrate. Since you send only a few bytes of data, a lower speed at, let's say 19200 would still give you the data fast enough to receive and process the data, and be ready for next set of data.
If Jbasic does the job for you; why not stick to it? :) I chose Python because the full environment was already installed in the Pi, and i wanted to get a fingernail inside a new language. ;) My 'old' language are Clarion's Basic; Clarion is a database oriented RAD tool. :)
My brother are a professional programmer, and he uses whatever language that suits the job; often mixing 4-5 different langages in one job/program. I'm a bit jealous of him about that. :P
Simen:
I suddenly saw the need to add some error-checking in my code... :o
Since the script writes the data received from the Tristar to a file in a folder which is mapped to another computer, there's a weakness if the network connection fails. The script would just stop and exit if there was an error writing the files.
The Pi are connected to a switch which get its power from a small 150W inverter, and that inverter cuts the power if the voltage in are over 15.1V, which happens now and then here, due to temperature compensated charging and equalizing.
So, i found the 'try:' - 'except:' - 'else:' methods useful.
Here's the original codepiece without the error checking.:
--- Code: --- fil = open('/mnt/dumpdata.txt', 'w')
fil.write(out)
fil.close()
counter += 1
--- End code ---
And here are the same, but with error checking - and logging...
--- Code: --- try:
fil = open('/mnt/dumpdata.txt', 'w')
fil.write(out)
except IOError, Argument:
tid = time.ctime()
Err = tid + " *** Could not write to DumpDATA.txt: " + str(Argument)
ErrLog = open('./errorlog', 'a')
ErrLog.write(Err)
ErrLog.close()
else:
fil.close()
counter += 1
--- End code ---
The code traps the error, and adds an entry into a local 'errorlog' file, so one can see what the error was remotely without having a screen connected.
Here's an example of an error written in the 'errorlog' file:
--- Code: ---Thu Apr 11 10:12:50 2013 *** Could not write to DumpDATA.txt: [Errno 112] Host is down: '/mnt/dumpdata.txt'
--- End code ---
Just wanted you to know... ;)
SparWeb:
Not dealing with errors is the #1 problem that programs get into trouble, so good thing you've found a way to deal with shut-downs.
Last night I discovered that my code needs a contingency for the rare event that the load goes negative.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version