Automatic optical inspection equipment running in SketchUp by dynamic component

It will be great if you can see that the equipment you designed running even in a computer. You can find out lots of thing that can go wrong before hand. Actually, I guess that is the motto of the SketchUp. Design and see whether it works. To that extent, using component and ensuring edges of different component meet exactly is a big step forward. Next step can be seeing those components running around in times and see how each components interact with each other.

But adding another dimension - in here, it is time - is always a great challenge. Sketchup answers it with dynamic component. Here is an example that use dynamic component to run automatic optical inspection system. You can see that a glass coming and sitting on the stage and gripped by tractor and being scanned by cameras that are also moving to cover whole glass area.



To make this kind of simulation, you need to slice the whole time and put which component should move in what direction in each time slice. Refer below screen shot for this.

When user click the bed component, the "ANIMATECUSTOM( "t", 10, 0, 0, 0, 10 )" is executed which increments variable 't' from 0 to 10 in 10 seconds. Refer SketchUp OnClick Functions for detail. Of course, 't' is the time in unit of seconds.

Now we can move parts in various ways in this 10 seconds. In above screen, you can see that the red marks that 't' updates variable 'servox1' to 'servox5' and when time is 2 seconds to 4 seconds, the servox2 is incremented from 0 to 120 cm with 60cm/seconds. Then it is added up to servox and servox is fed into X position of 'tractor' which makes SketchUp draws the tractor component moves along the x-axis at that time slice.

Well, it works but you can see that it is awkward. How ugly it looks to see those variables. It will makes you crazy if you are asked to change any movement in this code. Just think about how much changes should be there if you decided to put 1 second slice after second 2. Maybe there is a better way to organize code. But still you have to write everything in a line. And also look at all those methods - even there is 'AND' method. Of course, there is OR method. Certainly this will make dynamic component in less favorable option.

Reference : Google SektchUp Workshop. Edited by Laurent Brixius, Appendix : Dynamic Components by Matt Chambers

Employ matrix operation in C++ using MTL4

Developing algorithm using matrix asks for number of tools. First a straight forward and proven tool is needed like Matlab. It is better to minimize unknowns when a new algorithm is tried. You have to be sure that the result is solely come from one source - mostly from maturing algorithm. And that is the reason why you sticks to a tool that you are familiar with.

After making up an algorithm with matrix, it is time to make it a working code. It is not desirable to stick to the algorithm development tool as it comes together with a big library and license. It is MTL4 's turn to play.

MTL stands for Matrix Template Library. It is C++ template based and make no dependencies on a library file nor dll. Hence it goes in a small foot print and can be deployed in any platform.

But as template library goes, the most of the work comes down to a successful compilation of the source code. There are number of things to note. First, download appropriate zip files and copies files to an appropriate folders. In Windows, you can download from here and copies whole usr folder and name it MTL4. Second there is conflict in variable names between MTL4 and WinDefs. Refer below code snippet to fix the compilation error in Windows.
There are number of warning that can be ignored - I know I am lazy on it and will pay the debt at someday but until then. The code to include the MTL4 will be like below.
Now time to port the algorithm code to C++ code using MTL4. Refer below code snippet. As above code shows, the C++ code can be very similar to a code in the Matlab thanks to operator overloading in MTL4. In here, very limited features of MTL4 is shown and you can find more in the MTL4.

Installer with Wix

WiX is XML based installer builder.

As WiX is based on the XML, it can be version controlled and you can track the changes made. This is important as tool like InstallShield isn't saved to a text file. If you don't see a difference, you won't be able to debug some bug that comes up some day. If you know there is no difference in source code, you can be sure that there will be no difference in behaviour. If there is , then you can be sure that it isn't come from the installer. That will save a good time of debugging in installer.

Another advantage of WiX is that it is based on the Window Installer. If you write installer for Windows, you can be sure that this tool can fully utilize all the feature the OS provides - like rollback. How can you make rollback without OS supports ? I have no doubt that you can invent a wheel but who will credit you on a new wheel ?

Though unlike other script based installer e.g. NSIS and InnoSetup, WiX is declarative language as it comes from XML. You may find it hard to understand how one element behave. You won't be able to step through the XML. You will spend quite some time scanning through document to figure out which element should be used in what parent and still you need to figure out appropriate attributes. There is no assignment operator. There is no type. No control statement. All these makes quite unpleasant to read XML code. Probably you won't be able to remember why you use one XML element in a place after a month later.

So you have pros and cons. Simply speaking, it is a great tool to fine control the installer. But will take some dedicated mind to develop and maintain.

I am going to show you a simple WiX installer which install number of file and shortcuts. Also prerequisites will be installed also in here. Below is a xml file defines Product. $(var.Product) and others are preprocessor variables which can be defined in the command line argument of WiX compiler or it can be defined by another xml file. Below is a xml file that defines these variables. You might want to update this file automatically to have a increased build number on every build. Product has GUID at Id and UpgradeCode. You want to change Id when you make a major version change but will keep the UpgradeCode throughout the product.

When a product is installed, it is customary to put a registry value of 'Installed' at the HKCU/Software/Company/Product. This can be used by other installer or program to check existence of a product.

Files feature is defined at a separate file. It contains all the files that will be copied to the target PC. But as there can be quite number of files to copy and manually define all these files can be error prone and tedious, 'Heat.exe' is provided by Wix as harvest tool. To use the heat, we can put relevant files in a directory to simplify the process. Here is a sample batch file that copies product files to a directory and run heat.
Sole reason of copying files from one place to another is the heat.exe. It doesn't allow to run multiple times to merge harvest files. You run heat once and then you can't update the result xml file to feed on the next heat run. Maybe this is just one way to collect all the files to install. Anyway, you can find people using different technique like using XSLT or others to achieve their own goal.

The above batch can be executed by pre-build event of the project with below command line.

$(ProjectDir)PrepareInstallImages.bat $(SolutionDir)\InstallerPickupFilesInHere $(SolutionDir)\YourProductFilesAreHere

First argument is the target path at where the generated installer pick up files. This argument is evaluated at $(var.DIR.Main) at HarvestFiles.wx like below snippet.

But this file will be updated with new id and GUID whenever you run the build. It may not desirable. If you want to keep the change minimized between each version of installer, you'd better copy the content to a new file say Files.wxs and use it to build installer. And later when you need to add a new file or directory, you will pick up those changes from the generated HarvestFiles.wxs and put it to the Files.wxs.

With these files in place in the VS project - Product.wxs, VersionInfo.wxs and Files.wxs - you can build the msi file that can install your product.

Though it is not the end yet. You have your files installed with the msi file but it may not run properly as it may need dependencies installed. You may need to install prerequisites like VC2010 x86 redistribution or .NET Framework 4.0 or others. Time to delve into Bundle. There is "xmlns:util" which is same as in Product project. But in here, as it is a Bundle, you need to put "-ext WixUtilExtension.dll" at Tool Settings / Additional parameters / Compiler. This is to let the Wix compiler to figure out external dll. I found it weird though.

Note that the RegistrySearch is from util which is WixUtilExtension. The basic Wix RegistrySearch isn't working at the Bundle - how come ! - and you should use util:RegistrySearch instead.

For the VC2010 x86 and x64 redist, you can check registry whether those are installed before or not. Refer How to detect the presence of the Visual C++ 2010 redistributable package

The result of this bundle project is an exe file with those prerequisite files contained in addition to the msi file of your product.

Reference : WiX : A Developer's Guide to Windows Installer XML, Nick Ramirez.