Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / One Wire Weather Station project (open source)

Author
Message
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 20th Nov 2006 15:36
Link
If you had the time how are things progressing?

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 26th Nov 2006 00:47 Edited at: 26th Nov 2006 20:55
Link
Sorry for the delay. It has been a very busy time for me, with no signs of slowing.

Anyway, I encountered my first bit of ugliness with the connection. I cannot seem to start, end and restart a session with the same session handle. I am beginning to believe that is by design, and I would need to unload the dll to get the result I am seeking. I had thought that the flags would solve that, but...I do not see that flags parameter doing anything at all.

So then, I rewrote (actually, reordered) the code and now it works fine. I also ran into some trouble using make memory in the EnumerateDevices function. It seems to me like I was creating a memory leak, even though I used delete memory. I went ahead and used the memory block that I put into the device UDT for that purpose. It is also working fine now.

Initially, I tried to write this like an ethernet application, and that is not really in keeping with the 1Wire philosophy. (Then again, I do not feel that the current code meets that criterion perfectly, either.) One thing about it that is important to note is that the power to the devices is also on that 1 wire. Alot of communications will lower the available power to the devices. They store it in capacitors called charge pumps. It is interesting to note that Maxim is the company that pioneered that part of it. They made line driver/receiver chips back in "the day." Dallas started off by embedding lithium batteries in PC clocks mostly. The pairing is a natural one, I think.

The TMFirst/TMNext approach has a rather unpleasant side-effect. When the last device is found, the next call to TMNext returns 0, which works nicely to end the while loop in EnumerateDevices, but it is supposed to reset the search algorithm so that the first device answers up again the next go round. I can't make that work yet. I tried manually resetting the search, the network, all of it. This is the way it works for me at this time, and it works fine for my purposes. I had to write code so that I did not have to dump the device array each time. That way, their information is always available. Otherwise, those pretty high-level functions would look very ugly, and be quite useless some of the time. I actually had a rather elegant set of functions designed for using the devices, but I was not able to implement it the way I envisioned. I am compromising with good results so far.

The next step is to verify that I am finding your devices properly. Notice now that I look at the DeviceFamily to further qualify what the device has available. Since I do not have the same devices, I had to get the read memory working for my DS1994. That code is reading a 5 byte counter that is a clock. It is located at memory location 0x0202 and that is what the DoDeviceMemoryCMD1 function does. The standard method of reading/writing memory is a TMBlockStream command, which consists of a single byte command, two byte address, and then a buffer for the data. I am writing more of these routines tonight and tomorrow. What I am moving towards is an ability to recognize what devices are present, program those that are capable of being programmed, and also to collect the data in a preprogrammed fashion, with some alarms and also external notification and communication. I wrote a similar system for my former employer using their devices and ethernet/rs-232. I foresee a GUI that will allow a visual drag and drop programmability, and also...I would like to work to create a way to tie GUI elements to 1Wire data. Your compass will do nicely for starters. If I know the format and purpose of the data, and the same information about the GUI element, it is a cinch to program the data glue with what we are developing now.

Okay, I have some work to do, and then it is my required 2 hours of "Cops", then back to work straight away.

