March 2013

March 29, 2013

DIY in the Lab

Things break in the lab. Here’s how to protect your equipment, and what to do when it stops working.

By Jeffrey M. Perkel | March 1, 2013
 
tl_files/labsquad/blog_images/diy/labtools-2.jpg

With NIH funding fewer than 20% of the research grant applications received in 2011 (the most recent data available) and little hope for improvement in the coming year, researchers must squeeze what they can from every dollar. For some cash-strapped labs, that means buying used instruments instead of new, keeping equipment running long past its warranty, and jerry-rigging existing lab gadgets that might otherwise be scrapped.

When such equipment inevitably fails, it puts yet another strain on already tight budgets. Researchers facing service calls costing hundreds of dollars an hour may feel obliged to delay repairs, only to find that a service tech may not be readily available. Even in the lab, time is money.

There is an alternative. Lab workers armed with a bit of mechanical know-how and some basic tools can sometimes tackle repairs and problems themselves. Not every repair can or should be handled in-house, but those that can will get the lab up and running quickly and cheaply. The Scientist spoke with equipment repair technicians and core facility directors about the kinds of repairs that researchers can and cannot do on their own, and some obvious, but oft-ignored, steps they can take to avoid problems in the first place. Here are their suggestions.

1. RTFM (READ THE F**KING MANUAL)

Like cars and computers, laboratory equipment almost always comes with a manual (either printed or as a PDF). And, as with cars and computers, researchers often toss those manuals in the trash or “file” them in a drawer. Here’s a better idea: as they say on the interwebz, RTFM. Manuals outline recommended maintenance and cleaning schedules, provide troubleshooting tips, and demystify error codes. (Lane Smith, President and Senior Engineer at Phoenix Technical Services, an equipment repair company that serves the University of Mississippi, suggests storing manuals together in a safe place, or as PDFs in a common folder on a lab computer, for easy retrieval.)

The maintenance suggestions these manuals lay out may surprise you. Rebecca Wood, co-owner and vice president of Southern Medical Services, a medical and lab equipment repair firm that serves south Texas, notes, for instance, that some vacuum pump manufacturers specify in their manuals that vacuum oil should be changed after every use. Yet many researchers reuse the oil until it gets dirty—a practice that could potentially cost the lab big bucks. “If you had a vacuum pump that quit and you sent it in for repair and it had black gunk in the oil, they would say you’d voided your warranty,” Wood says.

2. Clean up once in a while

An ounce of prevention is worth a pound of cure, they say, and that’s certainly true in the lab. Dust accumulates on computer parts, ice accretes inside freezers, and carbon dust builds up inside centrifuges and stir plates. Taking care of these issues before they become problems can save a lab some money in the long run. “If you use a [centrifuge] rotor, make sure it’s cleaned afterwards,” says Craig Folkman, a field service engineer atBioNiQuest Lab Services in Danville, Calif. “Make sure O-rings aren’t cracked, and change them as necessary. If there’s a spill, clean it up, don’t let it sit there.”

For mechanical devices that use brush-based (as opposed to induction) motors, such as vortexers and microcentrifuges, Smith recommends investing in a small vacuum cleaner to clean out the carbon dust. (Smith notes that replacing a worn set of motor brushes is a relatively simple task that researchers can do themselves. For one of his techs to make a lab call would cost $200 for an hour of labor plus the brushes ($20–$50 for a set), not to mention travel time.)

Invest in a can of compressed air to clean computer fans and cables, or tracks on liquid handlers. And clean the air filters on lab freezers regularly (they are usually easily accessible on the front of the instrument). “These are fairly expensive pieces of equipment, and some scientists will have their entire research life in these things,” Smith observes. Cleaning or replacing the filters will keep the compressor working properly and prevent it from overheating.

Another easy bit of maintenance: Defrost freezers regularly. “Try to do it once a year, because you will either do it on your own schedule or on the instrument’s—at 2 a.m. on a Sunday morning.”

3. Establish a maintenance schedule

“My feeling about lab repairs is really trying to avoid them,” says Tim Hunter, Director of the Advanced Genome Technologies Core at the University of Vermont. Hunter recommends lab managers ensure that each piece of equipment be kept on a routine maintenance schedule (often outlined in the operator’s manual).

