Beginner welding experience - Thermal Arc 211i

I have wanted to learn to weld for sometime - I have never handled one before this.  I finally broke down and purchased a Thermal Arc 211i which is a 3 process (DC) welder - TIG, Stick and MIG (gas and flux-core).  I researched welders for over a year and was finding many positive references to Thermal Arc machines.  I was originally going to get the 181i but decided that the lack of 110v support in it was enough of a differentiator to drive me to the 211i which can work with 110 or 208/220v.

Not to spoil the rest of the post but I REALLY like the welder.

I purchased the machine from CyberWeld - they had a good price- not the absolute lowest but close and I found no indications of problems with their support which was not true of a place with a slightly lower price at the time.  I received the unit pretty quickly and without any issues.  I put in the paperwork to get a free auto darkening helmet (while supplies last..) and received it in around a week which was pretty nice.  I had already picked up some cheap tools/helmet/smock/gloves from Harbor Freight as well but this is working out well - I am going to try and teach my kids a little as I learn as well.

Best features of the Thermal Arc for me:

• 110v and 220v support. 
• Wonderful value - amount of functionality versus price is great.
• Can get MIG spoolgun, TIG torch and foot control when ready
• Not outrageously heavy and has decent handholds on front & back
• Documentation is pretty good
• components feel pretty solid and of good quality
• setup chart seems close in my limited use

 Lows for me:

• The supplied SMAW rods were marked for type (6013) but not diameter.  My lack of actually checking the size wasted several hours of my time, caused some heartburn and almost resulted in an unnecessary support call.  I was trying to verify things were working by welding a small piece of scrap but was using too low of an amperage for the rod and couldn't get a spark.
• Maybe a minor low that the MIG gun trigger is pretty sensitive.  I may have to just find some less bulky gloves.

My first actual project was to create a second lower wood loft for my spare wood, piping, etc in the garage.  I was making this out of angle iron, 1/8" flat stock and 1" square tubing using .035" flux core MIG wire.  Setting up the 4" spool was somewhat challenging to me - don't try it when you are tired already.  There is a fairly strong spring you must work against to attach the spool - a bit of an Abbott and Costello type comedy action going on for a little while.  I'll spare everyone the details for now.  I do wonder whether it would have been easier getting the large 12" spool on - maybe try someday.  As a side note, I picked up some Bosch  metal cutting bits for my jig saw and that worked really well for this project.  My welds so far are quite ugly - lack of skill/experience and the flux core combined make that unavoidable. 

I think getting the spool tension and such just right is a bit of an art form.  One of my first weld attempts resulted in the wire punching into a piece of flat stock hard enough to pop it loose from the welding magnets I had holding it in place.  This was after I got the helmet settings to the point that all light wasn't blotted out completely when the arc was going.  I'm starting to get more comfortable with the helmet and feel I can get down to what some of the books/manuals state as a recommended shade value for the helmet.  I was able to see the weld pool to some extent on my last welds but couldn't see far enough ahead to tell when I was about to run off of the object.  Nothing like going along fine and then having 4+ inches of wire hanging out in space.  At which point you bump the target object and make a mess.. not that I know anything about that.

This loft was a success and I have some new steel studs I am going to use for my overhead loft which is currently attached to the garage ceiling at the outside corner (no pole to floor).  I am going to switch from ceiling attachment to a pole (steel stud)  - I am getting a bit concerned about the weight I have up there possibly causing issues with the ceiling/wall.

Planning on looking for some steel later this week to try and build a welding cart.  Seems like a good way to practice.

All in all, the Thermal Arc 211i is a really nice machine and much more capable than I am for now.  Looking forward to practicing and learning TIG as well.  I may try the SMAW process a bit as well but my first successful attempt at that was not nearly gratifying as using the MIG gun.

[Edit 2014/02/25] Welding cart/table 3/4 "complete".. a bit of a joke since just like computer software, there is always "one more thing" you can add or change.

Summary of cart/table:

• 18" x 30" main cart top with ~ 18" x 36" base
• height adjustable folding side extension 18" x 36" - folding extending legs with pins to lock extension
• 1 drawer [side]
• 3 extendable/removable hanger poles - general hanging needs but also thinking about using with welding blanket for special needs

construction

