Arduino and Dallas DS1820 (one-wire)

[Nathan_B.]

It sounds like my previous thought may be true, that the Arduino is sending back too many packets.  If you send one too many packets once, it will throw everything off by one unless the buffer is cleared.  When you had the Init and Close VIs in the loop, it was clearing the buffer meaning that you were "starting" fresh each loop making your first function get all it's data.

One thing that you could do in the firmware is to multiply your result by 1000, cast it to an integer and send just that integer (probably a signed 32-bit or something which would require sending 4 bytes back).  Then, in LabVIEW, cast it back to a double and divide by 1000 to get the original number.  Using a method like this, unlike sending a formatted string, is that you will always only be getting 4 bytes from the Arduino preventing issues cause by the Arduino sending an unknown number of bytes to LabVIEW.

[PentairDave]

DavePW,

So this is what I did this weekend to get it working.  First I moved the setup information for the ONeWire and DallasTemperature to the LIFA_BASE file as opposed to the LabViewInterface file.  Next I added the Serial.Flush() method to our case 35 that we added previously.  Finally I added the setResolution(9); method which sets the resolution of the sensors to 9 bits.  I did this because as Nathan_B suggested the arduino may have been taking too long to answer.  All of these things combined made my system work flawlessly for over an hour.  Attached are my .ino files for review.  Let me know if it works for you.

[Nathan_B.]

I glad you got it to work.  However, you are still at the mercy of what Serial.print() decides to send via Serial.  It seems that before it was sending more ASCII characters than you were expecting but imagine if it, for some reason, sends fewer bytes than normal.  If this happens, LabVIEW will be expecting the same number of bytes as before but will eventually timeout because it has not received all of the bytes it was waiting for.

IMO, nothing appeared to be "taking too long to answer" before.  I'm quite sure that it was entirely about the number of bytes being sent.  Unfortunately, I would not be able to confirm this without hands on testing.

[PentairDave]

So to your point above Nathan, the case would like like below? Then as you said cast it to a double and divide by 1000 in LabView?  Then we would read in only 4 bytes of data using the send/receive block correct?

    /*********************************************************************************

    ** OneWire Read

    *********************************************************************************/

    case 0x35:      // OneWire Read

      sensors.requestTemperatures();  //Send the command to get the temepratures

        //Get temp in degrees farenheit by index (there are other ways available to do this)

        temp = sensors.getTempFByIndex(0);

        tempInt = (int) temp * 1000;

        Serial.print(tempInt);

        Serial.flush();

      break;

[Nathan_B.]

Ok, here is how I believe it should work along with the attached VI.  This method will give you three decimal places while ensuring that there are only ever 4 bytes sent via serial.  Note that "tempInt" must be declared as a long and not an int.

    /*********************************************************************************
    ** OneWire Read
    *********************************************************************************/
    case 0x35:      // OneWire Read
      sensors.requestTemperatures();  //Send the command to get the temepratures

      //Get temp in degrees farenheit by index (there are other ways available to do this)
      temp = sensors.getTempFByIndex(0);
       tempInt = (long)(temp * 1000.0);  // tempInt must be declared as a long

       // Write all four bytes to serial, MSB first
       Serial.write((tempInt >> 24) & 0xFF);
       Serial.write((tempInt >> 16) & 0xFF);
       Serial.write((tempInt >>  8) & 0xFF);
       Serial.write(tempInt & 0xFF);

      break;

EDIT:  Fixed a minor mistake.  The function number was wrong and should be 0x35 to match the firmware.

[PentairDave]

Thanks Nathan.  I'm travelling this week but I will definitely upload it when I get home and give it a try.  Thanks for your help with the coding (I admit I piece together most of what I have done).

[DavePW]

Hi there Nathan_B

Apologies - been away from all this for a while..

Thought I would try your idea for a slightly more robust way of getting data from the DS1820..

But I keep getting an error (Timeout from the Arduino).

Have attached the vi I put togther to test your solution..

cheers

d

[Nathan_B.]

I made a simple mistake in my VI.  I put 0x23 instead of 0x35 for the command number (23 is the decimal version of 0x35).  I have fixed this above.

Also, it is best to use my VI as a subVI which will allow you to keep it more organized and less cluttered.  Here is my version of your VI (make sure you replace the previous version of the VI with the one that I just posted in my last post.

[DavePW]

Hi - Well we are getting there slowly Nathan...

I'm not getting the error anymore so I think that's sorted..

But it would appear that Maxim/Dallas have a number of similar devices that work slightly differently.

I have discovered that I have DS18B20P and DS1820, neither of which appear to work in Labview with your Vi.

The DS18B20P, is I think parasitically powered through its data pin with the power pin no longer connected. This appears to work using just the Arduino and onewire library but when moving to LIFA and labview I don't get any sensible readings..

Shall carry on here and let you know anything further..

d

[DavePW]

Hi - Any idea how multiple DS18B20 devices can be read and displayed ??

d