Logged in users > User Diaries
Monitoring the Tristar TS-xx with a PI.
SparWeb:
Well, I should be using Py-modbus shouldn't I? It would certainly be easier than building the same commands from Py-serial.
Thanks for posting the code! It's full of ideas that will help me, perhaps even rescue my abandoned Python code.
Simen:
Sparweb;
Do note that you can only use Pymodbus when talking to devices that speaks the modbus protocol. :)
I am also a Basic guy; been that since mid-80's. ;) When they thought that Object Oriented Programming (OOP) was a good way to go, i fell off the ride... I do see the benefits of OOP, but i still struggle with it... ;)
For interested; here's the python code i used to read data from the Picaxe;
--- Code: ---import serial
import time
ser = serial.Serial("/dev/ttyUSB0", 4800, xonxoff=False, rtscts=False, dsrdtr=False, timeout=6)
ser.open()
a = 2
counter = 0
ser.flushInput()
while a > 1:
tekst= ser.readline()
out = str(tekst)
out = out.replace("b'", "")
out = out.replace("\\r\\n'", "")
fil = open('/mnt/dumpdata.txt', 'w')
fil.write(out)
ser.flushInput()
fil.close()
counter += 1
if counter == 24:
currtime = time.ctime()
log = open('/mnt/dumplog.txt', 'a')
outlog = str(currtime) + ' ' + out + '\n'
log.write(outlog)
log.close()
counter = 0
--- End code ---
No remarks in the code though, but that code are my work, so ask... ;)
bob golding:
--- Quote from: ghurd on April 06, 2013, 07:33:00 PM ---
--- Quote from: OperaHouse on April 06, 2013, 06:44:39 PM ---I think a lot of people feel cosmic angst over that battery condition. That condition is a myth reserved for backup systems that hardly get used. Unless the generating side is overly designed a lot of us don't get much out of bulk charge.
--- End quote ---
I 'THINK' I agree with that.
With PV or wind, often can not get there in a day with available resources anyway.
What is 'perfect on paper' is not always best, or possible with available resources.
G-
--- End quote ---
as i said in an earlier post, after 4/5 years apart from reduced output in the winter due to the cold conditions the battery bank is in i haven't noticed any significant degradation in my bank. of course since i installed it lots has changed anyway. i have rebuilt the wind turbine with fewer magnets as they have disappeared due to rust. changed the air gap changed the blades,and last year added 500 watts of solar.
my loads have also reduced due to lower power lighting as well. the only way i can tell the health of the batteries is to test them with a hydrometer to check they are all in more or less the same state. since i have added the solar the tri star controller seems to stay in the charging state,red and yellow lights on, a lot more that when i just had the wind turbine. this makes sense as the charging is more even. but trying to measure all this is not easy, hence the interest in simens data logger.
think as long as you don't let the water level get too low there is not much to worry about with those batteries,.
as long as you have some way of giving an equalization charge every now and again. living off grid without a backup could be worry though. i don't think they like just being charged at low current constantly without a boost every now and again. the rolls manual says they should have a eq charge monthly. i do mine around every 6 weeks or so. i have a 50 amp charger running off a generator and boost charge them for around 6 hours. even then to get the dump load to kick in takes along time. as i have 2 banks of 24 volts i sometimes just charge the banks separably if the batteries have got low enough to trip the inverter. this doent happen much with bothe the wind turbine and solar both working. usually happens when we get days and days of sea fog no sun no wind.
SparWeb:
Simen,
More code: Thanks again.
I see a pattern in what you're doing already, and if there's any knowledge you can share on the subject of USB serial communications versus COM ports I'd appreciate anything you can tell me.
When I was attempting to read about it on StackOverflow or from the Python tutorials, I just got lost. They were not talking to my level of knowledge.
All of the Python programs I've tried to write used this to open the serial port:
--- Code: --- ser1 = serial.Serial(port='COM5',baudrate=115200, timeout=0)
ser1.flush()
line = ser1.readline() # Read one line from Serial port (accelerometer)
ser1.close
--- End code ---
This is an excerpt of code, with a lot of other business stripped out, just to show you just the commands concerned with the serial port. The device connected to the COM 5 port is sending numbers every 1/2 second, always in hexadecimal format, always with a carriage return between them. I've checked the code a hundred times and the hex to decimal conversion is correct, and there are even provisions to strip extra characters in case the data stream has noise or is interrupted.
Is there anything you can see there that would cause the data read from the port to be corrupted? Half the time when I run the program it works and half the time it fails. This is where I was getting frustrated.
BTW: I now have my programs working FLAWLESSLY in BASIC today, after only a few days of programming, and starting from scratch too.
No pressure on you to solve this thing I have against python, and if you throw your hands up, then welcome to the club!
Simen:
I agree with you on the pyserial documentation; they threw out examples without explaining properly what happens etc. Not nice to beginners... ???
Instead of 'serl.flush()', try 'serl.flushInput()'. flushInput() clears the comports inputbuffer; making sure the data you read are fresh from the device (flush() doesn't. ;) )
Just for fun; before you try the flushInput(), insert the following code after your 'flush()':
--- Code: ---x = serl.inWaiting()
print("Number of data in queue; " + x)
--- End code ---
Run your program, and then change the flush() to flushInput() to see the difference. :) (The buffer would probably contain a good deal of data if you doesn't use the flushInput(), especially if you do this inside a loop.
That flush()/flushInput() caused me a headache too... ;)
Do you get a complete set of data before it separates them with a carriage return?
The 'readLine()' reads everything from the port until it receives a '\n' (newline)
If \n doesn't terminate a complete dataset, and you know the number of bytes you want to read, you could use 'read([number of bytes])' in blocking mode (timeout = 1 in opening the port). In non-blocking more (timeout = 0), it would just read the specified number of bytes from the buffer.) - (I found the latter one more unstable...)
Edit;
Make sure that the baudrate are correct; 115200 are pretty fast, and devices such as controllers use often lower rates. The Tristar for example, uses 9600 baud; the Picaxe 08M2 use 4800.
Edit2;
with the flushInput(), you might get an incomplete dataset when you read it the first time, but next time should be complete. This would only be a problem if you read the dataset only once, and not continuously. If you need the data only once, you could read the data twice and discard the first set.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version