Friday, May 10, 2013

Ultrasonic cleaners

an ultrasonic cleaner
Ultrasonic cleaners function by bombarding items with sound whose frequency is beyond the range of human hearing. A discussion of the specific mechanism of cleaning is complex and beyond the intent of this post. What follows are some pointers when using a simple ultrasonic cleaner.

Overview

Ultrasonic cleaners will impart their cleaning action to the objects submerged (normally in water) inside them. As such you will only be able to effectively clean items which will fit inside the cleaner. Items with unusual aspect ratios (such as rifle barrels) will likely require a more specialized unit as their shape will not be as common.

Some units will also have heaters for heating the cleaning solution. This is an excellent feature and greatly accelerates the cleaning process. The unit pictured at the top of this page will heat the cleaning solution to about 176F (80C). For comparison most residential water heaters will heat your hot water supply to 120-140F. If you use the heating function some of the cleaning solution may evaporate from the unit and condense on the inside of the lid. Thus care should be taken when removing the lid especially if the condensate may contain corrosives (more on this later).

Cleaners will generally come with some type of wire basket for adding and removing items without getting your hands in the cleaning solution. In addition larger units will have a drain valve for emptying the cleaning solution when it becomes fouled or unusable.

cleaner interior

Usage

Simply place the items inside the cleaner, then turn it on or set the timer. The unit does not need supervision. Certain types of items are more easily cleaned in these cleaners than by other methods. Objects having intricate shape or edges cleaning brushes could get caught on are good candidates for ultrasonic cleaning.
electric razor blade assemblies are easily cleaned in an ultrasonic cleaner
Often cleaning will be more effective if some type of solvent is added to the water to form a more effective cleaning solution. What you can use in your cleaner will depend on what it was designed for. Most cleaners can be used with household detergents.

cleaner drain valve
More corrosive/awesome cleaners like sodium hydroxide should only be used if the unit is intended for use with them. Even if your cleaner is constructed of a metal body resistant to attack by corrosives (like stainless steel) other components, like the drain valve seals, may not be. In addition a single successful use of a cleaner with a powerful solvent does not indicate the unit is not suffering damage. While not immediately destroying the unit some substances may greatly reduce its working lifespan.

Ultrasonic cleaners come in a variety of sizes and prices. The one picture in the article runs about $400. Other smaller units can be less expensive but may not come with a heating function.

Wednesday, May 8, 2013

'Exception' does not denote 'Infrequent Occurrence”



NOTE: this will generally pertain to C# but applies to any programming language which uses similar exception handling (for example Java). This article covers a few misconceptions about exceptions and is not intended as a complete reference. In depth study of this important programming aspect is highly recommended. 

Overview

The exceptions a method throws are as important as its parameters or return value. They are part of your contract with the user, even if you are not required to declare them as part of your method definitions (as you are in Java). Too often methods are completely written before any thought is given to the exceptions it should throw. This unfortunate behavior leads to a less than ideal interface for the user.

Many developers believe, and in many cases are taught, exceptions exist to handle rare or infrequent conditions encountered during execution. The truth is as developers we have no control over the circumstances our code is used in beyond the compiler enforcing the existence of our parameters. As such we can never say what the frequency of any use case may be. Thus we can never say if any given case is rare or common.

Usage

The correct use of exceptions is to convey our inability to keep our contract with the user as defined by our method signature. Let us consider the following method signature from the Int32 type:

public static int Parse(string s)

This method takes a string representation of an integer and returns its integer representation. Viewing the documentation reveals it throws the following exceptions:

ArgumentNullException – thrown when s is null.
FormatException – thrown when s cannot be converted to an int.
OverflowException – thrown when the representation of s is beyond the capacity of an Int32 to represent.

Each of these exceptions represents a condition which prevents the method from honoring its contract, returning an integer representation of the string parameter, to the user. There is a different exception for each semantically meaningful mode of failure. That is to say each exception represents a different reason the conversion failed giving the caller the ability to make a meaningful decision about how to proceed. The OverflowException can represent failure due to either a value above or below what can be represented by an Int32. As the user would not take different actions based on whether the value is too big or too small we have just one exception to represent both instead of an OverflowHighException and an OverflowLowException.

Example

Using these ideas let us design our own method. Let us suppose we have a type which represents a temperature probe. We might start by writing a class method with the signature:

public float GetTemperature()