For instance, in his facility, one worker’s job includes tracking the background signal in the lab’s real-time PCR machine, to make sure the instrument is operating correctly. Another bleaches fluid lines in the array reader between runs to minimize cross-contamination concerns.

Another commonly overlooked task, Hunter says, is defragmenting the computer hard drives attached to lab equipment. Hunter suggests doing that monthly. “[These are] things that people take for granted and just don’t check, but [that] can really impact things when you least suspect them.”

Wood recommends copying and laminating the schedule for each piece of equipment and affixing it on or near the machine, so that everyone in the lab knows what needs to be done, and when.

4. Build a basic lab-repair toolkit

Charles T. “C.T.” Moses, an independent consultant in Framingham, Massachusetts, has been offering seminars on laboratory equipment repair throughout the Northeast since 2004. The handout for his seminar includes a suggested laboratory tool set for taking on most basic repairs (see also: www.chastmoses.com/tools.html). To wit: Flashlight; multipurpose screwdriver (slotted and Phillips); small vise grips, needle-nose pliers, and side-cutter pliers; a small crescent wrench; small clamps; scissors; measuring devices (scale, tape measure, or ruler); small hammer; pocket knife; multimeter; polarity tester (to test electrical circuits); and a lockable tool box.

Other items you might want to have on hand are lubricants (e.g., oil or WD-40), compressed air, a set of American and metric Allen and socket wrenches, a drill, and electrical tape.

5. Try the obvious

When something goes wrong, the most obvious solution sometimes is the right one. So, if a piece of equipment suddenly stops working, make sure it actually is plugged in and that the outlet is working; even in the lab, plugs come loose, fuses blow, and circuit breakers trip unexpectedly.

Smith recommends doing a quick and commonsense “self-assessment.” For instance, if the −80 °C freezer is suddenly warming up, did anyone recently perform an inventory during which it was left open? Ditto for the cell culture CO2 incubator.

Next, see if restarting the instrument and/or attached computer solves the problem. Or, if it is a mechanical device, see if you can identify something obvious, such as dirt in a track or hinge, which might be causing the malfunction.

If the problem persists, write down any error codes or messages you see, as well as what you were doing when the problem occurred. For instance, if an autoclave stops working, where in the cycle did it halt? Also, see if you can figure out where in the instrument the problem is occurring. “The easiest thing to do when troubleshooting is to cut your problem in half,” says Folkman. For instance, suppose your HPLC isn’t working; see if you can determine whether the blockage appears to be between the buffer reservoirs and the pump, between the pump and the column, or in the fraction collector.

Even if you end up having to call in a repairperson, such information can save time (and thus money). “If you have an error message, instead of saying ‘I’m getting this diagnostic

,’ if you can say ‘I tried this or that,’ that makes it easier for us. . . . We can know exactly what the issue is.”

6. First, do no harm

If you do decide to open up an instrument to attempt a fix, Smith recommends following the physicians’ creed: First, do no harm. Put another way, make sure you can put back together that which you have taken apart.

Use a cellphone camera to take pictures of wires and instrument settings so you know where they go and how they were arranged. Moses suggests using a piece of white paper, marked to indicate the front and back of the instrument, and taping screws on the paper in approximately the positions from which those screws came, “so you know more or less how it goes back together.” (Oftentimes, instruments may use different screws in different positions, so this kind of information can be invaluable.)

To do no harm also means to protect yourself, says Moses. That means powering down and unplugging equipment before opening it, and putting your left hand behind your back before plugging it back in and turning it back on. That latter point, he says, is an “old electrician’s trick” that “helps prevent shocking your heart should your repair leave a loose wire inside the machine.”

Deciding what can and cannot be repaired in the lab must obviously be done on a case-by-case basis. But as a general rule of thumb, repairs that are covered in an instrument manual’s troubleshooting section can probably be attempted in the lab, such as changing the bulbs on a spectrophotometer or replacing the brushes on a microcentrifuge. Instruments like stir plates are easily fixed, says Moses—often a drop of oil at the point where the motor shaft emerges from the motor, called the bushing, is all it takes.

