about to pull what hair I have left out. Can some one help

karebill · Mar 15, 2011

Im using Dr_Acula example http://www.instructables.com/id/Control-real-world-devices-with-your-PC/ as my learning platform to use a picaxe with visual basic 2010. I am adding a DS18B20 to pin 4. (on a 20M) I know the circuit is correct because i can do a #terminal test and it reads correct.

#PICAXE 20m
#TERMINAL 4800
Symbol TReading = b0
setfreq m4

do
ReadTemp 4,TReading
sertxd ("Temp is ", #TReading, CR, LF)
loop

when I run this code below, b0 shows nothing but b2 which I put 100 into reads correct. I can turn pin one on and off also. I know im communicating between the picaxe and VB. I am using Dr_Acula VB code exactly.

Any one have any Ideas.

#PICAXE 20m
setfreq m4
main:
serin 7,N2400,("Data"),b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13
readtemp 4,b0
b2 = 100
serout 0,N2400,("Data", b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13)
if b4 = 1 then
high 1
else low 1
endif
goto main

westaust55 · Mar 15, 2011

Welcome to the PICAXE forum.

Do you have the DS18B20 temp sensor conencted to PICAXE logical input 4 which is the physical pin/leg 6 on the chip?

Do you have the 4k7 Ohm pull up resistor between the DS18B20 data pin and the supply voltage.

A schematic/circuit diagram would be helpfull for folks to understand your problem if the above prompts have not helped.

inglewoodpete · Mar 15, 2011

I think your trouble is what character you are inserting into the string. The PICAXE code you have posted receives data for VB and sends it back.

My guess is that the data sent by VB is printable characters: like ABC123?:-(&.

The temperature reading is a binary value like (say) 13 for 13 deg C. 13 is a non-printing, formatting character ("New Line"), so VB treats it differently to a printable character. I suggest you convert b0's temperature value to ascii (BinToASCII command) and send the values in several registers.

Otherwise you will have to explore how VB can read and interpret binary data (bytes)from the serial port.

SAborn · Mar 15, 2011

I think IWP is correct with a data type miss match between programs.

The simple solution might be to add a # before the variable on serout, like this.

serout 0,N2400,("Data", #b0,#b1,#b2,#b3,#b4,#b5,#b6,#b7,#b8,#b9,#b10,#b11,#b12,#b13)

This way the data should be in ascii format.

Worth a try.

hippy · Mar 15, 2011

SAborn said:
The simple solution might be to add a # before the variable on serout, like this.

serout 0,N2400,("Data", #b0,#b1,#b2,#b3,#b4,#b5,#b6,#b7,#b8,#b9,#b10,#b11,#b12,#b13)

This way the data should be in ascii format.

The problem with that is it will then merge all the numbers as one long string and you won't know what starts where. You need to add data separators, commas or something.

The fundamental issue though is that we have a piece of PC software that is written to work in a particular way and using it with a PICAXE program which isn't written to work in the way the PC software does will not work.

Rather than trying to hack what doesn't work - replacing a square peg with a round one, trying to bash that round peg into the square hole - we need to look at why what should work is not working - why the square peg and square hole don't fit together. Going off at a tangent won't really help.

hippy · Mar 15, 2011

karebill said:
when I run this code below, b0 shows nothing but b2 which I put 100 into reads correct ...

#PICAXE 20m
setfreq m4
main:
serin 7,N2400,("Data"),b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13
readtemp 4,b0
b2 = 100
serout 0,N2400,("Data", b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10,b11,b12,b13)
if b4 = 1 then
high 1
else low 1
endif
goto main

So what happens if you put "b0=123" before "b2=100" ? Does b0 then show "123" on the PC ?

karebill · Mar 15, 2011

Thanks for the quick reply.

(Do you have the DS18B20 temp sensor conencted to PICAXE logical input 4 which is the physical pin/leg 6 on the chip?
Do you have the 4k7 Ohm pull up resistor between the DS18B20 data pin and the supply voltage.)

I do have the DS18B20 data pin connected to physical leg six (input 4) with a 4k7 resistor to vcc. I can use the #terminal command and verify that it is sending the data.

(So what happens if you put "b0=123" before "b2=100" ? Does b0 then show "123" on the PC ?)

Yes if i put "b0=123" i get b0=123 on the pc

I played with this a year ago and had it working but now i cant get it to work no matter what i try. I am going to hook a pot to it and see if the readadc command will show on the pc.

inglewoodpete · Mar 15, 2011

Alternatively, comment out both SerIn and SerOut, replacing SerOut with Debug.

hippy · Mar 15, 2011

karebill said:
Yes if i put "b0=123" i get b0=123 on the pc.

That's great, so your code currently looks like this ...

readtemp 4, b0
b0 = 123
b2 = 100
serout ...

So now read the temperature into b2, remove "b2=100", and try that -

readtemp 4, b2
b0 = 123
serout ...

If the b0 still shows "123" but b2 now shows 'nothing' ( presumably zero ) then it's a fair bet that the READTEMP is actually returning zero, a hardware issue.

karebill · Mar 16, 2011

Well i have come to the conclusion it is not a hardware problem. A pot works fine and if i do debug it reads fine. but for some unknown reason the ds18b20 will not work. Has anyone tried using the ds18b20 with this vb setup?

westaust55 · Mar 16, 2011

From what I read, it is not an issue as to whether the DS18B20 can interface to VB, it is a hardware problem between the DS18B20 and the PICAXE as hippy has suggested.

The READTEMP command is reading 0 from the command suggesting that there is no input signal from the DS18B20 to the PICAXE.

If the DS18B20 were correctly connected but not initiated you would receive the default value of 85 when the READTEMP command is used.

The 0 value starts to look like there is not pull-up resistor properly connected as the 1-Wire system uses an open collector data line and if the resistor is not functional then you receive all zeros.

If the resistor were functional and the DS18B20 was not properly connected you will received all 1’s (=255 = error ).

karebill · Mar 17, 2011

Ok I got it working. the original VB code was this... Call Sleep(300) ' 100 milliseconds minimum to wait for data to come back and more if data stream is longer

I changed it to add more time for the data to come back... Call Sleep(1000) ' 100 milliseconds minimum to wait for data to come back and more if data stream is longer.

It now reads the temp. Thanks all for the help.

hippy · Mar 17, 2011

karebill said:
I changed it to add more time for the data to come back... Call Sleep(1000) ... It now reads the temp.

Interesting. I'd discounted that on the grounds that in the "b2=100" and "b0=123" tests the READTEMP was completing and sending data to VB or the 100 and 123 would never get through, and if those were getting through then so should everything else.

Perhaps one for Dr. A; how could VB have received the non-READTEMP data but not the READTEMP data ?

Glad you fixed it anyway.

inglewoodpete · Mar 17, 2011

Now I understand the problem. I was focussed on the PICAXE and not taking into consideration the possible impatience of the VB code.

VB wasn't waiting long enough for the PICAXE to do it's stuff. The ReadTemp command can take up to 750mS to convert and report the temperature.

It would be far better to have the VB code for the serial port event driven.

westaust55 · Mar 17, 2011

inglewoodpete said:
Now I understand the problem. I was focussed on the PICAXE and not taking into consideration the possible impatience of the VB code.

VB wasn't waiting long enough for the PICAXE to do it's stuff. The ReadTemp command can take up to 750mS to convert and report the temperature.

It would be far better to have the VB code for the serial port event driven.

In fact as expansion of IWP's comment, from the manuals and also more recent comments on the forum by Technical, I believ that:

All chips from the M, M2 and X1 and early X2 series parts wait for 750ms when the READTEMP and READTEMP12 commands are used.
The very latest X2 parts now poll the DS18B20 and only wait as long as necessary for the DS18B20 to complete the conversion. So it would be around 100msec for the READTEMP and 750 msec for the READTEMP12 command.

hippy · Mar 17, 2011

inglewoodpete said:
VB wasn't waiting long enough for the PICAXE to do it's stuff. The ReadTemp command can take up to 750mS to convert and report the temperature.

But, if that's the case, then how do you explain the other data getting through ? That's what has me stumped.

The "b2=100" is only set after this 750ms and if it gets through then why not the READTEMP result which would also be ready at the same time ?

Technical · Mar 17, 2011

westaust55 said:
In fact as expansion of IWP's comment, from the manuals and also more recent comments on the forum by Technical, I believ that:

All chips from the M, M2 and X1 and early X2 series parts wait for 750ms when the READTEMP and READTEMP12 commands are used.

The very latest X2 parts now poll the DS18B20 and only wait as long as necessary for the DS18B20 to complete the conversion. So it would be around 100msec for the READTEMP and 750 msec for the READTEMP12 command.

We never really said that

All chips from the M, X, and X1 series parts wait for 750ms when the READTEMP and READTEMP12 commands are used.
The M2 and X2 parts now poll the DS18B20 and only wait as long as necessary for the DS18B20 to complete the conversion.

We never said anything about 100 or 750ms, the PICAXE simply waits for the conversion to complete which can be anything 'up to' 750ms.

inglewoodpete · Mar 17, 2011

hippy said:
But, if that's the case, then how do you explain the other data getting through ? That's what has me stumped.

Maybe I misread the original post. I had assumed that, with the ReadTemp being included in the PICAXE code, VB was reporting that nothing came through. If "something" was getting through then there is something else happening.

The test would be to use a simple terminal program to send and receive the data. I wonder if karebill could try that and report back.

inglewoodpete hey! that's me! said:
It would be far better to have the VB code for the serial port event driven.

I'm trying to say "Don't rely on delays to get data from the serial port. Use the SerialPort.DataReceived event."

hippy · Mar 17, 2011

inglewoodpete said:
Maybe I misread the original post. I had assumed that, with the ReadTemp being included in the PICAXE code, VB was reporting that nothing came through. If "something" was getting through then there is something else happening.

You could be right, but the test with b2=100 and b1=123 both showed a something happening, the expected values being shown, and both those tests included a READTEMP. Perhaps the READTEMP was not actually included, what was tested wasn't what we were told was being tested ?

Perhaps karebill could clarify as it would be nice to know as using Dr. A's code has cropped up on the forum before.

westaust55 · Mar 17, 2011

Technical said:
We never really said that

All chips from the M, X, and X1 series parts wait for 750ms when the READTEMP and READTEMP12 commands are used.
The M2 and X2 parts now poll the DS18B20 and only wait as long as necessary for the DS18B20 to complete the conversion.

We never said anything about 100 or 750ms, the PICAXE simply waits for the conversion to complete which can be anything 'up to' 750ms.

yes you did indicate M2's also poll the DS18B20.

True that you never categorically stated anything about the durations from polling the DS18B20.

the timings I gave were my own approximations based on my memory for 9 and 12 bit conversions from information in the DS18B20 datasheet

karebill · Mar 19, 2011

inglewoodpete said:
Maybe I misread the original post. I had assumed that, with the ReadTemp being included in the PICAXE code, VB was reporting that nothing came through. If "something" was getting through then there is something else happening.

The test would be to use a simple terminal program to send and receive the data. I wonder if karebill could try that and report back.

I'm trying to say "Don't rely on delays to get data from the serial port. Use the SerialPort.DataReceived event."

The terminal program works fine. I know it is a timing problem. I added a second ds18b20 and had to up the delay time by twice to get it to give me numbers instead of zeros. can you give me an example of a serialport.datareceived event. thanks Bill

karebill · Mar 19, 2011

hippy said:
You could be right, but the test with b2=100 and b1=123 both showed a something happening, the expected values being shown, and both those tests included a READTEMP. Perhaps the READTEMP was not actually included, what was tested wasn't what we were told was being tested ?

Perhaps karebill could clarify as it would be nice to know as using Dr. A's code has cropped up on the forum before.

The readtemp was still in the picaxe code but I didnt have the ds18b20 connected. When i connected it I got all zeros even the b2=100 and b1=123
Thanks for the help Bill

hippy · Mar 19, 2011

karebill said:
The readtemp was still in the picaxe code but I didnt have the ds18b20 connected. When i connected it I got all zeros even the b2=100 and b1=123

Yes, that would explain it; the READTEMP completes much quicker in those circumstances so you don't need the long delays in VB code. Thanks for explaining.

inglewoodpete · Mar 21, 2011

karebill said:
...can you give me an example of a serialport.datareceived event. thanks Bill

The following piece of code come from a VB 2008 application that I am writing to interface with a PICAXE via serial. The code "collects" serial data as it arrives, adding new data to to the accumulation string. The data, incoming from the PICAXE, is terminated with a CR/LF Eg HSerOut cSNoBreak, (CR, LF) or SerTxd(CR, LF) etc.

The code gives examples for 3 different methods of handling the incoming data: Extract the required data, Display the data on the screen or log the data to file.

Code:

    Private Sub Receiver(ByVal sender As Object, ByVal e As SerialDataReceivedEventArgs) Handles SerialPort.DataReceived
        ' Note this subroutine is executed on the serial port thread - not the UI thread.
        Dim bRXByte As Byte
        Dim RXArray(2047) As Char
        Dim I As Integer = 0
        Dim sOPData As String = ""
        '
        Do
            bRXByte = SerialPort.ReadByte
            RXArray(I) = Chr(bRXByte)
            I = I + 1
        Loop Until (SerialPort.BytesToRead = 0)
        Dim RxString As New String(RXArray, 0, I) ' Convert the first part of the Char Array to a String
        sBuild = sBuild & RxString                'sBuild is a Class (Public) variable that accumulates the incoming data
        If InStr(sBuild, vbCrLf) > 0 Then         'Only process data strings that contain a line terminator
            RxString = Strings.Left(sBuild, InStr(sBuild, vbCrLf) - 1) 'Extract RxString from received data
            sBuild = Mid(sBuild, InStr(sBuild, vbCrLf) + 1) 'Then Remove RxString from received data
        End If
        '
        If Len(RxString) > 0 Then
            sOPData = ProcessIncomingData(RxString) 'ProcessIncomingData extracts the required data from the incoming data
        ' Put the "Display" routine and the RxString on the message queue and return immediately.
            txtReceivedLog.BeginInvoke(New StringSubPointer(AddressOf Display), RxString) '"Display" is a separate sub
            FileWriter.Write(RxString)      'Log incoming data to file
        End If
    End Sub

about to pull what hair I have left out. Can some one help

New Member

Moderator

Senior Member

Senior Member

Technical Support

Technical Support

New Member

Senior Member

Technical Support

New Member

Moderator

New Member

Technical Support

Senior Member

Moderator

Technical Support

Technical Support

Senior Member

Technical Support

Moderator

New Member

New Member

Technical Support

Senior Member