Ok I'm on 2.9.5. I'll update. I figured that the module you wrote was low level
stuff but apparently I don't know what does what.
C
> On Jun 30, 2016, at 7:34 PM, Paul W Panish wrote:
>
> It looks like Paul submitted my changes in v2.9p6. Support for the
> MAX31850
It looks like Paul submitted my changes in v2.9p6. Support for the
MAX31850 was added in v2.9p2. Not sure what you're saying beyond this,
and I haven't worked with the scratchpad registers.
When I modified this code I basically performed a dump of the data
available in the ow_1820.c module to
In what rev were these made? I'm on 2.9 I believe and neither make sense.
What is the possibility that scratchpad gets read wrong? I have no visibility
into the code but the faults I am observing are suspect, considering everything
reads fine using tmex.
> On Jun 30, 2016, at 3:58 AM, Paul
Sure, sorry I can't be of more help at the moment.
To be clear, with the changes I made, which were done empirically, I was able
to read the hot junction thermocouple temperature using the "temperature"
access string on the MAX31850 development board I had purchased. It also read
properly
Am 29.06.2016 um 23:51 schrieb Paul W Panish:
> All,
>
> I just realized the attachment from my email to Paul Alfille wouldn't
> be readable for anyone not using Postbox on a Mac. Here's a copy of
> the text, sorry about the bad formatting:
>
Thanks for the reply, Paul.
I try to understand all
Am 30.06.2016 um 08:30 schrieb Colin Reese:
>
> Thus, you need to know whether you are looking for a value interpreted
> as a DS1825 or as a MAX31850. Because they are indistinguishable from
> software,
>
They are distinguishable. The DS1825 configuration register bit 7 reads
always 0. The
DS9490R yields similar results. This time only a ground short is
observed. Again, this seemed to read fine into a DS9490R using the TMEX
API through LabVIEW.
Looking at the two datasheets, there is no way to avoid device-dependent
code. There need to be three distinct values: temperature,