Just going to kludge the link triangle thing for now…

July 27th, 2016

I decided that I’m going to make an alternate link-to-link simulation function that accepts a link triangle as one of the links. It won’t work for both to start with because, well, no one makes mechanisms like that.

The fact is, there’s only really one type of link triangle situation that people might use. They are probably not going to stick an actuator on a link in a way that the end of the actuator slides on that same link as the other end is mounted. They are probably also not going to connect two link triangles with actuators together at the end of two actuators.

Here’s what I want to make work:


And here are some things that still won’t work after this change:


imageimageAlthough I do want to come up with a more flexible simulation algorithm that handles all of these, right now I will add some code to handle the one special case of a single link triangle connected to something that is not a link triangle. We’ll see how it goes.

New Linkage 3.3.5 Available

July 14th, 2016

I got my new code singing certificate and I fixed a few minor bugs. Super short dimension lines were becoming infinite due to the space calculated for the arrow heads. There was also a problem with gear and link rotation angles that went wrong after about two rotations of a gear fastened to a link.

So go get a new version if you need it. The Linkage page, available form the right column of any of my blog pages, has the links to the XP and newer Direct2D variations of the software.

Working with Link Triangles

July 14th, 2016

I have a plan. It’s not a very good plan, but it is a plan.

imageThe mechanism above presents a problem that I have written about a few times in the past. The EGJ triangle is what I call a “link triangle.” It is a set of links that when simulated, act like one larger link. Although I added some code to do some simple link triangle simulation, it is not at all what I need. That code was more of an experiment to see if I could detect a link triangle and then use it in a simulation. But it could not handle the actuator seen here.

The reason that the existing link triangle simulation code can’t handle the actuator, and is far too simple anyhow, is because I used a modified function to replace a regular link with some triangle link info while looking for links to rotate to meet each other. There was no way to actually simulate the actuator when creating the link triangle and no way to handle sliding connections. Damn those sliding connections – they made all of the simulation code 10x more complicated that it was before adding the sliding connector feature.


Above is another mechanism that has the same link triangle sort of problem. This one is a little more interesting because it only has two links in the “triangle” and one of them is an actuator. The simulation is easy to do on paper but is a very special case in the software.


Now it’s just getting weird. Again, this is easy to simulate on paper but is yet another weird special case. The link triangle is formed by connectors CGE but the shape of the link triangle is defined by the actuator that is not a leg of the triangle.

So first things first. The only way to simulate this sort of thing is to figure out the relative positions of the various connectors based on the actuator length. Remember, what the mechanism looks like before it starts is not what it looks like at any step in the simulation. I will need find link triangles, and that non-triangle variation with the actuator and slider, and simulate the parts as if most of the connectors are at a fixed location. then I can create a temporary link of the new shape and use that in the normal simulation code to see how it interacts with the rest of the mechanism. I would need to save the temporary link and find other link triangles before doing any full mechanism simulation because two link triangles might be connected to each other.


But first, I need to change the entire data structure of links and connectors. Look at the simple mechanism above and then at the XML in the data file:

    <program zoom="1.000000" xoffset="-10" yoffset="0" scalefactor="1.000000" units="Millimeters"/>
     <connector id="0" selected="true" layer="16" x="-156.734694" y="54.666667" anchor="true" color="16711680"/>
    <connector id="1" selected="true" layer="16" x="-117.551020" y="166.000000" color="12632064"/>
    <connector id="2" selected="true" layer="16" x="-78.367347" y="54.666667" anchor="true" color="32768"/>
    <Link id="0" selected="true" layer="16" linesize="1" color="16711680">
        <connector id="0"/>
         <connector id="1"/>
    <Link id="1" selected="true" layer="16" linesize="1" color="12632064">
        <connector id="2"/>
        <connector id="1"/>
        <connector id="2"/>
        <connector id="1"/>
        <connector id="0"/>
        <link id="1"/>
         <link id="0"/>

Notice that in the data file above, and in the internal data structures for the mechanism, there is a single connector for the place where the two links are connected. This was a tough design decision to make and it turned out to be a bad one. What it does is it lets the user select and move a connector with very little code. But it also makes it impossible to treat links 1 and 2 completely separately. If the code needed to move connector B to make link 1 longer, like if it is an actuator, but not change the location of connector B for link 2, it is impossible; there is only one connector B. This makes it impossible to create a temporary link in place of a link and then simulate it using different connector locations.

