Thursday, June 25, 2015

Re-debugging my HVAC

A few weeks ago I posted about my air conditioning woes, that in the end were due to ants infiltrating my AC relay.

I went out of town for a few days recently, and returned home on a 95 degree day to find that my compressor was not running and my 2nd floor was a steamy 93 degrees! The thermostat indicated that it had been running for at least the past 36 hours straight.

I immediately examined the back of my compressor housing and found it covered with ants. Once I had the access panel that covered the relay off, I confirmed that the 3 week old relay was indeed no longer conducting 240V mains power, even though the solenoid in the relay was powered and engaged. Freakin ants!

Apparently 3 week's worth of ant biomass @240 Volts


I had to act fast, it was around 2 in the afternoon, and the parts store, which was at least 1/2 hours away, probably closer to an hour in rush hour, closed at 5. I wasn't about to give up on the part so easily. Uncharacteristically of me, I had thrown out the receipt for the relay, so I'd have to buy a new one. I wanted to see if I could get the existing realy working again. I got a can of compressed air, some isopropyl alcohol, q-tips and fine grit sandpaper. The contacts had a heavy coating of petrified caramelized ant biomass. I was able to remove 95% of it, and my multimeter confirmed reliable conduction through the relay.

With about an hour to spare, I got the relay back in, flipped the breaker, and the compressor purred back to life. I think proceeded to wage chemical warfare on the 6 legged minions wrecking my day and my wallet. I had assumed that the first time was a fluke, or possibly a build up of ant carcasses over time. The second incident made it clear it was all out war. Fool me twice, shame on me.

My second floor cooled about 1.5-2 degrees fahrenheit an hour (I think it did hit around 100F outside later in the day), so by the late evening it was finally quite comfortable again.

--P




Friday, June 5, 2015

Debugging my HVAC system

It's about that time of year in North Carolina where my Yankee Blood compels me to engage the modern marvel known as central air conditioning. High temperatures average in the mid 80's fahrenheit (~29C)  , but can sometime go above 90F(32C). It's also the time of year that you tend to discover something has gone wrong with your air conditioning hardware. Nothing stresses me more, it's one of the more expensive maintenance items facing a homeowner.

Last weekend, while my son was using one of our space heaters Xbox I noticed that the air conditioner didn't seem like it was keeping up. Heart-pounding, I sprinted through the 2nd floor of the house checking the air vents. Sure enough, they all seemed barely cool. We have independent air conditioning units, one cools our first floor, and the other cools our second floor, and the room on our third floor that serves as Anibit's central office.

The "evaporator" and blower part of the AC unit lives in an unfinished, uncooled, part of our third floor. You can usually feel that the ductwork leading from it is cold when running. It was warn. Bad news. Time to let the wife in on it so she can join me in the journey on the potential repair-bill coping process.

I went outside to where the compressor unit lives, and noticed that it was silent. Neither the fan nor the compressor motor was running. The coolant lines where exposed were slightly cool (everything had been working 30 minutes prior). Hmmm. This unit was relatively new. We had it installed about 4 years ago. The prior uint had, once or twice had its starter-capacitor die. The capacitor is only needed to handle the large current draw when the compressor motor first turns on. Last time we had it replaced by a service technician, it ran us about $250. I searched online and found the model capacitor used in my unit. $26 with express shipping.

I'm a genius! I saved ~90% (even more probably, since prices on service have probably grown since the last time). So we sweated it out for a couple days. Luckily, the weather changed mostly in our favor, going slightly below average. It did rain a lot, so the open windows and fans were bringing in a nice sticky-humidity you only really know about if you live in The South.

The capacitor eventually came, and I set upon swapping it out. The old one did have some rust on it, but not excessively. I love electronics, as you are well aware if you read this blog. But I avoid wall mains power as much as possible, because I'm clumsy, and make a mistake or two every once in while. The AC unit runs off the 220V appliance line, so I'm even more paranoid. There was a lot of voltage testing, and ground checking. I wore gloves and goggles, and used plastic-handled tools.

