Arduino and Dallas DS1820 (one-wire)

[MattBradley]

Hello PentairDave,

I admit it.  I'm new to this Arduino stuff.  Looks very interesting, but I'm having some issues.  Since I'm trying to talk to a DS1820, this seems like a good thread.

I tried using using your LIFA_Base.zip code you posted on 7/23, but when I tried to verify it, I got this error:

LabVIEWInterface:67: error: 'OneWire' does not name a type ... and then several more, all in LabVIEWInterface

I tried some other things but they didn't work either.  What am I doing wrong or what am I using that's wrong?  Are there any other files I need besides the LIFA_Base.zip code you posted?  Whenever I try to add in the DST 3.7.2 cpp and h files it asks me if I'm replacing them.  Same with onewire cpp and h files.

I'm using Arduino version 1.05 and trying to get it to work with LabVIEW 2010.  I'm starting with one sensor but eventually will move on to about 6.

Thanks a lot!

[MattBradley]

Update: OK, I figured out a bit more.  I imported the libraries and now I have the code working (I think).  It compiles and I downloaded it.

Now I'm trying to get it to work with LabVIEW... so far, so good.  Thanks for all the posts....

[PentairDave]

Matt,

Glad you got it working.  Let us know how the LabView interface works out.  I tested it before I put it up here but that is as far as I have gotten with it.  As I include it in my project I'll let you know if there any issues that arise but in my testing it worked well. 

There may be another way of doing it as well and that is to move the sensors.begin() to the void setup() of the LIFA_Base file and then only call the getTemperatures in the other.  I would also like to figure out how to pass a second command (index of the sensor) that way I can have one read per temperature sensor rather than reading them all at once and then trying to parse the information afterwards.

[1cecream]

So despite having implemented almost all the DS18b20 communication methods mentioned on this thread, a particular issue is constantly coming back to haunt me - As you can see from the photo below:

after succesfully uploading the appropriate Arduino firmeware, the above happens when I run my Labview VI to acquire a reading off the DS18b20: My laptop has clearly established a connection with the Arduino, but the Arduino is not transmitting any signals back to my laptop, and thus my Labview VI (RX light on, TX lights off). The following are some reasons why I think this is occuring:

1. Hardware issue (perhaps I unknowingly fried an electrical component on the Arduino or the DS18b20 is faulty) - This shoulden't be the case because labview-arduino interface works fine when I do not upload a firmware modified to read DS18b20. Additionally I have tested the DS18b20 via Arduino ONLY, and have succesfully obtained accurate temperature readings.

2. The Arduino is auto-resetting which is why the Arduino is irresponsive (TX lights off) when the VI begins to run - Maybe the labview firmware is toggling the DTR line in a way that causes it to auto-reset. A serial issue?

I think the reason entailing auto-reset is most likely and in fact I intend to try disabling auto-reset later, after I've acquired a 120 ohm resistor.

Has someone else on this thread come across this issue when talking to the DS18b20 via Labview-Arduino interface? or does anyone have any suggestions as to why this might be occuring?

[DavePW]

Well I agree with '1cecream' !

I don't get the issue he reports but have also tried the various schemes in this thread to get a temperature read from my DS18b20 on Labview. So far no joy.

If anyone has a working solution for this I would certainly appreciate some detail and vi's

Yours confused and dismayed....

d

[Nathan_B.]

IIRC, that can happen when the firmware is expecting a different baudrate than the one you are using in the LabVIEW program.

Which Arduino are you using?  What do you have as the baudrate on the Init.vi?  Which custom firmware are you using from this thread?  It's hard to tell which one since I've seen several different posts with firmware.

[1cecream]

Hi Nathan,

Thanks for your reply!

IIRC, that can happen when the firmware is expecting a different baudrate than the one you are using in the LabVIEW program.

I actually wasn't aware of this, but I just checked the firmware's Serial Baudrate and Init.vi Baudrate and they are both 9600.

Which Arduino are you using? 

I am using the MEGA 2560 R3.

Which custom firmware are you using from this thread?  It's hard to tell which one since I've seen several different posts with firmware.

The current firmware I am checking with is the route PentairDave recommended.

I also tried to disable auto-reset with a 120ohm resistor, but still the Arduino remains irresponsive (RX lights will blink for about 5 - 10 seconds until Close.VI senses that the Arduino is not communicating with Labview, and the entire VI stops). I think I should also note that when I tried running other labview-arduino interface VIs, whilst applying the same firmware customized to read the DS18b20, the same issue occurrs with the Arduino even though the particular case to talk with the DS18b20 is not even being called.

[Nathan_B.]

If you are having issue regardless of which function you are trying to use, you need to find out what VI actually creates the error.  You can do this by turning on execution highlighting and then watching the error wire values at the exiting wire terminals.  Because it happens for any function, it is probably being cause by Init.vi (meaning that it never gets to the point of executing a particular LIFA function).

Also, make sure that you consult the official documtation for the particular error that you are reveiving for troubleshooting steps.

Also, just to clarify, are you able to run a simple VI with the default firmware?  I usually test using something like this but with pin 13 (the on-board LED).

EDIT:  One other thing that I just thought of is that when you use Serial.print(), it sends human readable text.  This means that you will never really know the actual number of bytes you should be receiving.  If you do Serial.print(1.2354), it will send 4 bytes ("1.23").  If you do Serial.print(12.345), you will get 5 bytes ("12.34").  So, if you are expecting 5 bytes (as shown in PentaireDave's code, and it is only sending 4, it will timeout.

[1cecream]

Hi Nathan thanks for the advice,

you need to find out what VI actually creates the error.

I ran in execution highlighting and discovered that init.vi is producing no output signal as shown below:

Also, make sure that you consult the official documtation for the particular error that you are reveiving for troubleshooting steps.

I get an error 5002 but I've pretty much covered all the troubleshooting tips on http://digital.ni.com/public.nsf/allkb/15AE7F234C5B966886257884006DF1CD, and I'm pretty certain the addition of DS18b20 communication code to the Labview-Arduino firmware is making my Arduino irresponsive.

Also, just to clarify, are you able to run a simple VI with the default firmware?  I usually test using something like this but with pin 13 (the on-board LED).

Yes I can run the Arduino perfectly when using the default firmware, or basically any firmware that does not have DS18b20 communication code implemented.

So, if you are expecting 5 bytes (as shown in PentaireDave's code, and it is only sending 4, it will timeout

How do I go about fixing this? The send/recieve vi I'm currently using to call the case 0x35 is expecting 5 bytes. In fact I tried every possible byte input on the vi side of things, and still have an unresponsive Arduino. Do I need to make some changes to the firmware?

[Nathan_B.]

If it is only specific to the firmware with the sensor implemented in it then there is something wrong with that firmware.  Just adding a function will not normally affect the Arduino's ability to respond to LabVIEW.

Does the firmware compile without any errors?  Maybe you will need to post the LIFA_Base folder that contains the custom firmware because I don't see any major issues that would make the Arduino unresponsive with the version that PentaireDave posted.

I do have an Ardiuno Mega available to me so I will try and see if I can upload the firmware and get basic communication working (hopefully I get the correct library. . .).