Arduino and Dallas DS1820 (one-wire)

[1cecream]

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.

This makes sense because I've actually tried communicating my MEGA with other sensors such as the DHT11, and have had no problems at all. I also read somewhere on the Arduino forums that the MEGA 2560 has a tendency of auto-resetting when Labview is trying to open Arduino's serial port (http://forum.arduino.cc/index.php/topic,50266.0.html), causing it to be irresponsive; this is the only hardware issue I can think of that is causing the Arduino to not respond. However, I did try to disable auto-reset by sticking a 120ohm resistor between 5V and Reset, and still ran the program without success.

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.

The firmware does compile without errors. In fact I have experienced no issue with uploading the code onto my Arduino at all. Attached .zip is the LIFA_BASE firmware I have been testing the DS18b20 device with.  I've also added LIFA_BASE.ino, LabVIEWInterface.ino and LabVIEWInterface.h, just incase .zip does not work for you.

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. . .).

That would be great. At least if it does work for you, I'll know with greater certainty that the underlying issue is probably something to do with my Arduino Mega. The OneWire library I downloaded was from this site: http://playground.arduino.cc/Learning/OneWire , and the DallasTemp library: http://milesburton.com/Dallas_Temperature_Control_Library (Version 3.7.2).

Thank you for your efforts!

[1cecream]

Hi Nathan,

I was wondering if you ever got the MEGA working with the DS18b20. I also tried mariolino74's method and still ended up with the same error. I'll be getting an Arduino Micro soon so I guess I can test the code out when that arrives, in hopes of identifying whether the main issue is hardware (MEGA specific) or software related. However I still want to know if the code generally does not work on a MEGA, or it has something to do with my board specifically. It would be great if you could shed some light on this matter!

[Nathan_B.]

Unfortunately, I can't get it to compile.  It shows many fundamental errors in DallasTemperature.cpp and DallasTemperature.h and I've not been able to figure out why.  Not sure how you could get it to compile when there are these types of errors.

Errors:

In file included from DallasTemperature.cpp:10:
DallasTemperature.h:64: error: expected `)' before '*' token
DallasTemperature.h:222: error: ISO C++ forbids declaration of 'OneWire' with no type
DallasTemperature.h:222: error: expected ';' before '*' token
DallasTemperature.cpp:20: error: expected `)' before '*' token
DallasTemperature.cpp: In member function 'void DallasTemperature::begin()':
DallasTemperature.cpp:38: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'bool DallasTemperature::validAddress(uint8_t*)':
DallasTemperature.cpp:67: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'bool DallasTemperature::getAddress(uint8_t*, uint8_t)':
DallasTemperature.cpp:76: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'bool DallasTemperature::isConnected(uint8_t*, uint8_t*)':
DallasTemperature.cpp:99: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'void DallasTemperature::readScratchPad(uint8_t*, uint8_t*)':
DallasTemperature.cpp:106: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'void DallasTemperature::writeScratchPad(uint8_t*, const uint8_t*)':
DallasTemperature.cpp:173: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'bool DallasTemperature::readPowerSupply(uint8_t*)':
DallasTemperature.cpp:191: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'void DallasTemperature::requestTemperatures()':
DallasTemperature.cpp:324: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'bool DallasTemperature::requestTemperaturesByAddress(uint8_t*)':
DallasTemperature.cpp:341: error: '_wire' was not declared in this scope
DallasTemperature.cpp: In member function 'bool DallasTemperature::alarmSearch(uint8_t*)':
DallasTemperature.cpp:590: error: '_wire' was not declared in this scope
DallasTemperature.cpp:593: error: '_wire' was not declared in this scope


[DavePW]

Hi PentairDave....

Well been playing around with your solution for reading the DS1820 and it certainly works - Thanks.

I have noticed a possible glitch though.

I have been trying to compare the DS1820 with the analogue TMP36 part and have attached my diagram for this.

What I have noticed is that if you have an analogue read after the DS1820 read then the analogue read doesn't work.

So looking at the diagram I have attached both the TMP36 and DS1820 reads work fine but if you try to read an analogue voltage at the read after the DS1820 it doesn't respond with anything... Am I missing something??

Thoughts anyone?

Dave W

[Nathan_B.]

Does it depend on which analog pin you are reading or is is a specific pin?

Likely not related to the issue but you can (should) move the Init and Close VIs outside of the loop so that you are not initializing and closing the Arduino connection on ever loop iteration.

[DavePW]

Thanks for the reply Nathan...

No I don't get anything sensible from any pin.

Thanks for pointing out the silly mistake re the init and close Vi's - Spot the beginner??!!

[Nathan_B.]

If it was me, I would test this same thing with purely Arduino code:  read the sensor then read an analog pin to see if there is something specific to LIFA causing it.

When you say you don't get anything 'sensible', does that mean that you are getting a value (as opposed to something actually failing)?  I'm guessing that the Arduino is printing more characters to the serial line than LabVIEW is expecting.  This means that that extra byte might be being read by the Analog Read Pin.  This is why I would try to avoid sending formatted floating point values over serial.

[DavePW]

Hi Nathan..

Interesting what you said about moving the init and close Vi's outside the While loop - It makes sense but when I do that the the value recorded for both the DS1820 and the TMP36 gets scrambled. The first iteration round the loop is fine with both sensors recording a sensible value. But then further iterations of the loop cause the numbers to be recorded wrong - they are changing but are all over the place...

As you say its probably best to test this just on the Arduino to see if its a LIFA thing. I'm pretty sure its LIFA - would be interested to hear from PentairDave who came up with the solution and changes to LabViewInterface.h which I'm using.

[PentairDave]

All,

Sorry I've been quiet, I haven't had time to mess with this again since testing that one night.  I will try again this weekend and see if I get the same results.

DavePW, one question I have is do you have a delay in there?  I noticed that without a couple second delay it would do what you are saying and give answers that are all over the place.

I was just looking at the LIFA code again and I had a thought.  I wonder if we need to send a Serial.begin() in the LIFA_Base before we can talk to it correctly?  Not sure, just a thought.  As I said, I'll try to mess with it more this weekend to see what I can find out.

[DavePW]

Thanks for coming back on this one PentairDave....

Yep I've played around with the delay value (upto 5 secs) - but the numbers are still bad..