Then came the moment of truth. I had my wife on the phone, inside "Ok, go ahead and set it to 'cool'".

"Ok, it's flashing 'cool', flashing 'cool', ok it turned on"

CLICK! The relay in the outdoor unit engaged.

Nothing.

"Sonofa, I was so sure that was it! Hmm, wait keep it on, let me take some more measurements."


The fan and compressor motors are controlled via a large relay. Measuring the voltage on the output side of the relay revealed that it was not conducting.  "Ah, the relay is bad!'

Not wanting to wait for another part to ship, and having the luck of a little free time in my schedule, I tracked down a local supplier a half hour away for a new relay.

I installed the new relay, still with as much caution, but not quite as much pomp as the capacitor. I turned the unit on, and raced out to check the compressor(my wife wasn't around this time).

Success!

Mechanical relays are relatively simple devices, and this one wasn't very old. I wondered to myself about why it might have died, and why they don't use a solid state relay. Maybe the high current makes it unsuitable, maybe AC solid state relays are prohibitively expensive or complex.

I decided to take apart the old relay and take a gander. The root cause became obvious at once:


Do you see it?

How about a closer look at the contacts (click on the image for a larger view):

Oh the antmanity!

Encrusted at each contact was a mass of dead ants. I have heard that ants were attracted to electricity, especially fire ants. We have fire ants in our area, but I have never noticed them on my property. At the same time, we have ant's in our house 365 days a year. This winter was the first time in 10 years I went more than a week without finding an ant in my kitchen, but they were back in rotation by february. I'm not sure if these are fire ants. If so, they are a little smaller than I typically see them. I'm not a biologist, but it is possible that 220V might cause a drop in ant stature.

The ants were all clustered right at the contact. There were no ants elsewhere in the relay.  One thing I'm not sure is if the ants collected there in one event, eg they picked that fateful day last weekend to throw an electrofest, or, if it was a build up of individual ants that happened to by passing by right when the relay kicked in crushing them. Either way, it's hard to muster up any sympathy for them.

--P

Monday, June 1, 2015

The D programming language, "dlang" ,part 2: Templates

In my last post, I gave a brief overview of my background and interest in exploring the D programming language from a background of a seasoned C# developer. (Also note that I feel all "curly bracket" family of languages developers would appreciate D, it's just that if C# is one of your personal favorite of the family, D may have even more for you to like.)..

Now for the good.


After enumerating so many points lacking in D, you may wonder why I'm so enamoured with it. The language itself has many features found in C#, and also many features C# lacks. In some case's D implementation of a feature is superior to D. Let's give a brief introduction to some of the really cool parts of D that have no counterpart, or aren't done as well, in C#. 

Templates


C# has generics, but as I hope to explain in future posts, they're not nearly as powerful as what D can do. Anyone who does worked a lot with C++ templates and found C# generics lacking, would be pleasantly surprised with D. D brings back the power of C++ templates without all the awkward syntax and linking issues you have with C++. Templates are a concept in D somewhat orthogonal to the definition of a type or method. A template is just a parameterized piece of code. You can place class and method definition inside a template, then those classes and methods are templated. 

public template ListTemplate(T)
{
public class List
{
void add(in T item)
{
     //stuff
}
  //etc
}
}

That illustrates the idea, but if all you really want is a old fashioned template class, D, being pragmatic, has a shortcut:

public class List(T)
{
void add(in T item)
{
}
}

In addition to classes and functions, you can declare variables and type aliases inside templates too.


You can have value template arguments as well, something that doesn't exist in C#.

public class SillyArray(int size)
{
int[size] _myArray;
}

Now, the size parameter is part of the type of declared variables. If you've never worked with template value parameters before, it might not seem obvious what you gain from them. Because it affects the type of the class, just like a type parameter would, you could do things like define a range type:

public class Range(int low, int high)
{
int _value;
this(int value)
{
assert(value >= low && value <= high);
_value = value;
}
}

Now you have a type where the legal range forms part of the type itself, and the compiler can distinguish the legality at compile time.

Let's define an alias, akin to C++'s typedef though more powerful, to reference the type:

alias liquidWater = Range!(32, 212);

Now later on we could define a variable,

auto myCup = new liquidWater(4); //error, out of range.

In this case, the compiler can determine that the assertion will fail, and so it flags it as a compiler error. This is another great point about the D compiler is that it will evaluate assertions at compile time when it has enough information! When it doesn't it will still evaluate it at run time.

Type constraints.


C# does have a limited type constraint system for generic type parameters:

class foo<T> where T : IDisposable where T : new()
{

}

This lets you declare that what type is used to instantiate foo must implement IDisposable, and that it must have a parameterless constructor(this feature seems like an odd special case to place in the language, I always wondered why they stopped there).

In D, it gets waaaaaay cooler than that. Essentially any logic you can supply that can be determined entirely at compile time can be used as a type of value constraint.

Going back to our range type, lets say someone did something like this:

alias invertedRange = Range!(100, 0);

Notice how the "low" parameter was greater than the "high" parameter? As the designer of the Range class, you never intended that. How might you prevent someone from doing that in a way that it's caught at compile time?

You add an template constraint expression:

public class Range(int low, int high) if (low <= high)
{
int _value;
this(int value)
{
assert(value >= low && value <= high);
_value = value;
}
}

Now the compiler will not allow the inverted range alias declaration. As long as the logic can all be determined at compile time, anything is possible as a constraint, even function calls!:

bool isLower(int a, int b)
{
return a < b;
}

public class Range(int low, int high) if (isLower(low,high))
{
int _value;
this(int value)
{
assert(value >= low && value <= high);
_value = value;
}
}


This syntax really gives you a rich language for expressing contracts between parts of code in ways that I have not seen in other languages. These are compile time contracts, validation is immediate, not through unit testing or function tests, but before you ever have executable code. Your intention as an API designer can be very explicit. That, is what make me smitten with the language.

I''ve barely scratched the surface of what you can do with D's generic programming system. If you want to know more, check out the very well written online book "Programming in D" by Ali Ă‡ehreli at http://ddili.org/ders/d.en/templates.html

Until next time,

--P



The D programming language, "dlang" - Part 1

I've started a new project recently, related to a product I want to develop. It's a software-only product, but it's electronics related. I thought it would be fun to chronicle the development and design progress.

I'm working on a tool that I don't think really exists yet, at least in the way I envision it. As usual, I'm going to be coy about specifics until I'm ready to announce it.

I've mentioned in the past that I'm a programming language geek. I still feel that C# is one of the overall best, most productive programming languages out there, and it continues to get better with each new edition of the language. Now that Microsoft has let Linux and OSX join the .Net family (even if they are still somewhat still the red headed step kids, which I feel will change in the not too distant future), I'm hopeful that developing desktop code on .Net will become a reality.

I have had it on my list forever to give the "D" programming language a go, and this project presented itself as a good opportunity to try it out. D is a non-main stream programing language that has been around since 2001. Despite it's fantastic design and feature set, it's adoption has been slow and steady.

To make a long story short, I had it as a goal to use D to develop my new software. I admit that a small part was driven by the desire for something new and shiney, but I have spent a decent amount of time researching that language. I think that D has some of the right set of features for large and medium sized application architectures. D has a bag of features at your disposal that very few languages have and have done right so that you can pragmatically "get stuff done".  Scala is another contender in this area, though in my experience Scala veers a little too much into academic theory and a little shy on the pragmatism end of things (for example loop flow control keywords were omitted because the language designers felt they encouraged imperative programming style.). At the same time, Scala, being a language that targets the Java virtual machine, is encumbered with some of that platform's limitations.

In the end, I decided to stick with C#, but not without a heavy heart and solemn face. I still have D in my heart, and will take another shot at it in the near future, it just wasn't the right fit in this case. The primary reasons for ultimately goign back to C# were the Framework support, especially GUI support.

Note that I'm be no means a D language expert. I've never authored any sizeable application in it. I'm still learning it. I'm bound to make a mistake or two here, please call me out if you spot something!

Comparison to C#