• 1/4" plate for tops
• 1" tubing & 1/4" thick angle iron for the basic frame.
• spare pieces of "super strut", angle iron, a smidgen of flat bar for the folding/height adjustment aspect of the extension table. The super strut pieces form a guide for 1" tubing which slides up/down where the extension and main cart meet.  The tubing is too small for the super strut cavity so a small piece of flat stock was hand fitted and welded to the tube so that it doesn't rotate, etc when changing the height.  I might try to add a diagram showing this at a later date - a bit hard to describe.
• The drawer body is 20ga steel.  Using some slides from Lowes which are ok..  Some angle iron and 3-4" wide bar stock are welded to the bottom of the cart top.  I attached the slide to the flat stock with rivets.  I also attached the drawer body to the slide with rivets.  I almost hate to describe the drawer body because folks will probably fall down laughing.  Anyways, just think of it as Christmas present wrapping.
• Cart bottom is 20ga steel
• The poles are 3/8" stainless steel which slide in short pieces of 1/2" tubing with a piece of nail in a through-hole supporting them when raised. [NOTE: Practical example of knowledge - the stainless is not magnetic so the magnetic pickup was useless - not fun when you know you must cleanup WELL so the kids don't run through it with bare feet!]

This was really an experiment and nothing like a production design.  It won't win any awards (although my kids said maybe an "ugly weld" award might be possible).  I did learn a lot and the result is extremely useful even with a few warts here and there.

Todo:

• add 2 more drawers [on front] - still experimenting as I create these without any reliable tools for bending.
• add 1 more extendable/removable hanger pole
• Modify rear base area to support Argon/CO2, etc tanks [flat plate as bottom and add straps]
• Replace current rear casters with something larger and easier to roll over transitions between the driveway/garage/sidewalk.  This will be even more important once I have shielding gas tanks.
• Considering making the extension table a little more flexible in height adjustment by using cam levers [search 'cam lever' on Grainger] on the legs.  Trying to determine if they can handle a reasonable amount of load from hammering and such on the table top.

Here is the "final" cart; I don't think I am going to add argon/co2 storage to this since it has gotten extremely heavy.  The only other "someday" change is better height adjustability of the side folding/extension table.

I'll have to start dreaming up plans for handling argon/co2 tanks sometime.  I would love to try some TIG work  but I think I exceeded my hobby budget for "a while".  I only have DC TIG capability so while it is possible to work with aluminum per a bit of research; it looks like the results won't be as clean and it may take more effort to get even "reasonable" results.

Linux/Unix application configuration methodology

We are experiencing substantial application sprawl at my current employer while staffing either stays stable or decreases.  The combination of 9-5 normal development/operations/support combined with more after hours time for production operations is leading to increased human error and general difficulty in managing the movement of application & settings between dev/test/prod environments.  A contributing factor is the fact that each application has a slightly different method of handling configuration data.

This lack of a standard template and methodology for handling configuration was not sustainable.  This lead me to identify a number of core issues and work toward a process the mitigates them.  Some common problems include mismatches of configuration data between servers in a specific environment, changes not getting propagated between environments and incorrect configuration propagating between environments.

The mitigation methods include:

• Use of a source control system (Subversion) to contain all application configuration/settings data.
• Configuration files named based on server name/environment - typically for properties files
• Spring XML configuration files keyed by environment
•  Environment setup broken out into up to 3 distinct files - one for each of application, server and environment.  These files are named based on the type of data.  The general idea here is that application wide settings reside in a shared application wide (all server, all environments) file.  Any environment specific profile setup is in a file named based on the environment type.  Each server has a file based on the server name and is primarily responsible for setting the environment type.
• A shared profile processing driver that each server uses to "source" the appropriate configuration files.  There are some utility functions shared between all systems. The application wide environment setup profile plays the role of the driver and used the utility functions to process the server specific environment profile first, followed by the environment specific profile and finally completes its processing of the application wide environment settings.
• Utility functions include an item which displays the server name, application name and environment type.  This is called at login and is available to operators to quickly verify they are operating on the system they expect to be on.

This methodology is combined with the use of NFS in production and sometimes non-production environments.  There is an additional benefit of this combination in the production environment.  There is no direct network server to server communication between the production and disaster recovery (DR) environments but the production NFS storage is replicated to the DR site.  By including all DR environment settings/configuration on the production NFS storage, it automatically gets replicated out to warm DR servers.  Some additional shell scripting, a couple cron jobs and a standardized but special app deployment method result in the ability to have the DR application/web servers automatically deploy the production application versions in an unattended fashion.

I am still evaluating this mechanism in combination with Jenkins jobs and remote nodes for a more automated production deployment. 

Overall, there is a little learning curve for my team but this is already providing some benefits including traceability of change, identification of unapproved changes (run Jenkins jobs which check for correct versions of settings and local server modifications) and easier difference identification/handling via Subversion diff/merge functionality.

One other item of note is that the Subversion "externals" functionality is somewhat key in the sharing of some items which need to be available to all applications but would be awkward to manually synchronize or duplicate. 

Java code - correctness and consistency

It has taken nearly a month to cleanup most of the data access code (DAO classes) mainly produced by a consultant.  I will say that some of the changes are "nice to have" items but there were plenty of "must fix" items with a few of those still remaining.  The fact that there is lots of client code, little documentation and a lack of coherent conventions drove me to start looking for ways to get things in better order and keep them that way.

The initial steps in the cleanup of the "must fix" items:

• Implement the interface java.lang.AutoClosable in the base class of all the DAO code.
• Provide a factory type instance into the DAO instances which acquire DB connections instead only when absolutely needed (which isn't 100% of time in these "DAO" classes).
• Replace the previous DAO connection close() logic (which was never in try/final blocks)  with the Java 7 try-with-resource constructs everywhere.

So at this point, we have reduced the amount of DB connections being tied up needlessly and have plugged all the known potential DB connection leaks. 

Some other changes involved conversion from one cache solution to JBoss Infinispan 5.x and a different method of handling cache keys for the DAO data.  I ended up with a somewhat more complex solution for this to help reduce the chance of keys being duplicated and used for different data items.  The Java enum type is great for this and being able to implement interfaces on them provides a lot of flexibility.

The next problem was how to sort out data flow, mutability and nullness consistency.  I try fairly hard to keep a certain consistency in what I return from DAO methods.  I find that returning null tends to produce more errors through forgetting to check for it in all cases.  This can be mitigated by not returning nulls whenever it makes sense.

I find this most useful when dealing with collections - return Collections.emptyList() (or use similar methods for sets and maps) instead of returning a null where there was no data to return.  This works when you return something the client doesn't mutate.  Other use cases might be handled by returning a new mutable empty list (but only if truly needed), requiring the client to make a copy of the object or possibly having the caller provide the collection.  Wrappers and immutable collections are quite useful to prevent modification to the returned object when there is content in collection.  Consistency is helpful to fellow developers who may not know the application or frameworks as well as the original developers.

One deficiency of Java is that it is impossible or nearly so using just the core language itself to fully define mutability constraints and expectations.  Most of the time this must be done via Java doc with the hope that it is actually correct.  The current project I am trying to sort out lacks usable Java doc or comments on what the best constraints should be.  I am starting to work with an annotation framework to help document, report and enforce various constraints (mainly nullability and mutability).

      http://types.cs.washington.edu/checker-framework/

I am trying to utilize it via an Eclipse plug-in with some success (but not complete).  I think the nullability checks are working but I am running into problems with the mutability annotations.  I know there are some limitations using Java 7 which should be removed or minimized with Java 8.  It could also simply be related to the Eclipse plug-in or the use of Eclipse 4.2.  The embedding of the annotations in Java comments has both good and bad aspects. I like not having to worry about the build server having the annotation jars, etc but I would like Eclipse to tell me when I make an obvious mistake well before I try to generate and analyze results.

If I am able to get this working correctly for my main cases, it has the potential to provide a much higher static gurantee that object instances are only being used in the way I intended them.

Other useful references are:
JSR 308: Annotations on Java Types
JSR 305: Annotations for Software Defect Detection
Java Modeling Language (JML)

Once I am able to get a more rigorous definition of how the DAO data is used in the current application, we can either further improve the plain JDBC based solution, move to an internal framework which uses Apache DBUtils or possibly move to Hibernate.

I am slightly leaning toward Hibernate because I think it will reduce our custom code, remove/reduce the need for the manual caching of data, possibly improve performance and generally reduce the number of sources of problems.  I only say "leaning" until I gather enough info and prototype & evaluate some partial solutions for comparison.