I finished the minimal work necessary to use the new installation package. I don’t have time to do more extensive work on it but I think that it is good enough to send out. The user cannot pick a destination for the install and the program is installed for all users without a choice. I create a desktop icon and a shortcut in the Start menu program list.

I had a bit of fun trying to make the graphics more interesting. I’m not sure if they are great or just cluttered but I like them.

The Welcome Page

The Progress Page

Other than a completion page that looks a lot like the Welcome page, there isn’t anything else to the installer.

Get it here.

The bug mentioned in an earlier post today was an easy fix. During the simulation, I do error checking to make sure that a set of links that are being moved into their new locations are not already stuck in their current location. Sort of.

Invalid Connections Shown Correctly

The problem was that I was moving link 1 (dark blue) and link 3 (green) to meet each other at the common connector C. The code made a bad assumption of I just forgot to check that both links were not connected to something already stuck in place. The code only tested link 1 which has no other connections. Link 3 has that connection through link 2 (cyan) to link 4 (purple and not confused with link 6). Link 4 is already fixed in place so 2 cannot be moved later.

There is still a flaw because it is possible that link 2 could work properly in a mechanism like this and not cause link 3 to bind. I am not checking the distance to see if it is valid, just that there is nothing attached to link 3 that could keep it from moving into its new position. I will need to test my theory and then improve the code.

But what I really need to do is rewrite the simulator code to be a bit less complex. There should be a way to move things into their new positions and somehow just know that a mechanism is not valid. It will take some thought before that happens.

I encountered a bug in the Linkage simulation code. I have error checking for mechanisms that won’t work and I was aware of some situations that were not working right. This new problem surprised me.

Video of the Failure

The simulation code uses an iterative approach where each element is moved if it can be and once all elements have been tried, the process repeats until there is an error or until all elements have been moved. This is a bit clumsy but it was the only way I knew how to do this. I knew that there was a bit of error checking missing when rotating input anchors but I didn’t expect this case.

Link 2 get stretched. It appears that either connector D or connector F is getting moved without regard to the other.

I’ll fix it as soon as I get a chance but I did want to at least have some record of the problem for anyone who might encounter it.

And if anyone doesn’t know this already, there is an exponential order of magnitude relationship between the amount of code in a program and the difficulty in writing that code. Double the code and it is like making it 10 times more complex. At least it seems that way sometimes.

Dave

About ten years ago, I was building a robot and I found a demo of a 4-bar linkage design program that would synthesize a mechanism based on an input curve. It suited my needs but I wanted to do more. I ended up wanting to write software for editing and animating mechanisms but I had no background in that field or in any field related to mechanical design.

So I wrote some code and let it sit for 8 years until a few years back, I got a fully functional and useful program written.

Then I did some research…

Sure, I did some internet searching back when I was writing the software for the first time but not much was available at that time and I was focused on free software.

I recently did some more research and didn’t skip programs that cost money. I’m not really surprised but it turns out that there is a package that has been around for a long time that I apparently copied. I only say that because there are enough similarities between my program and theirs that it might look that way. I actually had no idea about their software until recently.

SAM can be found here: http://www.artas.nl/

SAM looks like a nice package. I dislike what looks like a modal interface but that’s just a strange preference of mine. It doesn’t seem right to decide to change a property of a connector then click on the connectors that should have that property. I base this assessment on seeing a video where connectors are changed to ground connectors by first selecting something in the toolbar then clicking on the connectors. I could be wrong and there could instead of some key presses happening.

SAM sells for about 1425.00 Euros. That’s a pretty steep price for the software but maybe it’s not out of line considering some of the more advanced features that are in that package. I will certainly admit that it does what Linkage 2.x does and a lot more. In fact, it would take more than a few hours of development time to get anywhere close to the number and complexity of features available in SAM. Heck, I can create mechanisms in Linkage that don’t work and show no errors so I am certainly not building a commercial package.

So hats off to Artas Engineering Software for doing what I wanted to do and better and being able to sell a few copies!

But if you want some of those features and you want them for free, give Linkage a try.

Animate Gif Converted from Linkage AVI File