[Note: normally we would use a property here but for demonstration purposes we will make this a method. Also, interestingly enough, the CLR doesn't know about properties so C# converts them into methods during compilation]

What exceptions should this method throw? Anything which violates our contract with the user should be represented by an exception. In this case any condition which would prevent us from returning a temperature will need an exception. We could start with the following:

TemperatureProbeNotAvailableException – thrown if our connection to the probe is lost.
TemperatureOffScaleException – thrown if the probe provides a value beyond what its specification states it can accurately measure. 

Previously when considering the Parse method we said there was no need to have multiple exceptions to represent the high and low possibilities for the OverflowException. Here we also have a single exception to represent an out of range condition. Considering further is there any action our users might wish to take based on whether the temperature probe is off scale high vs low? In this case there is.

If the probe were attached to a heating or cooling system knowing which direction the temperature is off scale would be very meaningful information. For a more awesome example let us say this was a very high temperature probe in the exhaust of a gas turbine engine. Many such probes do not operate correctly until they reach a minimum temperature well above normal ambient. An off scale low condition might be normal while the engine was offline or idle but an off scale high might indicate the engine was running beyond specification and should be throttled down.

Since the direction of the off scale condition is potentially meaningful to the user we should provide exceptions for these conditions.

public class TemperatureOffScaleHighException : TemperatureOffScaleException
public class TemperatureOffScaleLowException : TemperatureOffScaleException

Though the off scale direction of the temperature probe could be useful to the user this might not always be the case. By extending the high and low exceptions from the TemperatureOffScaleException we give the user a choice  If they do not care about the direction of the off scale condition they can choose to catch the base TemperatureOffScaleException. Otherwise if they have code to handle the high and low conditions differently they may catch these derived exceptions in separate catch blocks and deal with them as they see fit.

Aren't Exceptions Time Expensive?

Depending on the environment the throwing of exceptions can be time expensive, especially if they repeatedly do so in tight loops. The previously mentioned Int32 type addresses this with the TryParse method. 

public static bool TryParse(string s, out int result)

This method does not throw a FormatException. Instead if will return a boolean indicating if the conversion was successful and if so it will provide the converted value via the result out parameter. By using a boolean instead of an exception this call avoids the cost associated with handling an exception.

Does this method keep its contract with its user? Yes it does.
Whereas the Parse method implies by its signature it will return a converted value TryParse implies it will attempt a conversion. This distinction in naming is important in creating an API your users will be able to easily understand.
A simple look through the FCL will demonstrate the occurrence of TryX is very limited. While the TryX methods seem to match the X method in capacity and excel it in speed it fails in code simplicity. The code necessary to support the TryX method is more cumbersome than the a simple X method.

Conclusion

There are various opinions about the role of exceptions and how they are used. What I would like to convey here is exceptions are an important yet overlooked aspect of development in environments which support them. A more in depth study than what is presented here is recommended though simply considering them at the outset of development instead of as a postscript will help in API design. 








Monday, May 6, 2013

Dealing with partially lighting gas burners

The patient needing attention
The above is my stove. It is an old stove. I think I have used this stove once in five years. I don't really care much about the stove. Unfortunately someone recently pointed out to me the burners on the stove do not light correctly. So in accordance with my 'fix ALL the things' policy it was torn apart until fixed or destroyed, whichever came first. Mercifully this ended in a fixing and what follows is what I discovered.

Overview and Operation


stove with the top removed
Opening the top of this stove is as simple as lifting the top from the front. Once raised the top can be slide off of its hinges exposing the amazingly primitive bits underneath. The gas line comes in from the upper left and travels down the left side to (what I think is) a regulator, a flame arrester, or both. This gas line then takes a 90 degree bend and forms the main fuel rail at the front of the stove.
Each of the four knobs for the burners and the one for the oven all open valves off of this line to supply fuel to their respective elements. When you turn on a burner fuel travels down its supply line, pulls some air in (more on this later), and fills the burner element. Turning the knob on also starts the igniters located in between the burners which share it (both igniters fire regardless of which burner you are lighting).


closeup of the ignition flame ports
Each burner has a set of flame ignition ports on the side facing its igniter. Fuel from these ports travels down a hollow tube to the igniter. Once lit the flame travels up the tube to the ports on the burner. From here the flame travels up to the closest main burner ports and then around until all of the element is lit. 

Problems and how to clean them

Assuming your ingiters are working (you can hear if they are firing and if they are not you have an issue which will not be covered here) the most likely cause of the burner either failing to light or not lighting completely is ash build up in the flame ports. To fix this you simply need to remove and clean the burner element. For my stove the elements can be removed without tools. 

Start by removing the spring clip for the burner. Then rotate the burner until it is free of its supports and then slide it off of its fuel nozzle  With the element free simply clean it with a stiff brush then blast some compressed air through the gas inlet. When cleaning the burner don't forget to clean the vertical ignition ports on the side in addition to the horizontal main ports at the top. Do not use any tools which could change the shape of the flame ports. Marring the ports on your burner will give you other issues not addressable with cleaning. You will want to use the compressed air outside as it can blast a surprising amount of ash out of the burner. 

Elements can acquire a good deal of grease and other nastiness on them over time. Unless the offending matter is blocking a port it is not necessary to remove it. If you do choose to do a deep cleaning of a burner remember it must be completely rinsed and dry before it is re-installed.

Why is there a slot in the fuel line?

air induction port
These port are intentional. All combustion requires fuel (in this case natural gas) and an oxidizer (normal air). When gas passes through this segment of tubing it creates an area of low pressure around this port (via venturi effect) and pulls in the surrounding air. This fuel air mix is delivered to the burner for combustion. 

Normally these ports are too far from any opening in the stove top to get dirty so you likely will not need to clean them. Just be aware of them when working on the stove as anything blocking or interfering with them will cause issues.