Instruments that are under warranty or service contract probably should not be repaired in-house, as doing so might void the warranty. Very heavy equipment, very expensive equipment, equipment with precise tolerances (such as a microscope), or equipment involving high voltages, lasers, and so on, probably should be left to experts as well. So should equipment with obvious charring or burning, Moses says, as these might require special expertise in measuring and monitoring electrical circuits.

7. Know when to call for help

When in doubt, it never hurts to call the manufacturer or a third-party repair company. Smith says his company will often offer advice gratis over the phone, and so will most instrument vendors. “I have rarely come across a manufacturer that will not answer simple questions on the phone,” he says.

In some cases, you can purchase a part, like a hinge or a circuit board, and have technical support walk you through the installation process. But make sure the repair doesn’t cost as much or more than buying new. Moses recommends checking the manufacture date on equipment to see how old it is (and thus, if it makes sense to repair it). Circuit boards and electrical components often contain a four-digit code in the form YYWW. For instance, 9613 means the component was built in the thirteenth week of 1996; 0744 means the forty-fourth week of 2007. Though such information will not give a precise manufacturing date, an instrument obviously must be at least as new as its newest component.

But before you do anything, see if you cannot at least identify what is wrong before calling in an expert. By figuring that out you can give the technician the most accurate information, thereby saving him time and you money. Just as practically, you can learn what to do differently moving forward.

“By opening [up a piece of equipment] you can be aware of what happened and what not to do in the future. We don’t want this to happen again,” Moses says. 

Originally Published on March 1, 2013 at:  The Scientist.com

March 26, 2013

Nervous…System Support

My last post about standardization and open source scheduling software for integrated systems got me thinking more about the post-sales support sidon knottsde of those systems.

As many of you know, systems can be very expensive so end-users are making critical decisions on behalf of their employers, both on how well their money is being spent and what are reasonable expectations as to when the system will begin to show a return on that investment.    There is always concern about that ramp up time and the problems you may encounter along the way, so the question of warranty becomes very important to the lab manager or principal user of the system.

Most system integrators go through a very similar process regardless of who the end user is.   It generally all starts with a customer needs assessment, whereby a sales mabiocelnager (usually accompanied by an Application Scientist) asks a number of questions prior  to generating a system concept proposal.   While it may seem tedious to the end-user, (I know what I want, why can’t these people just give me their quote?) this is a critical step in ensuring long term success.   I have been involved in a number of situations where a customer had budgeted hundreds of thousands of dollars but could not provide a single manual method they wanted to automate.    Not good.

Weeks (more like months) after  the system is designed/proposed and agreed upon/purchased by the customer, a date is usually scheduled for a FAT (factory acceptance test) whereby the customer visits the integrator and goes through a “buy-off” checklist prior to shipment.  This buy-off is best done with beckman systemthe actual customer methods (minus real chemistry) to ensure that the system performs as agreed upon prior to shipment.   Remember, shipment means breaking down the system and packaging so that it can be “re-integrated” yet again upon arrival at the customer site whereupon it goes through the SAT (site acceptance test) which is basically the  same buy-off as the SAT, albeit with actual chemistry.   Once completed, you get a handshake (maybe a hug if it goes really well) and “TA-DA !”you own the system.

Most integrated systems come with a one year warranty.  This can mean different things to different integrators but in my experience, entails parts and labor only (travel is nostaublit included).  It also does not include operator induced failures like crashing a robot into an instrument.  In general, most systems include a fair number of third party instruments that the integrator does not manufacture and they don’t make a lot of money providing them.   These instruments come with their own warranties (usually 1 yr) and the integrator almost always passes these on to the end-user, acting as the first point of contact if a failure occurs.   Since the instruments can often reside at the integration firm for several weeks prior to FAT,  it is important for end-users to understand their warranty…’what is covered?’, for how long?’ and ‘when does the clock start ticking (upon shipment, acceptance)?’.

As mentioned in prior posts, an extended warranty for an integrated system can often cost 10-15% of the purchase price of the system.   Some integrators offer an incentive (discount) if you purchase such an extension with they system, or prior to expiration of the standard one year warranty.   Should you choose that option?