The image above was not created by the Linkage program. It was converted from an AVI file that was created with Linkage. I’m thinking about how I might be able to build in the GIF animation creation feature so that I can get easier-to-view videos that loop. YouTube is nice for sharing with strangers but the lack of a looping feature and the really ugly preview image (see High Quality Video Preview for YouTube Videos) makes it a mediocre video service. The animated GIF files don’t have a preview and are playing the moment the page is displayed but that is fine. JavaScript might also be a very useful tool that would allow me to present an animated GIF similar to how YouTube videos are presented; a play button over a preview image should be fairly easy other than having to create the preview image manually.

So there it is; a nice animated GIF showing some curved sliding connections in a mechanism.

I have an urge to add cams to the Linkage program. After adding the ability to affix drawing elements to links, I realized that I had created the method to affix cams to links. That was a stumbling block I was not able to overcome for a while. By using that method to attach cams to a mechanism, I get past what had been holding me back for a while.

I also figured out the other issue which is designing a user interface to edit cam shapes. Although I would prefer to edit the shape right in the drawing editor, and I may add that, I would use a properties dialog box to provide the initial cam creation UI.

Three Types of Cams

I have identified three types of cams: eccentrics, typical, and Bezier. Typical cams are those found in engines and have a single lobe or protrusion. Although they can have very complex shapes, I would limit them to having a base radius, a tangent radius, and a nose radius. Bezier cams would be my own method of letting a person create a complex motion controlling cam with almost any shape desired. Eccentrics are just offset circles and might not be so useful. I’m not sure if the follower motion of an eccentric is the same as a crank but I think that it is. The only reason to support eccentrics is to more accurately represent what a person intends to build.

Each cam type would be edited in it’s own properties dialog box that has controls for the specific cam type. Although it would require a lot of typing to create the code for this, there is nothing in the user interface that I have not already experimented with on my geometric constructions page.

Geometric Constructions Page – Bezier Cam

Geometric Construction Page – Typical Cam

Getting the cams to work in the simulator is a different problem from creating the UI to create them. This part would be tricky since the typical and Bezier cam types have unusual mechanical issues. Intersecting a line or circle with a cam becomes problematic. For instance, finding an intersection with a typical cam requires intersecting with four different arcs. Intersecting with a Bezier curve might require iterations through a set of small lines used to form the curve and through multiple Bezier curves of a single cam.

Other Work

Unfortunately, or fortunately, I have a paid contract coming up. It is Windows Phone programming work. It has replaced the contract for IOS programming that I was looking forward to doing but it is a lot of work and a lot of extra pay. So the Linkage program gets a lower priority again. I will need to make sure that I don’t end up writing half-assed cam code like I did with the DXF file creation code. That stuff is still only partially working and I’ve lost interest in making it better.

Dave

I found a major memory leak in the Linkage program. Fortunately, the leak only added up to large amounts of memory if a simulation was running for a while.

The leak was caused by my forgetting to create a virtual destructor for a C++ class. One of the changes that I made a few months ago before taking a break from working on this program was to place all rendering code inside of some C++ classes. I opted to use the regular GDI code as the basis for this rendering class instead of making it something that can be used cross platform but it still has the ability to convert any drawing operation from a GDI call to a call to some other functions. For instance, I use this rendering code to “draw” DXF files.

One thing I did with the structure of the program was to have a rendering class that contains a member object that is the actual renderer. When a rendering class is constructed, it accepts a parameter that indicates what type of final rendering is needed. The contained rendering class is based on a common base class so that the higher level renderer does not know or care what type of actual rendering is going on. The high level class is used just to hold the actual renderer and pass on requests to it.

So the bug was that I forgot to make the destructor of the base implementation class a virtual destructor. The destructor for the actual low level rendering class never got call and never cleaned itself up.

I wish that the compiler could have told me this.

I will upload a new installer for the Linkage program shortly.

I need to add that I created a linkage that caused the program to do something wrong and that in turn caused the entire system to become unstable. I think the problem was that I used up a critical and limited resource when I didn’t free things properly. I hope that the problem is gone now that I found the leak.

I am searching the code for other less obvious memory leaks but so far, it looks good. If anything is leaking, it is very very small.

Dave