I exchanged emails with a nice guy who was interested in the Linkage program. He had some useful feedback and also some suggestions and comments about an issue I had with triads. A triad, as I use the term, is a link with at least three link connections to other parts or the ground. Because there are three elements positioning the triangle link, it’s impossible to solve for one of those connections without another of those connections already solved. Anyhow, we exchanged emails about iterative approaches to the problem, which is what I had ended up doing. In the discussion, it came up that the Linkage program calculating something like the Geneva mechanism would have a cumulative error problem. I’m not sure if that’s the right term but if you calculate the position of something by taking the previous position and applying velocity and acceleration information, the small rounding errors and lack of infinite precision of the computer number storage add up each step and eventually, the position is significantly wrong. This is true and I explained that I never use the previous position of an element to calculate the new position. I had to be forceful about this because it wasn’t clear to the other person that it’s very easy to calculate the current position of a Geneva mechanism based on the original starting point and angle measurement for how much the input has rotated. Keep in mind that the angle could be something like 1,234,123.456 degrees. Someone might suggest that adding a little to the angle each step still has that running error. That’s not the case because again, the code will start with zero as the angle and figure out the current angle based on which step of the simulation it’s on. Yes, there’s always some rounding problem because the angle is calculated from RPM and again, the computer just doesn’t have the precision to get the angle perfect.
With all that in mind, it’s sort of funny that I was insistent that I didn’t have any running errors since I found one yesterday. It was not in any math-related to the calculation of the positions of elements during the simulation, it was with the timing of the simulation steps and the animation of those steps. The Linkage program targets 30 frames per second by trying to make each step of the simulation 33 milliseconds long. If a step takes less time to calculate and draw, the difference is used for a timer that delays the next step. I was calculating this delay using the number of milliseconds it took to calculate and render the step of the simulation and with 1ms accuracy, that code could easily be off by almost 1ms per step. 1ms per step times 30.303030 frames per second, the actual expected frame rate, times 60 seconds in a minute adds up to 1800ms which is a 1.8-second inaccuracy over one minute. I did a bunch of tests and found that the code was actually about worse than that and always fast. A 1 RPM input would go around in about 58 seconds. The fix for this was simple; I just figured out at 33ms per step how many milliseconds should have passed up to the current step and then get the system timer millisecond count and see how far off it is. I ended up with the timing being as accurate as the system millisecond tick counter is accurate.
Yeah, that geneva mechanism thing is interesting. The solution for it is to see how many full rotations the output will have made based on the total angle of the input. Then there is a remainder that is used to figure out the partial additional rotation of the output using some triginometry to figure out, based don’t the pin position, where the slot in the output would be. I would be all done with it if not for the issue of deciding where the mechanism start point should be and how to deal in the math with clockwise vs. counterclockwise rotation.