I had a running error, or something like that, in the Linkage program. I had targeted 30 frames per second for animations and I used a 33 millisecond target time for each frame. If a frame took less than 33 milliseconds to compute and draw, I would add a delay of the appropriate amount. The problem was that the start and end time for each frame would be somewhere between two different millisecond values of the system clock and I had no way to adjust by more or less than one millisecond. Imagine starting a timer for a running race that only shows seconds and then seeing two runners cross the finish line a half-second apart. They could both be registered by the timers as crossing at the same time and if you used that time to give one a handicap in the next race, you could be wrong by up to a whole second. If you also started the race by looking at a running timer, you would not know where between two values on the clock the race actually started.
I fixed the timer problem by keeping track of the total steps of the simulation and then calculating how many milliseconds should have gone by in total. If one frame is adjusted by too much or too little, it will be accounted for in the following frames. Yay!
Now the new problem… By targeting a total timer value based on the simulation step, the run-fast mode that calculates ten steps of the simulation every frame became slow and showed a new frame three times per second instead of every 30 times per second. I fixed this with code that looks at the speed of the simulation and adjusts for this. But there are still issues because the animation code also handles manually stepping one frame at a time and the manual mode lets the user move the inputs to specific positions using sliding controls. I need to work on these things to make sure that there are no introduced delays or weird calculation problems. I suspect that stepping backward does weird things to this new animation timer code.
I’m also working on another issue. I had changed the run-one-cycle buttons to run-half-cycle buttons because I already had a way to simulate one full cycle of a mechanism and I needed to see the end result of a mechanism that moved out then back in again with each cycle. I’m going to “fix” the one-cycle button that I already had, which is called something like “Run Simulation” (being different from “Animate Simulation”) so that it can alter the RPM of an input (or CPM) so that it always ends up doing exactly one cycle, something it doesn’t do right now. It may not be obvious but if you are animating at 30 frames per second, an input with a certain RPM value could get very close to a full rotation in one frame and then be past a full rotation in the following frame. I want to adjust the RPM because the animation isn’t animating and the visual speed of it isn’t important. Heck, I could even allow users to enter the number of steps to calculate for the full rotation in order to get any accuracy they might need in exports data! I also need to check on the calculations to ensure that if there are 600 steps for a single cycle, that there are 601 lines of output in the motion path export file – the end of the simulation should be the same as the start of the simulation. 601 lines mean users will have 600 steps from one line to the next to use for their calculations if needed.
I hope to make these changes soon and then make the Beta Linkage program the official released version. The Beta has cams as well as some bug fixes that I want to make available as soon as I can.