In short, the answer is no and I will tell you why.   Let’s assume we are talking about a $350K ELISA system that includes a robot mover, bar code reader, liquid handler, plate washer, ambient storage hotels and plate reader.    Those majorbeckman systemcomponents probably account for less than 50% of the price of that system.   The remainder is comprised of  things that don’t wear or break (system tables, enclosures, scheduling software, PC and …labor).   That last one is a biggie.    Integration is hard work and proper design, build, programming and testing prior to  SAT can include hundreds of person-hours.  That is commonly referred to as NRE or non-recurring engineering.   A warranty for such a system could cost upwards of $50K, or more (not including travel) but you really should only care about the instruments…not the other stuff.

So, if you are faced with a decision regarding extending the warranty of your integratedautomateitsystem…push back.  It’s pretty easy to determine the list price for each instrument in a system and request a contract that is based on just those costs.   You could also go directly to each manufacturer and request contract pricing on their product only.   If that is too time consuming or a management hassle you don’t need, you may want to reach out to one of the major MVS (multi-vendor services) providers (ThermoPEJohnson ControlsAgilentGE) or smaller ISO (independent services organizations) like The LabSquad.

Don’t be nervous about system support…be informed.

March 22, 2013

SiLA Love Songs

Time to talogo_silake a break from talking about instrument support and wax philosophically about a bigger support challenge – integrated systems.    A colleague asked me my opinion of the SiLA, a consortium that is creating standards for lab automation instrument interfaces.

As I understand it, the folks behind SiLA have a business model that will define these interface standards and then presumably charge instrument manufactures for the privilege of claiming “SiLA Compliant,” or some such declaration.    I have to admit that my knowledge of this model is sketchy at best, and the SiLA website does not really lend much insight.

This seems a bit like putting the cart before the horse to me.  That is to say, the instrument interfaces are fairly useless without a higher level scheduling software that manages assay workflow, instrument status and data.

In the 1980′s and 90′s, there were many such products from well establishepolarad system integrators such as  RoboCon (acquired by CRS Robotics), CRS Robotics (acquired by Thermo Electron, who merged with Fisher Scientific),  Scitec (acquired by Zymark), Zymark (acquired by Caliper, who merged with Perkin Elmer) and Velocity11 (acquired by Agielnt) — do you sense a theme here?  All this M&A activity happened during the HTS and uHTS craze.  Once that goldrush ran it’s course, it became clear that system integration is difficult in a public company.   It’s hard to take a 16-20 week design/build/install model and cram in into a quarterly revenue model.  Systems needed to become smaller, more standardized and less expensive.

Nevertheless, each integration company created their own assay management and scheduling software and wrote their own libraries of instrument interfaces.  Hundreds of systemsMicrosoft.Net were installed and not a single one required the involvement of SiLA or any other instrument standard.   One common thread that enabled each of these software’s to succeed was the widespread adoption of Microsoft’s COM, OLE and eventually ActiveX  and .NET frameworks.  As long as instrument manufactures included automation “hooks” based on the MS framework, integrators had little trouble creating robust instrument interfaces.   It’s really not that complicated, as you really just need to be able to initialize, start, stop and report error status for most instruments.   Data (from readers primarily) was generally a secondary consideration and not part of the scheduling paradigm.

So flash forward a few years and there are remarkably fewer pure integration companies left.   Caliper/PE and V11/Agilent are still out there, but not perhaps as visible as they once were.   Thermo Fisher now has a more limited presence as well.   To be sure, companies like Beckman, Tecan and Hamilton still build systems but they are primarily liquid handling companies first, integrators second.   Really only HiRes Biosolutions,Process Analysis & Automation Ltd. or PAA and Hudson Robotics still fit the pure integrator definition.

It would seem to me that without an Open Source scheduler software standard, there isn’t much need for an Open Source instrument interface standard.    Each of the companies mentioned above already have significant investments in creating their device libraries.  What is the incentive for them to abandon those interfaces (many of which they charge for) in favor of the SiLA standard?   I’m not saying they wouldn’t but I’d like to hear a good business argument for it, other than fear of someone else doing it.   In fact,  I would imagine that an Open Source scheduler could exist nicely even without SiLA, much as the proprietary schedulers have existed.    As users create interfaces to various instruments, they would put them into the public domain for anyone to use…no SiLA required.

