[lutorm]

Background: My machine uses water cooling with an external radiator, and I'm measuring the temperature of the water with a couple of DS180B20 mounted on the radiator. The fan on the radiator and the 1-wire probes are connected to the machine with a cable that plugs in the back. The fan is controlled with LCDC using the PID plugin. Since that fan is what keeps the machine from boiling, I'm obviously concerned about it failing or, more likely, the cat pulling out the cable to the rad when noone's around. So, I'm setting some safeguards as events in LCDC to shut the system down if it looks like the cooling's failing. Which brings me to the problem:

When LCDC starts, 1-wire probes return "NYR" for temperature until they get their first update. But after that, disconnecting a probe just silently keeps returning the last valid temperature. This is really bad, because it means that if the connection to the fan/temp probe fails for some reason, it'll just look like all temps are A-OK when in fact the cooling has failed and the machine is about to turn into a steam engine.

Can we please have 1-wire probes that stop returning a value revert to returning "FAILED" or something so the condition can be detected?

cheers,

/Patrik

[Matthew Augier]

Ok, they will now display ERR when you get an unexpected result.

[lutorm]

Matthew Augier, on Feb 11 2009, 01:29 AM, said:

Ok, they will now display ERR when you get an unexpected result.

Great! Does that mean there is a new download somewhere? Or was this a statement of intent?

[Matthew Augier]

There is a new version anyway just not uploaded it yet, and no point till I sort out your 4,000 other requests

[lutorm]

Matthew Augier, on Feb 11 2009, 08:41 AM, said:

There is a new version anyway just not uploaded it yet, and no point till I sort out your 4,000 other requests

Wait, I have another one!

[lutorm]

Matthew Augier, on Feb 11 2009, 08:41 AM, said:

There is a new version anyway just not uploaded it yet, and no point till I sort out your 4,000 other requests

Hi Matt,
Did this new version ever get uploaded? The main download still seems to point to a version from 2006... I'm still waiting for the 1-wires to display ERR...

[Matthew Augier]

There is a beta http://www.lcdc.cc/d...s/beta/LCDC.zip been out for a while, sorry forgot to tell you!

[lutorm]

Matthew Augier, on 20 October 2009 - 03:21 AM, said:

There is a beta http://www.lcdc.cc/d...s/beta/LCDC.zip been out for a while, sorry forgot to tell you!

Cool, thanks... except it doesn't work... I unplugged a temp probe and after 5 minutes it still shows the old value. No "ERR". v 1.07.38, right? Any idea what's up?

[Matthew Augier]

Works perfect... if you only use one prob - lol, sorry! Uploaded another beta, try that.

[lutorm]

Matthew Augier, on 23 October 2009 - 03:28 AM, said:

Works perfect... if you only use one prob - lol, sorry! Uploaded another beta, try that.

Thanks, this one works. I now get ERR!

However, something else is broken, because now some of my temp probes display temperatures in the vicinity of -50C - -70C (and I don't have them immersed in dry ice... ). Somehow the temp decoding code must have gotten screwed up. They are changing their values as the system warms up, so it's reading something. It's just not getting the right value out. For what it's worth, the ones that display the wrong values are sensor type 0x28 (DS18B20) as opposed to the ones that are 0x10 (DS1820) which seem to work.

[Matthew Augier]

Sorry! Had some test code in. fixed (I hope)

[lutorm]

Matthew Augier, on 23 October 2009 - 08:08 AM, said:

Sorry! Had some test code in. fixed (I hope)

Ok, we're getting there... This one now seems to work as intended, all probes including the DS18B20 ones are showing reasonable temperatures. But it's still not right: I'm now getting ERR from one of those (only the DS18B20s) very often, like every 10-20 seconds. If I lock at the probe outputs on the screen, I can even see ERR flashing briefly (for like a frame) much more often, every few seconds, but most of those are very short and don't stay. Every now and then, a persistent ERR will show up, and those always last ~7-8s. (I don't know if this is a coincidence, but I have 8 probes connected.)

It feels to me like a race condition, like the thread that writes to the display reads the temps when the thread that reads the probes is updating that field and it gets screwed up. For what it's worth, the previous beta-2 version that had the wrong temperatures did not show this behavior, it only showed ERR when I unplugged the probes. It's also weird how it's only the 3 B20 probes that do this, the 5 DS1820 probes seem stable.

Any ideas? As it is now it's unusable because the "lost communication" tool tray msg event I added pops up literally every 10s.

[Matthew Augier]

My DS18B20 probe is not playing ball for some reason, I can see it but not get any readings out of it?! Hence why all the problems currently is on this type. I've uploaded another version as I spotted a possible cause. Let me know.

[lutorm]

Matthew Augier, on 26 October 2009 - 12:58 AM, said:

My DS18B20 probe is not playing ball for some reason, I can see it but not get any readings out of it?! Hence why all the problems currently is on this type. I've uploaded another version as I spotted a possible cause. Let me know.

This looks promising. The random ERRs have gone away but it still detects properly when they get disconnected. I'll get back to you when I've run it for a while.

Thanks for fixing this!

[lutorm]

Ok, after using it for a few days I can say that in general it seems to work pretty well. There does seem to be a problem though: Occasionally (like once or twice a day), something happens and all probes turn to ERR. This appears to be irreversible, once it's happened they won't come back unless you start-stop the display.

I wonder if this is the same thing I'd noticed some times before where the probes would just hang and display the old value? Of course with the old version it was much harder to notice, now it's obvious (which was the point of the ERR functionality!)

I also wonder if it's somehow related to the fact that the communications with the lcd seem fragile. I think I mentioned before how the bar code characters tend to get switched to some other character set if the display runs for a while. (Like now one bar graph displays a line of Euro signs...) It has also happened that the backlight goes out. The display is still running, you can see the text updating, and stop-starting the display restores it, so it's as if it got a spurious 'turn backlight off' command.

I thought this might be the usb cable, but I've tried with both the internal MO cable and another external usb cable and the problem is the same. It's also persisted across switching to a new motherboard, so the only common elements are LCDC and the display itself. Do you know if these sorts of communication problems are common?

Since stop-starting the display restores things, maybe it would at least help as a stop-gap measure if lcdc resent whatever commands are sent when starting the display (backlight, character set, probe init?) with some interval so the effect of these errors don't just get worse over time.

Incidentally, I also tried lowering the communication speed on the COM port from 19200 to see if that would help, but the display just shows garbage if I set any other speed. Do they only work at 19200?

Thanks,

/Patrik