The plan as of a few minutes ago was to change the entire data structure so that each link keeps track of the connectors as separate objects in the code. There would be two objects for connector B, one belonging to each link. They would then point to each other. I think that these per-link connectors will not be connectors like I use now, they will just be some intermediate data structures that keep track of where they connect and also keep track of the existing connector data object. Ugh, too many objects in the data structure for the mechanism gets a bit unwieldy (if that the right word). It makes it hard to maintain the code when there’s so much data to manage and use during any operation.

So to put it another way, the connection points of a link will have their own positions along with a reference (C++ pointer) to the regular connector object. The regular connector objects will no long have a position used during simulation, just during drawing of the mechanism. I can then create a temporary link from a link triangle and have it connect to other links without worrying about altering the shapes or sizes of those other links.

Now to actually change the code. That’s going to take more than a few hours I suspect.

Linkage in a Virtual Machine on Mac

July 6th, 2016

FYI, I was able to easily install Windows 10 running in a virtual machine on my MacBook Pro. I got a trial copy of Parallels and it handled the Windows 10 installation seamlessly. I already had a Windows 10 product key so it was free (so far). And the best part is that the Linkage program, after a little extra startup delay, works fine.

As a side note; I just sent my verification data to Symantec and they should get me my new code signing certificate any day now. I am anxious to publish an update to the Linkage program because of a few small bugs that I fixed recently.

No Linkage For a Short Time

June 26th, 2016

Somehow, I missed that my code signing certificate was about to expire. And Symantec needs me to do the whole notarized identification thing to renew it. This means that I can’t produce a new Linkage program with a bug fix that I wanted to distribute, at least not for a week.

The bug is not really a big problem. It turns out that if a dimension line is short enough, making room for the arrow heads causes the line length to get screwed up and the line draws itself right of the page and maybe to infinity. Just ignore it if you see it.

I also discovered that sometimes drawing elements that are not part of the mechanism should be drawn without dimensions. I got a mechanism file from a user and saw that a bunch of extra junk shows up when drawing layer elements are present and complicated. I don’t know why they needed all of the drawing elements, maybe to use for aligning the mechanism, but the auto-dimensions look crappy in this case.

So the list of ideas gets bigger:

Allow auto-dimensions to be disabled for specific elements.
Allow auto-dimensions to be enabled/disabled by layer.
Allow drawing layer elements to be including in the parts list.

Art of Time Video

June 11th, 2016

I captured a few stills from this video because the work is just amazing. Credit for the stills goes to the people who produced the video; Seiko. The comment on the video says “The meticulous attention to detail and artistic beauty of the time.”


Last Beta Before Release

June 7th, 2016

This is the last Beta version of Linkage 3.3.

Get this Beta version here: http://www.rectorsquid.com/temp/linkage.msi

The video seems to be working properly and so does the image export. It’s almost time to release the new Direct2D version of the Linkage program. And wow do those smooth lines look great! If anyone sees something wrong, send me a screenshot.

I will keep making the older version because it should work with older versions of Windows if the new one doesn’t.

Wow, that is a cool tool…

June 2nd, 2016



I would love to make stuff this good looking.

Direct2D Linkage Beta

May 23rd, 2016

I am mostly done with the smooth drawing version of the Linkage program. I am using it on a high-DPI screen so more testing is needed to make sure everything works right for everyone else.

But since it is close, I have a Beta version available for anyone who wants to try it.

Get the latest Beta version here: http://www.rectorsquid.com/temp/linkage.msi

If anyone sees something wrong, send me a screenshot.



P.S. “Direct2D” is a drawing API for Windows that uses the 3D accelerator to draw quickly and smoothly. It’s a lot different from the older GDI API that I’ve been using.

Direct2D Progress

May 21st, 2016

I have a lot of the GDI functions converted to Direct2D functions. I am still using the GDI pens and brushes, so I just create Direct2D equivalent objects at the time the Direct2D functions are called to draw stuff.


Old GDI Drawing


New Direct2D Drawing

I have arcs, pies, lines, fills, all working pretty well. I have not tried to handle dotted lines or text yet. And the selection box drawn when the mouse is used to select multiple elements, is a color that doesn’t seem quite right.

But progress is good and I’m very please with the results.

One thing I am looking forward to is the text output. If the text can be rotated easily at runtime without needing to create a new font for every line of text, I may try to rotate the text to align with the links, and especially to align with measurement lines. I may end up having to use the Direct2D rendering for image and video export too! That might even make things quicker in the long run if I can scale the drawing process instead of shrinking a larger bitmap to get the look I want.