EDIT: I got bitten by the editor when I posted that code. Sorry, it will crash...it still used the make memory. I have replaced the code today with the correct version. I am glad that I use many backups!
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 26th Nov 2006 22:37
Link
I see you found sometime to do a little coding, what with all your activities going on, plus the next one in about 24ish days time (Don't panic..) well done.

looking a lot easier to place code in it, like your new method of function Get1WireNetworkxxxx should make it a lot simpler write or rewrite.

code works ok this end.

cheers till next post.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 3rd Jan 2007 05:29
Link
just keeping alive to save starting another one

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 20th Jan 2007 04:39 Edited at: 20th Jan 2007 04:45
Link
First, the bad news...this is not even Y2K-compliant yet, but I am getting there, bear with me. Next, this version is a little frustrating to work with owing to the stupid new thingy I did, which was to load up WinSock and touch the Internet...what a mess! (But I don't want to spoil your surprise too much, let me bore you a little first.)

About two weeks into this experiment, I sorely missed my printer...but I trudged on, scrolling and taking copious notes on various scaps of paper which I promptly lost. No matter, things went well and I decided that I could continue for a bit coding from the hip in the same fashion. Then, I got a little loose with the Windows DLLs and lost my mind. I decided to synchronize the whole thing with atomic clocks. Fabulous idea, but...the sockets are (in this particular case, anyway) blocking sockets, which has the nasty practical implication that they will hang the program at times. Oh, and let me tell you that your firewall will cause you a lot of grief if, like me...you cannot tell it to ignore your repeated recompiling, and running it the way that I do! The solution, and in fact, the way I should have proceeded in the first place, is to simply (!) put all of this stuff into a user DLL, which allows non-blocking sockets, access to the 1-Wire, and ability to show up in DBPro as a complete communications interface in the form of function calls. Simple, right?

I have fabulous news everyone, I am going to split this back into two threads, er...projects. I am posting a really fun version that is only unique from the last in the use of the Windows DLLs. The DBPro code will still have that, but the blocking sockets are not (in my opinion) a good idea, they will lock the program up, because I have not been able to code a robust interface. That requires doing in it in a more controlled environment than I am able to dummy up at this time.

With respect to the Windows DLLs, I will repeat my advice to anyone wanting to explore the use of Windows DLLs in DBPro apps to download the Platform SDK from Microsoft. It is a valuable resource, with loads of samples, and complete documentation of the Windows API. Oh, and its free. The how you do it part is located in the code, way down at the bottom. The structured approach is obviously optional.

The second version will be available in pill form, I mean DLL form. I have a DLL with some useful functions already, which I will use to drive the communications. Its better that way, because access to all communications is possible, and the bridge to DBPro is already in place in my DLL project. Another thing I will stress here is that such a DLL could be used to gain access to the message pump of DBPro, but I am not going to go that route. Another way is to use threads, which I likewise will not be doing in this project. What I will be doing is creating my own timer, and managing all communications within the context of the timer, and other callback functions. This is scalable like threads, but there is not as much overhead. It is simpler to me that way, as well. (So then, it might be all my fault, but it will work to satisfaction, I am certain of that.) Another thing is that Windows likes it that way, too.

As a sidenote, my graphics card died, and when I finally replaced it, my frame rate tripled on this app. I was getting a little embarrassed, but now it idles at about about 150fps, which is nice. (Still, how lame is the GUI on this dog, anyway?)

Which leads me to my next two problems. Namely, I want to add two things, which are timed events and hooks into GUI elements like your compass. I can now print out the entire source, which helps alot. I put alot of Windows constants in there, along with a ton of UDTs, some of which I will never use. The timed events and socket use are what are making me run to the DLL solution, but...I was never far from it in the first place. The time calculations are not in place...I failed on New Years' Eve....bummer. (I was tickled pink, however. I instantly knew what was the matter.) It actually failed early by telling me that it was day -2 of 2007. This happened on December 22, which is very ominous, since I am probably one one billionth Mayan. (I mean our billionth, too, so it really isn't enough to get any benefits from my government.) As I am sure you are aware, everything ends December 22, 2012. The trouble in my code was the fact that I was faking the thing the whole time, and what bit me was the number of leap years since 1970. My version of Sudoku, I guess. You see, a year is 365 1/4 days. A leap year is nearly precisely one day longer. I wrote all this code in the late 90's Y2K panic, and what I wrote then was eventually bullet proof, and all that...but, alas...it is taking me time to repeat every single error in exactly the same fashion, some of those brain cells are gone, people! The code will work for now, but I think I am the only one on the planet that is running that particular routine. For the morbidly curious, it is called jzMakeTimeStrFromSeconds, and is located at line 2697. For those wanting to figure it out, I remember that I used div_t structures to figure out what to do in late February and also what to do about Dec 31.

The code comes with the whole WinSock thingy commented out. To enable it, use line 913 instead of line 915...if you dare, er have an active Internet connection. It is setup to query a time server once a minute. Now, to write the convoluted synchronization scheme. The servers are all US-based. I saw a list of European ones before, but I never returned to get the pertinent data. I believe that Britain has a few, as well. Also, there are some day of the week issues, I think. We will deal with that later.

Anyway, sorry to be gone so long, and to go on so long...so long for now.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 20th Jan 2007 22:56 Edited at: 21st Jan 2007 01:48
Link
Well while you been having some fun with graphic cards and other things I ended up,having to do a system rebuild to stop the system getting to hot and shutting down, which mean I did not back anything up so all I had is lost, apart from what is store on line some where, like getting the driver to talk to the weather station took a good hour as I had not made a good meatle note as to where I found them.

Ho yes this "..." part on each line to join them together how's it done, as I think its stopping me from running the programme keep getting array not exist or script out of bounds.

Also do we now have to update the editor or is it now fixed, as I could not find the site for updating it.

Plus anyone know if XP Pro more stable than MCE XP Pro?

edit
ran an old one that worked ok so must be something else as that was suing the ... line linking.
ran it F7 and its getting lost because it canno find the clock has "NIST Time not initialized." when run, this then makes come up with an array problem.
may find away round it but that whats going on.
edit

edit
found a uk time clock but this did not slove the problem here in is if it might help.


found the line it the one

edit

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 21st Jan 2007 20:53 Edited at: 21st Jan 2007 21:48
Link
EDIT : There are updates to the editor, and also DBPro, too. Check the stickies in IanM's bug forum. That's what I do.

The line concatenation is handled by the Tools menu in the editor, which is not fixed...but stable, predictable and very nearly useable. That's my story, and I'm sticking to it.

...I didn't use the line continuation too much until this project. I don't like it when my line disappears at the right margin, so I have needed it alot on this one.

Line 1499 in my version is where the selection of the time master takes place. You see, I decided to set and read the clock first. I have two devices with clocks. I read the time, and started the routines to make strings from the output. One of my clocks functions alot like the "GetLocalTime" function in Windows. That is when I decided to add the DLLS, just after Thanksgiving. I knew the routines were not complete, but...I did not write robust code to check if any time was available...it is supposed to default to using the Windows call. I forgot to change that line for you...it should read:
this.timeMaster = -1
What is happening here is that the code will make an array of time sources, and the user will be able to select one to synchronize all clocks to...it will be cool when I get it done. (And a pain until I do. Sorry.) I should simply make the Windows call element 0 in the array, and that will fix it. Now, I use -1 to inform the code that it should use the Windows call. I can be a little indecisive like that, and it makes bugs in my 'stream of consciousness' code. That is where my printer helps. I don't desk check long code unless it is for debugging purposes. These types of programs are difficult to debug, to boot. It helps to have another machine monitoring the progress, and also writing to log files helps. That part is coming up soon, too.

My intent has always been to document this as an example of how to proceed in a situation where you need to use DLLs to bring outside functionality to DBPro apps. (Games are great, but the language is alot more capable than that narrow definition makes it seem.) The time code is of two types, BCD and long count of seconds since a start time. Both methods are in widespread use, and the routines are also pretty common. As I said before, they were written a while back, and it is sometimes good to go back and rewrite, I guess. The BCD code is the one I have the most fun with, it reminds me of watching a hand magician at work. (I am going to write the set time routine for it this week.) The BCD code is great for showing really messy assembler code, too. My DLL has some inline assembly in it already. Solving the BCD riddle is a fun exercise, and in C, you can shift and assign at the same time, which makes the code even more obfuscated. Farout.

Thanks for the URL, I am going to find that list of European time servers yet. I seem to recall that Britain's was a separate page. Once you get it going, it does okay. I had it go for a few days just before the -2 day time rift incident. If the server does not respond, it will hang for however long your timeout is on connect. It will fail gracefully after that timeout, and continue. The trouble happens when there is an incomplete read, I think. As you can see, I have alot of low-budget debug code in there. Ewwwww. There are functions in WinSock to examine and change this on a per socket basis, which is a good thing, but...it is apparent to me that we should be using non-blocking sockets in the first place.

A really useful addition to DBPro would be the ability to write a callback function, or to hook into the message handler the way that MFC applications can. (Messages get passed to each of the main classes and whichever one handles it returns TRUE.) That creates a chain, which puts it in series. My use of a timer puts it in parallel...theoretically. Truth is, they are all in series, but Windows manages that for free, and it looks parallel to us. WinSock can be used in a non-blocking polled fashion, and I could do that in the code we have now, but I don't want to do that. What I want is to have the thing manage its own state, and then DBPro apps can do the polling of its state. When used in non-blocking mode, you provide a callback routine, or use a timer. I will do both.

This week, I am getting another machine donated which I will use to assist the effort on this. Focusing on the time and sockets was a bone-headed move on my part, because it complicated the code without providing much extra functionality on the 1-Wire. However, the DoDeviceCommand is going to be the workhorse in this code. I wrote it after reading a white paper regarding using 'Data Sheet Commands'. In fact, they used my DS1994 as the example, so it was really easy to write the read time command. It works like this...you get a memblock large enough to hold the command, and data to be returned, and pass the command, address, and memblock to the function. The data will be returned in the memblock. I think it is adviseable to put some flags in the device UDT so we can tell when the command has returned the data, because it will wait until the next second to send the command, and the data will come in the next second after that. There is a comment in the EnumerateDevices function that foretells that...'Here is where the programmed data collection should start.' The time master/time code is the first example of that type of data collection.

I wanted to get the same devices that you have, and perhaps build a similar weather station here. I am pretty sure that Dallas would sample me the counter, and A/D converter, but I have not asked yet. Otherwise, they are only a few bucks apiece, I could afford them, but most places have a $50 minimum, or add $10 - $20, which does not make sense for someone with no discretionary spending fund. I took on a paper route to finance it, but all that ended up doing was funding an XBox360 purchase. Now, its catch up time on all bills, just like everyone else! At least I don't have to get up at 1AM anymore. My status on buying mad scientist crap is that I am going to get this very interesting communications thingamajig that includes Ethernet, 1-Wire, RS-232, USB, CAN and TINI for about $110. Also, I am anxious to get this $100 CCD camera for my telescope. It has software that allows TCP/IP control of the thing already...it would hook into this, as well. That is probably two months off, at least. I estimate that I can get my telescope, the CCD images, and weather conditions all into one place for about $300. Add a listener socket for port 80, and then you can spew out ready to eat web pages. As a very interesting sidenote, a former coworker of mine stopped into my shop last week. He has servers and domain names already. I had not seen him in over 5 years. Hmmm.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 21st Jan 2007 21:05 Edited at: 21st Jan 2007 21:28
Link
cheers for the update just started a system rebuild again as I got too many bits wrong last time and it started to stop just about every thing from working, so the above might work will see.
now to download dx9.

edit
the =-1 bit work ok cheers but its not showing any thing else is it supposed to?
Plus I was running the other weather programe.

Weird when the other programe is running the ibutton runs but does not show anything which is expected, now if i turn off the other programe and run ibutton it comes back with the send an error report, the only way I am able to run it is F6 mode.
not see why yet?
edit

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 21st Jan 2007 21:58
Link
How much fun are you having? I am so jealous.

Seriously, I don't share the buttons well, and neither does Dallas. I have encountered trouble trying that, and also...a few times I accidentally F5'ed with a copy already running, which is where I feel the editor starts to lose its mind.

Unfortunately for us both, the mighty Chicago Bears are vying for a Super Bowl bid at the moment. Well, maybe only for me.

Yes, the DX9 will probably help that error. That one is pretty pervasive...it will show up on alot of DBPro apps.

I'll be back periodically...My football interest lies in the second game...which is still a few hours off. Cheers.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 22nd Jan 2007 00:07
Link
you'er lucky we only get to see high lights or re live, we have it on pay per view sport network, hopefuly one of our free tv networks will show the final game.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Jan 2007 05:00 Edited at: 23rd Jan 2007 05:06
Link
...I hope you get to see both games complete. Oh, and don't get me started about pay-per-view NFL football...that is supposed to be free for all! by the way, it is almost unbearable around here with all of the gloating and whatnot.

I should have also warned you that, although I set the port to NTP in the array, I only use port 13 right now. Port 13 is called DAYTIME protocol. Its great...you just touch the port on the server, and it spits ASCII back. NTP is actually a UDP port, whereas port 13 is TCP. They are very different. Sorry for the confusion. The servers that I have listed generally respond within a few ticks. My timeout is about 20 seconds. Sometimes Microsoft doesn't respond, and the one I commented out was down for a while. The one you have doesn't appear to support DAYTIME protocol.

At any rate, I should point out in general that these servers, while completely free to use, should not be loaded unnecessarily. I wrote the code to check once an hour originally. The code is to support time synchronization, which usually involves a number of queries to a number of servers, rigid timing, and some type of processing of it all into a time update of one or more clocks. Also, it is used to check precision, drift, etc.

Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 23rd Jan 2007 05:25
Link
I see the Chicago Bears won there game, whom they playing next?

Tried the isp number I gave you but it just comes back with #100060 or something like that.

Saying that your screen output is different to mine, but then we are using different ibuttons.

nearly have most things back on the drive after the rebuild, still get the error report buttons if I try to run programe direct with F5, can only get it to go using F6 or F7?

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Jan 2007 06:41
Link
They will be playing the Indianapolis Colts. It is not a surprising pairing to me. It should be a great game, barring a wardrobe malfunction on Prince's part, that is.

Yes, that server does the Network Time Protocol...I don't in the program just yet. Error 10060 is not a problem, it will still try the next one in the list. That means the socket timed out without a response from the server. I will put more meaningful error text in this week. For now, just use the ones I have listed, or use ones that support Daytime protocol. Anyway, if you get error 10060, just let it continue. That one it can actually recover from already!

...hang on a tick, I will get you some links to explore. I am not at all sure why you need to use debug builds, unless I have left you with another bad array subscript problem. Those usually just fail with that message, however. Lem'me think a bit...requires coffee.
Back to top
Profile PM Email Website
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Jan 2007 06:57 Edited at: 23rd Jan 2007 07:09
Link
Here you go:

Boring RFC-867 document that this is based on:
http://www.faqs.org/rfcs/rfc867.html

Better - Wikipedia entry with further links:
http://en.wikipedia.org/wiki/DAYTIME

Even better:
http://www.greyware.com/software/domaintime/technical/network/protocols.asp

Okay, now I made my screen look like yours. The NIST time will not try to initialize until the minute mark. The other one I will fix, and post an update. You don't have any time devices. Now, I don't either.

Back to top
Profile PM Email Website
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Jan 2007 07:17 Edited at: 23rd Jan 2007 07:17
Link
At line 1128 in my source file there is a function, Get1WireNetworkMasterTime()...here is the fix, I think. It establishes a lower layer of default behavior, which can later be useful in failure modes. :

function Get1WireNetworkMasterTime()
if this.timeMaster = -1 or array index valid(timeSources(this.timeMaster)) = FALSE
this.MasterTime = jzGetLocalTimeStr()
endif
endfunction this.MasterTime

This will default to the Windows function call if there is not a device available.
Back to top
Profile PM Email Website
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Jan 2007 07:26
Link
Watch this:



...nothing up my sleeve...



...bam.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 23rd Jan 2007 11:31
Link
very strange if I leave the code like so :-


with >-1 I get a 118 error code about the subscript being out of range and get the same if I do an F6, now if I change it to =-1 I get an error report buttons come up when using F5 but seems to run ok in F6 or F7, also the error line number is pointing to a rem statement.

wouldn't worry about it as it may be to do with your temperature device being a ds1921 and mine is a ds1920 or ds1820, so the programe say.

Looking forward to the time when I can get some numbers from my device and say hey it x degrees out side

ho! look a yellow sheild more updates..

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 24th Jan 2007 03:30 Edited at: 24th Jan 2007 03:31
Link
Yes, I should have also added that before, when I changed the other function. Here is the correct code:



Sorry about that.
Back to top
Profile PM Email Website
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 24th Jan 2007 08:10 Edited at: 24th Jan 2007 08:11
Link
Here is a version that you might like better. I have disabled the NIST server queries for now, and concentrated on getting your temperature reading going. Mine is working okay, and yours works nearly the same way, so I am hoping that it gets you some data. If so, we can try the others in turn.

At line 1612, there is a place to put your information. The temperature reading will occur once a minute.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 24th Jan 2007 15:24
Link
Well tried the update still not able to run it with F5, now its finding the time stations OK, so that part seem to be working.

Sorry but you have lost me on how or what I am to do to get a reading of the temperature device.

I look at line 1612 but don't see what I should be trying to, as your code is starting to lose me in many places.

Basically I am saying show me how please.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 24th Jan 2007 15:34
Link
I just put my name and location at line 1612. I am not certain that yours will work. Mine only really does 1 conversion with this version.

Its time to go to work, so I will work on it tonight some more if there is time.

Anyway, the temperature conversion is automatic. You should not have to do anything to have it work, or at least try to work, that is.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 24th Jan 2007 15:37 Edited at: 25th Jan 2007 05:30
Link
Ok, catch you later I'm off to work as well.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 25th Jan 2007 06:39 Edited at: 25th Jan 2007 06:45
Link
Well using a very mad idea I've found the function that stops it ruuning in F5 mode, its

well I did find it but its now random so will taken a bit longer


it does not like it when done with F5, all ok if using F6 or F7

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 25th Jan 2007 07:44
Link
There are some differences for DBPro in debug versus release builds. I know of no dependencies on the program's part. That continues to perplex me, as well.

Tonight, I noodled around a little with things on my end. I am getting a temperature reading once a minute, but I have not been able to verify the conversion with the counter that is provided in the DS1921G. It is supposed to increment, but I am not reading it right, I guess.

Also, I tore out some of the old code...I will continue to do that next time. Here is a shot of what I have now:


The code is confusing for a couple of reasons now. Primarily, I am trying to write something that can be programmed to run autonomously, yet remain flexible enough for manual use. Its hard to explain, but I am also learning to manage the differences of the devices, and the WinSock thing is also new, so...I am still using it to experiment, and to learn DBPro more.

EnumerateDevices is ripe for splitting up into smaller functions. That will be one of the more odious tasks that I will need a few hours to do.

Anyway, tonight I'm done. Cheers.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 25th Jan 2007 14:01
Link
I could be wrong but it looks like it maybe a sync lock with device, as sometimes it will stop at :-

function >>> function GetDeviceROMIDStr(device as integer)
line >>> if device > -1 and device < array count(Devices()) + 1

and other times

function >>> function GetDeviceMemoryTypeStr(device as integer)
line >>> if device > -1 and device < array count(Devices()) + 1

was as if the device timed out while it was begin looked at, way it runs in F6 ok is anyone guess.

was thinking at first that you may have had some plugin that I did not have, and that you had called it, but that would had shown like a bad dream.

My mad method it putting "Print "40a "; : sync" (last count you had about 55 functions) at the begin of function or end of endif's messy but is letting me track where it going to and when it stops.

While doing the above it did run once all OK, though I had pressed the wrong complie button but had not.

cheers for now.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 26th Jan 2007 01:48 Edited at: 29th Jan 2007 11:21
Link
Almost every device function works that way. I wanted to avoid using array index valid, but...I think that perhaps that is a change that might help. Also, there is a variable in the devices UDT that is supposed to be used for situations like that.

The program creates the Devices array the first time only. In subsequent Interrogate1WireNetwork calls, it only verifies that the device is still present. That is another error check that will help things. The variable is called bPresent, so the code that would trap calls to non-existent devices would use array index valid and also bPresent.

Wow, it got down to 18.5C while I was at work today. This is in the lab, otherwise known as my bedroom, otherwise known as the basement. I also noticed today that my 1 second loop is pretty accurate most of the time - it was within 8 milliseconds of the DS1921G clock. I was pleased that I was able to use it for time and temperature in the same polling loop. If I could also get the total conversions counter read properly, I would be very pleased with that!

I will post up- a version that uses that type of qualification. First, its dinner and coffee...gotta fuel the motor.

...Here is a version that uses the newer logic. I am not sure at all about the temperature that is returned in your case, it was the first thing I came up with for that device. Before, I just had the same thing my DS1921G uses. Yours is a little different. I hope that you get the debug issue resolved.

Also, the sockets are very stable in this version.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 1st Feb 2007 14:24 Edited at: 2nd Feb 2007 06:10
Link
just re-looked at this post feb the 1st and seen that you have put a new source code up.

Ya he! it works no running errors on running.

just needs a little tweaking on the value of temperature as 37.50c for outside seam a little high, just a sec, on the other weather programme I have values of 51.24f and 10.75c.

not lookied yet to see how you get the values, but I am sure it should be easy to change.

Now to study how and whats going on.

cheers well done.

edit
seem the 37.50c has the same value whether its indoors or outdoors iTemp comes back with 75 when printed on its own.
it does conversion from lines 2510 onwards, id of this_ROM_blk = 16.
I belive that the device I am trying to talk to here is the ds1820 as thats what they show on the PCB.
edit

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 2nd Feb 2007 15:27
Link
had a look at the two devices we seem to be using your DS1920 and my DS1820 and there are a few deffrence between them.

The TRANSACTION SEQUENCE is not the same on the DS1920 it does this,
The protocol for accessing the DS1920 via the 1-Wire port is as follows:
§ Initialization
§ ROM Function Command
§ Memory/Control Function Command
§ Transaction/Data

on the DS1820
TRANSACTION SEQUENCE
The transaction sequence for accessing the DS18S20 is as follows:
Step 1. Initialization
Step 2. ROM Command (followed by any required data exchange)
Step 3. DS18S20 Function Command (followed by any required data exchange)
It is very important to follow this sequence every time the DS18S20 is accessed, as the DS18S20 will not
respond if any steps in the sequence are missing or out of order. Exceptions to this rule are the Search
ROM [F0h] and Alarm Search [ECh] commands. After issuing either of these ROM commands, the
master must return to Step 1 in the sequence.

not much diffrence but enough to stop it doing what it should. looks like it may need a fountion just to read the device.

found the info at
[href]null[/href]http://datasheets.maxim-ic.com/en/ds/DS1820-DS1820S.pdf you may all ready have this info.


cheers Jonathan

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 9th Feb 2007 13:50
Link
jinzai don't know if you had time to look at the above post, however are you follow the flow chart that is with the documentation on your device, or have you done it some other way.

Trying to work out which way it flows through the program so that I could make it follow the flow chart I have for my device as shown in the link above.

Cheers catch you soon.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 9th Feb 2007 22:32 Edited at: 9th Feb 2007 23:24
Link
Yes, I read the post, but got distracted...I'm back now.

I have a DS1921, and thought that you had a DS1920...sorry. I am trying to download the data sheet as we speak...I will get you a temperature conversion yet!

I do use the flowcharts from the data sheets, but some of the steps are actually done by the ibfs32.dll...it is the bus master, and the reset is performed every time Interrogate1WireNetwork is called, so each EnumerateDevices is done on a "fresh" connection.

My DS1921, for example...has a the same command to force a temperature conversion, and the result is read like memory. The conversion takes about 90mS, so I put in an ability to delay things until data was available, but...it is not hooked up to the timing loop yet. (The variable is called ticker, and is a millisecond timer.) Right now, I don't need it, because we are only collecting data once a second. The DS1920 takes much longer...about 750mSec, still...I'm okay getting the answer the next second.

I think you are onto something about the timing of it. While the power will still be on because the session is still active, I think that your temperature conversion request will always need to be the last thing done in each Interrogate1WireNetwork. Other than that, the command is still the same (0x44), and the read is still from the scratchpad (0xbe), like the DS1920. The main difference between your DS1820 and a DS1920 is that the DS1920 is a true iButton, while your DS1820 is either a TO-92 (three-legged bug, looks like a transistor), or an SOIC (small outline integrated circuit, an 8 pin chip). Also, your DS1820 cannot tolerate any activity at all on the 1-Wire network during the conversion because it draws parasite power from the same place. That is probably not so bad in your case, however...we will have to account for it, so what I will do is write a bit of code at the end of EnumerateDevices that will request the conversion at that point. (It is the best place for it because at our sample rate, the line will be quiet for a second, and the read will be valid on the next interrogation.)
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 10th Feb 2007 11:52
Link
distraction not to serious I hope , glad your back.

The device is the 8 legged version, and have just checked the other weather program and you are right the last thing it checks it the temperature after doing everything else.

You may have heard we have had some snow here in the UK, south west part has seen it and its gone, however the Midland's are still sort of digging there way out of it.

Weather people say there might be more on the way, been a few years since it given UK a good dusting.

catch you soon.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 13th Feb 2007 22:58 Edited at: 14th Feb 2007 02:39
Link
Yes, snow is fun...we are getting our share here, as well. I even got a day off today owing to the weather. Yes! An even smaller paycheck next time; I can't wait.

Here is a picture of some of my distraction...I have my non-blocking sockets working at a basic level with the DAYTIME servers. They are great! I can make 16 of them at nearly the same instant, and get the results as they come in with no blocking at all. The application I am using to write the plug-in is a basic FPS with a third person view. The avatar is the female marine from Quake II. If you look in the left corner, you will see a couple of DarkMatter jets patrolling the area, which is advanced terrain from the GIS data for the area of Brest, Belarus. Unfortunately, you cannot at this time see the tank that is also patrolling the area, and my artwork is still pretty primitive. The plug-in provides an additional output for use by the DBPro application. I intend to create a debug window with logging capabilities. In this application, it will be where the ugly display I have now will reside. One of the chief advantages of using a plug-in is that I can register my own window classes, and more importantly, I can define callback procedures, which is the standard way to hook into the Windows subsystem in a well-behaved way. As I said before, I could also hook (cooperatively, we hope) into the message pump of DBPro. What I want with these sockets is something altogether different...they need to work on their own independently of DBPro, yet still interface quickly and accurately. It would also be of enormous utility if they afforded the DBPro app with some object-oriented capability. I think I have that well underway in the plug-in, it works exactly like the app in this thread does by using the C++ Standard Template Library in lieu of the U.A.S., which probably uses STL, anyway.

There is a strong temptation to use .NET extensions, Microsoft Foundation Class (MFC) and/or to use some variety of threads; they are all quite nice. All add additional layers of complexity and interface without making it any easier, so I am not going either route at this time. Winsock is an approximation of Berkeley Sockets, which is the standard that the Internet is built upon. (Unix and clones, primarily.) Windows is pretty easy to control from the normal Windows API, its just a little tedious at times.



The DBPro app creates a TCP socket for each of the 16 NIST DAYTIME servers, and the results are sent to the terminal window. Perhaps you can see that most of the connections happen nearly simultaneously, and I left in the server that appears to be dead. The deviation can be seen in the time returned by the servers. Each socket represents an instance of my jzSocket class, which handles the actual communications. The results are all back before the advanced terrain gets loaded, so it happens alongside the DBPro app, which is what I wanted in the first place.

I have nearly completed the modification to the code to account for the DS1820. I need to substitute my DS1921 to check it, but...It should work without breaking the rest. I will post it later tonight, I hope. The A/D converter and the counter should be much easier...again, I hope.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 16th Feb 2007 19:38 Edited at: 17th Feb 2007 06:26
Link
While I am waiting for your update; your other task pending, I have made a limb model of the device that I get the weather info from, If you have the time just paste in to the ide and run.

cheers.



Dark Physics makes any hot drink go cold.
Back to top
Profile PM
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 22nd Feb 2007 05:37
Link
jinzai how's your distraction coming on and has the weather improved your side.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Feb 2007 03:09
Link
Weather has been peachy for the last three days, now its muddy, and the remaining snow is gray. No worries, they say more is on the way.

I have to say that my focus is really not at all there now! I did the modification, and it worked...but it keeps occurring to me that your thermometer might not be the last device "spoken to", so I still need to use one of the ROM select commands...I have chosen to use the TMAccess function call after loading the ROMID of your thermometer...that will ensure that it works properly. Okay, so after another great weekend with my son (btw, he is getting pretty funny for an 11 year old!), we got this new RC mini-helicopter, it is great to fly around the house! So, naturally...I dusted off my WWII RTS/FPS, and added some nice exhaust particles to the aircraft. You know, the stock DBPro particle system does heat waves, and such quite well with some fiddling...I was impressed with how little I had to do to get a realistic effect. (Sorry, I only had a little time, and it was there.)

Tonight, I have some time to get it wrenched in there properly, and the inclination as well. Here is the version that (should) work, as long as the DS1820 is the LAST device that answers up...I think! (It worked when I used my DS1921 in place of the DS1820, but that is not proof of much!) Okay, coffee's ready...I'll post the new code later.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 23rd Feb 2007 05:33 Edited at: 23rd Feb 2007 05:46
Link
Sound Like great fun with the mini-helicopter they look so simple to use, but you soon find out there not.

Well have donwload this version, changed one variable from Hold Ihold as it is a reserved word for one of the TGC plugins I have, but no joy when run this time, adding some numbers to the CONVERSION IN PROGRESS string I am able to see which one is doing the conversion and it is lines 2613 to 2641, this might help you see what going on.

getting the time from severs work great no problems there.

just notice do you get a fps drop when the mouse is in DBPro window but place it outside it goes up. strange.
edit

just had a thought the ibfs32.dll were should that be, as the code does not moan it has not found it.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Feb 2007 05:52 Edited at: 23rd Feb 2007 06:11
Link
Well, maybe I'm not setting up the display in the correct order...my fps stays pretty constant around 147-150 fps. I suppose that you could rem out the window mode stuff...there's no real need for it to be that way. Oh, and also...maybe a socket was trying to connect, that will lower fps for a bit, too.

I have the necessary mods in place to do this using a ROM select and TMAccess. It works great with mine, but I cannot change when it answers up. I suspect that yours will work with this one because TMAccess applies the necessary TMTouchReset. I think that is the correct procedure. I cleaned up some stuff, too...it is a little inconsistent in some areas still.

Also, ibfs32.dll just needs to be in one of the directories that Windows will search, which are the Windows directory, system32 directory, or the application's directory. It is not at all involved with plug-in dlls, or anything like that. If it were not being found, there'd be BIG trouble at light-off. The install software already took care of that. (The 1-Wire install, that is.)
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 23rd Feb 2007 06:46 Edited at: 23rd Feb 2007 07:23
Link
Nothing happens in the converion part now. ever thing else seem ok.

edit
seem to not want to true this bit to enter.

line 2560 +- 1/2



Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Feb 2007 08:20
Link
My bad, I was suspicious of that file...it is not the one I intended to send. I have to remember to quit fiddling with the project frame...the editor loses its sense of the files. I almost have it sussed out...anyway, thank goodness I didn't damage the copy in the TEMP directory...here it is.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 23rd Feb 2007 13:31 Edited at: 23rd Feb 2007 13:37
Link
Ok still no joy (getting tried of begin negative) here's a run down of what I see it doing;

when tick = true
first pass
enter's at line 2536
then goes to 2538
then line 2540 this un-ture
then two endif

second past enters line 2540
comes back with
device =1
scrathpad 1 = 190
scrathpad 2 = 170
itemp = 75
then prints 35.70c every time.

is there anyway for me to get it to come back with something that may let you work out what might be going a miss.

cheer have good weekend

edit
just though this might help.

PC -- usb Ibutton ds9490r -- rj11 socket -- cable --- weather station rj11 scoket --- ds1820.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 23rd Feb 2007 15:38
Link
I think the conversion time is more than I am allowing...no time to check now, but I will try when I get time. I have a rare Saturday off tomorrow, so I will put in the delay. The path you showed is the correct one, I just need to give the thing a little more time. (I mean, you have to be absolutely melting at 37.5C!)
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 23rd Feb 2007 16:28
Link
I think it gets close to that in Australia at the moment.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 24th Feb 2007 06:54
Link
Okay, I have gone a slightly different route this time. I used TMBlockIO to send the Match ROM command, which I think might be the issue at this point. I suspect that my DS1921 being at the rear of the queue is masking my improper use of the network outside of the relatively simple TMFirst/TMNext method.

If this works well with the DS1820, then it will be a way to address individual devices out of order, and also asynchronously with respect to EnumerateDevices, which will help alot with your end application.

I hope that this works...that way we can move on to the counter and A/D converter...then get the visuals hooked up.
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 24th Feb 2007 08:55 Edited at: 24th Feb 2007 10:08
Link
think I may have an answer, if you look at this



you will see the Temperatura number for the TAI8515, now on the 1 wire code you have this

DC008000B114A01 DS1920 DS1820

now it may just be being displayed worng but it looks back to front.
As you have guessed the last code was a no go.

EDIT
but then again I may be wrong as I found this ini for the graphics and thats the way your using now.



Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 24th Feb 2007 20:14 Edited at: 25th Feb 2007 07:04
Link
Actually, I reverse it to match the output of the 1-Wire Viewer app...if you look at the function "GetROMIDStr", it makes the string back-to-front, with the CRC first, ID bits 5 - 0, then the device family. If you go back to code before I wrote that, you will see it displayed as it appears in the structure...family/id/crc. I just didn't like the way it looked - not like the Dallas app.

There are a couple of things that might be happening here. I have overrun the DS1921's ability in the past; I never got the time and temperature "in the same breath". (That device can timestamp conversions, so it is not really a problem.) Next, I think that the DS1820 data set commands would use the TMTouchByte type communications as opposed to the stream oriented ones that I have been using. I will code the change today...bit by bit.

EDIT: There is a typo in the code that gets the data. I changed the variable used from the GLOBAL iTemp to the LOCAL itemp. You can see it in the code that attempts to read the scratchpad. I am rewriting that code, because it is not appropriate for your device, either. Your DS1820 does not work like later iButtons do...it requires the use of the ROM commands. I am nearly done with it.
Back to top
Profile PM Email Website
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 25th Feb 2007 04:34 Edited at: 25th Feb 2007 06:59
Link
This version uses the TMTouchByte command to "byte bang" the ROM command and device command. I have tried to duplicate the sequence in the data sheet as closely as I could within the context of the program. (For example, I do not wait 750 milliseconds after the convert command, I go about my business, and wait until the next second to ask for the data.)

At any rate, I think we are closing in on it....
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 25th Feb 2007 10:42 Edited at: 25th Feb 2007 11:18
Link
Well, will let you know how its doing soon after another rebuild hopefully the problems will go away Monday when the guy to give it a kick as been.

just thought I'd go AAAAAAAAAARRRRRRRRRRRRRRRGGGGGGGGGGGGGGG.

right that's better.


edit
Right we are now getting a reading of zero degrees which mean something as happened. What I not work out yet. plus this machine is playing work on work.

and trying a new firewall and its driving me up the wall, can't anyone one make one that's user friendly? Ho just remembered if was user friendly I would have worked out how use it by then.

DBPro is now playing the send; don't send, game run it one time OK run again no your not.

right, that's me moan out the way.

I'm getting quicker at rebuilding this system now doing it in under 4 hours. used to take 9.

perhaps when I have calmed down , might be able to see whats going on in the code, at the moment the screen dump protocol keep wanting to engage.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 25th Feb 2007 22:14 Edited at: 25th Feb 2007 22:48
Link
Ouch. I hate it when that happens. Recently, I fell for another Java update, which I am certain that I did not want. Since the kid has another iPod now, I also have Steve Jobs running amok in my machine. I hate that guy! My mp3 player works like a drive; its really a cakewalk working with it. The iPod is a pain in the ar$e.

You certainly are patient; I have to give you that.

I only tested the MatchROM/Convert side of the sequence on my DS1921 because it has EEPROM memory as opposed to scratchpad memory, so it has a little different way of reading it. I could probably make it work like your DS1820 by using the MatchROM/READ_MEMORY, but I suspect that it would work fine still. (It has been very nice about giving me the correct temperature in about 4 different ways at this point.)

What is going on? I wonder, too. Well, I think that we have initiated a conversion (finally), but returning 0 is the DS1820's way of saying that the conversion is still in progress. I had thought about initializing the buffer to 0xff like the samples code usually does...then, if it returns 0xff, we have no data written to the buffer. I wrote the code to conform to the datasheet flowchart. Every time I want to address the device directly, I use the byte by byte method, which slows down ibfs32 a little. The command will return -1 if it cannot transmit the entire sequence. (Not the best error reporting, but...its a start.) In the datasheet, the code assumes little, but it does draw the communication out in one long back and forth sequence...a little selfish if you ask me, but.... One thing that I have been wondering about is the master holding the bus high. That is what (I assume) happens when there is no activity, but the session is still valid...the line is held high. That is normal for this type of signalling line...it is held in either a logic 1, or a logic 0. The US Navy calls it "mark hold" and "space hold", among other things; it is an idle state in any case. TMTouchReset "pulls" the line low for 480 microseconds minimum. That is a control signal; it resets the "line". Then, the devices indicate their presence in a similar fashion. The TMFirst/TMNext code in EnumerateDevices has two major, and two minor paths...TMFirst and TMNext are the outer portion, and in the inner portion of each is the section that checks to see if the device has already been "acquired". ("DeviceAlreadyAcquired") btw, all that function does is a fast compare of the ROMID using XOR. That is an old assembly language trick to zero out a register. Anything XOR'ed with itself results in zero, so I just xor each one...if the result is zero six times, its a match. The rest of EnumerateDevices is trying to determine what we have found, and what if anything to do with it.

What we are doing now is going to be very helpful to you once I get it all sussed out properly. (I'd almost kill for a DS1820 and a storage scope at this point, but...I can do this with the device in GB, and me in IL....done it before at greater distances than this with less going for me. Its really a matter of black box t-shooting, and killer utility on the software end, which we don't have just yet...sorry, we will get there, too.)

...I can call TMTouchReset before each sequence is sent, which will do two things for the DS1820. First, it will reset its own communications. Second, it will slow down ibfs32 a little more. That way, we can compensate for its reduced ability, and not make the rest of the devices suffer for it.

EDIT: One more thing, I am going to move the code to get the result into the same place that I have placed the convert request. I don't think that the DS1820 likes being in the TMFirst/TMNext AT ALL, so let's move it out of there, and see what happens.

Hang in there, Jonathan...We will get this thing going like you want it to. I just know it.
Back to top
Profile PM Email Website
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 26th Feb 2007 00:20 Edited at: 26th Feb 2007 00:26
Link
Okay, I am stupid. I never got the scratchpad content! When you use TMTouchByte, there are 2 things that you need to do that I did not do:
You have to TMTouchByte 9 additional times to get the scratchpad contents, and also...I was not saving the return from TMTouchByte...it is actually an echo function.

Try this one...I hope it works!
Back to top
Profile PM Email Website
HowDo
22
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 26th Feb 2007 00:33
Link
Yes patient is an understatement, after doing the rebuild (9) could not get the dam thing to fall over, engineer going to have fun trying to find out if its hardware or software.

In your above text are you say if we were link via the net some how you would be able to talk to it from your end?

Using my old P3 to write this after waiting for all the updates from about 6 mouths of it begin off line.

Will be trying the code on this machine when I have found the right bits and down loaded them againagainagain.

If its possible could you show in the code were it will trying to do its job with a set or rem ed 8s, as I am just guessing I am hitting the right places when looking to see where its going.

cheers again.

Dark Physics makes any hot drink go cold.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2025-08-08 17:36:57
Your offset time is: 2025-08-08 17:36:57