MAX31855 component: fails to return temperature and faults "7"

i have a bunch of MAX31855 i got from China a little while back, and some Type-K thermocouples.i have a better MAX31855 board from adafruit, but can't find it. i need to monitor spindle temperature, so i thought this to be the best option. i have tried with long wires, with the MAX31855 near the spindle, and got no results (no temp, fault 7), so i shortened the wires thinking it would help... nope. shortened more... nope.
i have tried two different Chinese MAX31855 boards, and a different thermocouple. the thermo couple is connected directly to the MAX31855 board, with no funky extension wires. the probe is now so far from the spindle, it would sense room temperature, but reports nothing.
i have verified wire connections from the MAX31855 board to the Mesa 7i80HD-25 gpio. i have not tested with an oscilloscope yet to verify signal, but i have use hal show to watch the "lights" blink. my oscilloscope is currently charging... (Hantek handheld portable 2ch, with DMM, and function generator)

second time posting as i think the forum must have eaten the last post here... this time i will copy the post to clipboard...

I thought I saw something you posted about this somewhere?

What's fault 7 and why do you think these parts actually work? Can you test it with someone else's code on an arduino or some such?

according to the comp source code, fault 7, or binary "111" is true for short to gnd, short to vcc, and shorted probe.
i can try with an arduino tomorrow, see what's up. the comp code is mainstream, packaged with LinuxCNC, but i will try an adruino and see.
 

If you have an oscilloscope, verify that it is in fact talking to the chip.
Also, try it without any thermocouple connected, error code should be different ("open"), and verify polarity of thermocouple.

clock signal looks good, CS signal looks good, but the data signal follows CS... i connected the MAX31855 as close to the Mesa 7i80HD-25 connections as i could, thinking cross-talk in my wires, and for a moment, data looked to be streaming data, but returned to following CS, with fault code 7. this is regardless of how or if the thermocouple is connected. i suspected the MAX31855 board, so i tried a fourth, with no thermocouple. still, data follows CS.

i wonder if the clock/cs is too fast for the board somehow? is it possible in the comp source to slow down the signal a bit for testing?

it looks like the driver is bit-banging that via mesa IOs, so no way that would be too fast (500Hz). some other semi-obvious things to check:

* check power supply of max board
* GND connection between max board and mesa board

I would second the GND suggestion, and since the 7I80HD has a GND per signal
I would use as many GNDs as signals to reduce GND bumping.

 

i happened to think to use halscope to view what LinuxCNC is receiving from the MAX31855 board. the data changes with each scope cycle, suggesting it is outputting data, but also dumping the data from a (possible incorrect) fault code. maybe due to my cheap boards.

ground signal tested out fine, though i still have only one wire from the board to ground. i will upgrade if i can't figure out why it is receiving data and dumping it in the trash.

i have the 7i80HD-25 Pullups set to on, at 5V... what are the chances that when the machine is not running that the unprotected data pin is getting fried by the pullup? i checked the schematic, and the data pin of the max31855 board does not have protection from 5v like the CS and CLK pins do. i think tomorrow i will disable the pullups and try a new, unmolested MAX31855 board, just to rule it out. other than my stepper driver signals, the I/O is most all run through a SSerial board, so i don't think disabling the pullups will harm anything.

 
the schematic from adafruit