I was trying to make a tutorial for the Linkage software to show how to design a vertical sliding garage door. The door is built out of four or five segments with rollers at the intersections. The rollers roll in tracks that are vertical then transition through a circular curve (round) to a straight horizontal path. The panels move up and curve at the top to then move back into the space, out of the way.
I encountered a problem where pushing the door down, instead of up, caused the bottom slider to flip 180 degrees around the slider above it when it should have moved off the track. The problem is caused by how sliding connectors are simulated on splines; The software finds all of the locations on the spline where the sliding connector could be placed and then picks the location closest to the previous location of that sliding connector. This is a reasonable way to do the simulation except that once the connector would slide off the end of an open spline, the other locations are far from the previous location and are also not where the user would expect the connector to end up.
I came up with a way to fix this based on the angle of the link that has the problematic connector. If the link needs to rotate a significant amount from the angle on the previous simulation step then there is clearly a problem. But I don’t really keep track of the data to test this. I have the data in some form or another but it’s not data that is generally relied on to be consistent. In other words, I have never made sure that the code keeps track of this for all links for all situations.
An alternative to the link angle test is to predict the next location of the sliding connector and then determine if the new location is too far from that location. I could also do an angle check using the predicted location, which would not rely on data calculated in a previous step of the simulator. This is a better choice even though the prediction uses the previous two locations of the connector and can only predict its movement in a straight line. Still, this would probably work well enough. I just need to come up with a range of valid vs. invalid results and use those for the location test.
Another solution is to detect open splines and then add an imaginary straight line off each end of the spline. If a sliding connector location is on the extension line and that location is the closest to the predicted location from all of the possible locations, then the sliding connector clearly moved beyond what is valid; The mechanism is broke.
The last proposed solution is the one I want to use. But it’s not an obvious choice and I’m also almost as interested in the second solution that uses the angle between the predicted location and the calculated location to determine if the movement is not valid. I think that both will work just fine although extending the spline is more likely to never work incorrectly.
I do need to make the tutorial. It’s a good tutorial as long as I mention that the whole mechanism can get screwed up in the simulation until I fix this issue.
Please comment if you have an idea on how to detect when a sliding connector travels off the end of an open spline. Keep in mind that the software is doing some simple math to find all of the places along the spline where the sliding connector can be placed and that it’s the location nearest the previous location of that connector that determines which location is picked. When the connector would travel off the spline, the code is simply finding one less location where it could be placed. Yes, the previous location of the connector is know during the simulation, as is the location before that (so I can calculate acceleration). I can calculate stuff like the angles, speed, acceleration, etc. and use any of that information to detect the failure.