MAX31855_test.py problem

[vichente1]

When I run MAX31855_test.py first time Temperature is 0, but when run again the temperature is correct. What is the problem?. I print the max31855.py library value and return 3 bit values when I try it the first time, later return correct 26 bits values for 14 bits thermocuple temperature and 12 bits internal temperature.

[alexanderhiam]

Interesting, are you sure it's 0 and not None?

The lowest three bits are a status code, which I'm only looking at when the fault bit (bit 16) is set, in which case it returns None instead of a number (because any number could be a valid temperature). My understanding is that those status bits shouldn't ever be set when the fault flag is not, but perhaps I missed something in the datasheet...

[vichente1]

I'm sorry is not 3 bit value is a 8 bit random value. The 3 bit condition works perfect but it works at second time (Only when I boot Beaglebone Black and run for first time MAX31855.py doesn't work). I want to use your max31855.py library with machinekit, I made some changes to run without bbio libraries, only with serbus library and I have the same results (it works later than second time).

I export SPI0 device tree overlay to /sys/devices/bone_capemgr./slots, when it load. I run cat /sys/devices/bone_capemgr./slots to check.

spidev1.0 and spidev1.1 show up in /dev

spi1.0 and spi1.1 show up in /sys/bus/spi/devices

max31855.py library running for first time with disconnected thermocouple

I reboot Beaglebone Black again and I do the same previous steps.

max31855.py library running for first time with connected thermocouple

Python files:

python_MAX31855.zip

Any suggestion will be very much helpful.

Thank you in advance!

[alexanderhiam]

Oooohhhhh, I misunderstood, I thought you meant just the first value was 0, but it's every value the first time you run it.... weirder.

You know, that reminds me that at one point I did have an issue pop up with that library, and I think it might have been 0 values like that...

Perhaps it has to do with the state of the SPI module before it's configured for the MAX31855? I'm curious, can you try moving the spi config stuff to the __init__() method with a bit of a sleep after:

  def __init__(self, bus, spi_cs=0, offset=0):
    self.spi_bus = serbus.SPIDev(bus)
    self.spi_bus.open()
    self.bus = bus
    self.spi_cs = spi_cs
    self.offset = offset
    self.error = None

    self.spi_bus.setClockMode(self.spi_cs, self.SPI_CLOCK_MODE)
    self.spi_bus.setMaxFrequency(self.spi_cs, self.SPI_FREQUENCY)
    self.spi_bus.setBitsPerWord(self.spi_cs, self.SPI_N_BITS)
    self.spi_bus.setMSBFirst(self.spi_cs)
    self.spi_bus.setCSActiveLow(self.spi_cs)
    time.sleep(1)

that way it'll separate any glitches that might occur from the first transaction. It's a long shot, since that would probably only explain a single bad sample, but maybe....

Another thing you could try is powering the MAX31855 from a GPIO pin (it draws 1.5mA max, so it shouldn't be a problem), in which case you can power cycle it (and give it a hundred ms or so to stabilize) before starting to read from it.

[vichente1]

Hi, sorry for my bad english, I don't speak english very well. I tried all and it doesn't work but I changed serbus to spidev library and now it works.

Thank you for your great MAX31855 library.

Python files:

python_MAX31855_spidev.zip