I’ve been using the MvvmLight Toolkit on a project now for several weeks. At first, the ViewModelLocator pattern the toolkit uses didn’t bother me. But after you wonder why your view can’t be located and then debug everything only to discover that you forgot to create the ViewModel in the ViewModelLocator.

I first thought about switching the ViewModelLocator to inherit from DynamicObject and using MEF to discover the VIewModel’s. A quick search lead me to discover that I’m notthe onlyone to have that same thought

The one thing I didn’t like about using Dynamic and MEF for discovering the ViewModel was the design time experience took a big hit. Locating the ViewModel was now much more expensive at design time.

I started started doing more thinking, and wondered if I could use T4 to generate the ViewModelLocator for me. After more thought, I knew I had to be able to use T4 to generate the ViewModelLocator, heck T4MVC uses it to generate a bunch of helper classes.

Because I’m big on using IoC in my apps, I’ve also added the ability to get the ViewModel from an IoC container if the application isn’t in design mode.

There are two files that are required to make this approach work. ViewModelLocator.tt, and ViewModelLocator.settings.t4. The settings file exists so you can configure the what’s and how’s. If you use the default setup for MvvmLight, the only thing you will have to change is the IoC stuff.

To use the T4 ViewModelLocator, delete your existing ViewModelLocator.cs class in your ViewModel folder, and drop the two T4 files into your ViewModel folder. Once that happens, you will see a new icon show up in the solution explorer called “Transform All Templates.” Click that icon to have your ViewModelLocator automatically generated for you, compile and run

Next time, I’ll write a post about using MEF, DynamicObject and other code to dynamically locator your ViewModels to create a composable application (Wait, didn’t I just say there were performance issues? Yes, but sometimes you have to take the hit).

Please post your thoughts on all this, I would be really interested in hearing other perspectives!

I purchased my DS1052E scope several months back. After trying, and failing for days to get the “Ultrascope” software to work under Windows 7 64 bit, I gave up.

My interest was recently renewed in getting the Ultrascope software to work on my computer so i decided to give it another go. This time, I succeeded!

To save others the pain I went through, I’ll document the things I did (well, that i can remember given that I had previous failed attempts). Install the Rigol Ultrascope software.

Second, download the DS1000 Series Windows driver (note, I can’t take credit for these two files, I found them in another forum). Extract these two files, then go find the device in the Device Manager. Update the driver and point it to the directory where you extract the driver files.

Next, download the NI-VISA Run-Time Engine (v5.0.3 as of this writing). Beware, this file weighs in at 71 MB. Install the VISA runtime with the default options (you could probably get away with just installing the USB portion, but I didn’t try it).

When the NI-VISA installer finally finishes, you might be prompted to reboot. I skipped this step . Run the Ultrascope software, and click on Tools –> Connect to Oscilloscope. I was prompted with a list of devices, with none of it making much sense, except the first option “USB0…” I choose that option and everything worked!

After I re-read my last post, I realized I kind of cheesed out on the drill bit part, so I figured I would more fully flesh that part out, plus detail the opto-isolated limit switches I purchased.

Drill and Router Bits

For hole drilling, I looked at buying a kit like this one from Drill Bit City, but ultimately decided that I would just get a 10 pack of each of a few different sizes. I ended up getting #71, #70, #66 and #60 drill bits from Drill Bit City.

For milling (cutting out), I got a 10 pack of .0625 down-cut carbide bits, also from Drill Bit City.

For trace isolation, I picked up a 10 pack of 60 degree carbide “V” bits off of eBay.

Limit Switches

The purpose of the limit switch is to keep the controller software from driving any of the axis's to their physical limit and causing damage.

You can certainly run your CNC machine without limit switches, but honestly, if your going to spend a minimum of $1500 on your setup, why not spend a few more dollars (and a few input pins on your break out board) and prevent costly damage to your machine?

When I was doing research on limit switches, I was originally considering using a standard lever actuated micro-switch. But I had some questions and concerns regarding their accuracy. Over time, as a axis slams into the switch, it will deform the lever.

When a microswitch is used on say an arcade button, any imperfection or deformation of the lever will go unnoticed by the user. But in the world of CNC, accuracy and repeatability are everything.

After doing a lot of research, I stumbled upon Colin Mackenzie’s Opto-Isolated Limit Switches. Colin had the same concerns I had regarding using physical limit switches and came up with an opto-isolated switch which can be wired in an “OR” configuration.

While the opto-isolated limit switches are a little bit more expensive than a typical micro-switch (at around $2 - $2.50), at $8.50, I didn’t find the cost difference to be to great.