A few years back, a number of folks in the Cambridge, MA community came together and started to discuss an Open Source scheduler.    About two years ago,  Caliper donated it’s CLARA/iLink source code to the University of Wales, in Aberystwyth which can still be found on Source Forge under the name  LABUX.   Last fall, two MIT students created a similar effort called Clarity.   I have not followed either of these endeavors closely, but it seems to me that they could either solidify SiLA or bury it.

My opinion?  When I ran the system business at Caliper, prior to the PE merger, I was not a big fan of Open Source scheduling.   I knew the investment we had made in our own software and although I knew it had it’s limitations, it was enabling technology that created significant revenue.   Still, I saw the LABUX initiative as a way of testing the waters.    If an open source scheduling standard did emerge, better that it be something we were familiar with.     Additionally, if we could build systems and not have to maintain the software staff to maintain the scheduling software, we could in theory be more profitable (that public corporation thing again).   Now, two years removed from that role,  there does not appear to be  solid consensus on Open Source scheduling or interfaces.    I have no stake in the game anymore, so perhaps I can now be a bit more candid and say.  I am a big fan of the pure integration model, so I am rooting for HiRes, PAA and Hudson!   I still don’t get the whole SiLA thing.   Seems a bit… SiLLY to me.

March 21, 2013

Is your instrument A-OK? If not, you may want to fix it PDQ (or you may be SOL) – LOL!

Is there an acronym for excessive use of acronyms?  It seems every industry has a long list of abbreviated jargon to capture the essence of what is important to their needs…and the life sciences industry is no exception.   Below are a just a few of the many acronyms that we encounter in our daily support of lab instruments and some brief definitions.

OEM – Original Equipment Manufacturer, generally the name of the company who sold the instrument.  However…there have been numerous mergers, acquisitions and bankruptcies over the past decade or more so your BioRad thermal cycler might be sitting on the bench with an older model with an MJ Research logo, or your Zymark Twister robot could now say Caliper Life Sciences (which is now Perkin Elmer)…you get the idea.

MVS – Multi-Vendor Services, a generic term that describes a single services provider who works across multiple vendor brands and product lines.   Giants include Unity Lab Services (Thermo), PE OneSourceAgilent, Johnson Controls and GE Healthcare.

ISO – Independent Service Organization, anyone other than the OEM.  Typically a local provider who works directly with customers or acts as a sub-contractor to MVS’s.

PM – Preventive Maintenance, sometimes called Periodic Maintenance.  A pro-active service performed prior to instrument failure designed to catch wear items before they escalate into more costly failures resulting in downtime.

MTBF – Mean Time Between Failure, a spec provided by some OEM’s that statistically predicts instrument reliability.   Failures are generally defined as abnormal occurrences that cannot be easily remedied by an operator and render the instrument or system inoperable.

MTTR- Mean Time To Repair, the average time required to repair a failed instrument or system.   Total number of failures / total time instrument/system is unavailable for intended operation.

IQ – Installation Qualification, documents that the correct instrument was received and installed properly. IQ can be performed by the user or the vendor (typically both during the site acceptance of a device or system).

OQ – Operational Qualification, tests that the instrument meets specifications in the user environment. OQ can be performed by the user or the vendor.   Some instrument include simple diagnostic routines that can be run by users, however a number of such tools are password protected or visible only to service personnel.

PQ – Performance Qualification, tests that the system performs the selected application correctly. PQ must be performed by the user, or in the case of some GxP or CLIA labs, a third party that provides hard data.

CV – Coefficient Of Variation (not your curriculum vitae, or resume),  a normalized measure of dispersion of a probability distribution.  Insofar as labs are concerned, this is generally a reference to unexpected errors across a microplate.   The resulting errors or outliers may often be traced back to liquid handling or pipetting performance.

GLP 0r GMP – Good Laboratory/Manufacturing Practices, a set of standard operating procedures (SOP’s) to ensure the uniformity, consistency, reliability, reproducibility, quality, and integrity of chemical (including pharmaceuticals) non-clinical safety tests.   Insofar as automation of assays is concerned, these SOP’s may contain periodic OQ & PQtesting of individual instruments, using NIST traceable tools and including analytical date (where applicable) .  Techs working in such labs may be required to show tool certificates prior to beginning work and produce validation results.

CLIA – Clinical Laboratory Improvement Amendments, any facility which performslaboratory testing on specimens derived from humans for the purpose of providing information for the diagnosis, prevention, or treatment of disease or impairment, and  for the assessment of health.   As with GxP above, CLIA labs follow stringent SOP’s regarding instrument support or verification, often requiring certified documentation (audit trails).

Did I forget any?  Don’t be shy, let me know.   TTFN!

March 18, 2013

Is it a System or is it a Liquid Handler?

Remember Razzles? – ‘is it a candy or is it gum?,” so the TV commercial went.   (I actually razzlessubmitted a contest entry calling it  ‘Ghandy…a peaceful coexistence of seemly incompatible delights.’  Not bad for 9yrs old and still waiting on a reply.

Servicing liquid handlers can be a lot like Razzles in that you start out thinking you are working on one thing only to show up and find out that you have something else going on.

System Types:

There are essentially three types of plate based automated systems commonly found in life science research labs.

Robot Centric – A robot arm (manipulator) delivers all consumables to/fropaam a variety of plate based instruments and storage devices.   While many such systems include a liquid handler, they along with other instruments are controlled via a separate scheduling software that oversees the assay steps and ensures proper timing.   Common examples are Hi-Res Biosolution ACell , PAA automate.it,  Agilent BioCel and Caliper (PE) Staccato.

Distributed Robots – Similar to above, except that there are multiple robot arms connected via a conveyor belt or other plate transporter.  Each arm is dedicated to a small number of instruments which each carry out the assay in a sequential (first station to last) fashion.  Again, one or more liquid handlers may be present in the system however they contain programs that are initiated 

dim4

by a higher level scheduling software.  Such systems were very popular in the pharma industry (Thermo Dim 4, Zymark Allegro) rush to process more compounds per day (HTS and uHTS) looking for new chemical entities, but nowadays you be hard pressed to find many survivors still in operation.

Liquid Handler Centric- In this instance, the liquid handler is the heart of the system, which is to say, the liquid handler software runs the assay (no higher level scheduling software).   A large number of these types of ‘systems’ consist of just the liquid handler, by itself, simply carrying out pipetting operations.   However, as many mainstream liquid handlers now include robotic gripper capabilities, these devices start to be 

evo-system

stretched into more capable systems that automate more of the assay freeing up lab personnel for more high value operations.   The plate gripper can load/unload consumables for multi-plate runs or can deliver consumables to shaking, heating, cooling or waste locations on the liquid handler deck or may move them off-deck to plate readers, washers, centrifuge, incubators, thermal cyclers, reagent dispensers or storage devices.   Examples can be see from well known vendors such as Beckman CoulterTecanHamilton RoboticsAgilent and Perkin Elmer.

Conclusion – when exploring your options for servicing a liquid handler, be sure to consider any peripheral equipment attached to that device.   If the end-user expects their entire system to PM’d during a routine visit, the service tech may be either the bearer of bad news or a well prepared and valued service provider.

March 6, 2013

Liquid Handling Questionaire (‘questionaire’ is French for…questionaire)

If you or your lab currently use liquid handlers, or are planning to purchase liquid handlers please take a few minutes and fill out this labX survey.

(click on the image below and you will be redirected to LabX)

tl_files/labsquad/blog_images/liquid_handling_questionaire/labx-survey.jpg

Looking to buy a liquid handler?   Try www.UsedLiquidHandlers.com

March 4, 2013

IT's an IT Thing

windows xp the task failed successfully dr heckle funny wtf windows errorsWe’ve been hearing a lot of our customers ask about various lab instruments being compatible with Windows 7 lately.   Seems  IT groups everywhere are struggling with the eventual demise of Windows XP.  Already unavailable for new PC’s since 2010, Microsoft has announced that all support for WinXP will cease in April of 2014.

While most instrument OEM’s (original equipment manufacturers) are already making the move to Win7,  a huge number of legacy instruments in labs are running XP.   Manufacturers may not want to provide ‘backward compatibility’  for older equipment for two reasons; First, if it ain’t broke don’t fix it.  Sounds lame, but most instrument software is developed with the OS of the day in mind.   Trying to get the performance and reliability that users expect by supporting a major OS upgrade could lead to tons of surprises…ones that  they won’t be paid to correct.   Also,  more than a few vendors have used this Microsoft phase out as a reason to obsolete older instruments and encourage users to upgrade to new hardware in order to get Win7 compliance.

If budgets don’t permit the purchase of new equipment desperate users should consider exploring the Windows 7 compatibility tool.    One caveat is that you would be well advised to back up your WinXP first, or better still try installing your legacy applications on a new Win7 PC.    It’s a lot easier to mess around with a new PC if you know you can go back to the original PC if all else fails…

The following is gratuitously ‘borrowed’ from http://www.howtogeek.com
 

Using Program Compatibility Mode in Windows 7

It can be quite annoying when you try to install a driver or other software on Windows 7 just to find out it isn’t compatible with the new OS. Today we look at using the Program Compatibility Assistant, and troubleshooting compatibility issues so programs install successfully.

Program Compatibility Assistant

Program Compatibility is a mode that allows you to run programs that were written for earlier versions of Windows. The Program Compatibility Assistant detects compatibility issues and allows you to reinstall using the recommended settings. For example we got this error trying to install a music interface device driver for home recording.

2comp

After we closed out of the error, the Program Compatibility Assistant came up advising that the program didn’t install correctly. To try to install it again select Reinstall using recommended settings.

The Compatibility Assistant went through and fixed the issue and we were able to install the driver. The problem was the driver was designed for Vista and the the assistant automatically select the correct compatibility mode for us to install it.

Sometimes you might get a screen similar to this example where Virtual PC 2007 isn’t compatible with Windows 7 and you can check for solutions online.

After checking for solutions online, we’re shown that there is an update that might solve the issue.

Which points us to the Microsoft site to download Virtual PC 2007 SP1.

Note: Sometimes a program does install correctly and Program Compatibility Assistant thinks it didn’t. There are also times when you cancel an installation half way through and it pops up. If you’re an Admin and tired of seeing it pop up because you know what you’re doing, check out our article on how to disable program compatibility assistant in Windows 7 and Vista.

Program Compatibility Troubleshooter

There might be times when Program Compatibility Assistant can’t find a solution, or a program installs fine, but doesn’t work the way it should. In that case you’ll need to troubleshoot the issue. Right-click on the program icon from the Start Menu or in many programs the shortcut icon and select Troubleshoot compatibility.

Windows will detect any issues with the program and you can try to run it with the recommended settings, or go through the troubleshooting wizard. For this part of our example we’ll select Try recommended settings.

This option allows us to test run the program to see if the new compatibility settings fix the issue. Click on Start the program to begin testing it out. After testing the program and determining if the settings work or not click on Next.

If the program is running correctly you can save the settings and it will continue to run with those settings. If it didn’t work properly, you can try using different settings or report the problem to Microsoft and check for an online solution.

If you selected No, try again using different settings it will bring up the troubleshooter where you can specify the issues you’re having with the program.

Depending what you check in the screen above, you’ll be presented with other options for what is not working correctly. Where in this example it shows different display problems.

New settings are applied to the program and you can try running it again.

If none of the compatibility settings work for the program, you’re prompted to to send a generated problem report to Microsoft.

Manually Select Compatibility

Of course if you don’t want to deal with the Program Compatibility troubleshooter, you can go in and manually select Compatibility Mode. Right-click the program icon and select Properties.

Then click the Compatibility tab then check the box Run this program in compatibility for and select the version of Windows from the dropdown. Now it will always run the program in Compatibility Mode for the version of Windows you selected.

Conclusion

Hopefully running the program in an earlier version of Windows helps solve the problems you’re experiencing. Each program is different so the troubleshooting steps will vary. Most programs written for Vista should work in Windows 7, but not all of them. If you’re having problems with a program not working correctly on Windows 7 and have gone through the Compatibility Mode troubleshooter, your best bet is do search the developers website for a newer version or in their forums.