tracks putting main ball in 2ball holder

This has happened several times to me. I have yet to troubleshoot this to see if a specific track can produce this result repeatedly, but I am guessing not. I have hypothesized that tracks which do a lot of perimeter moves build up sand along the perimeter and may end up pushing the ball into the bull pin.  Maybe someone with better knowledge of the table can tell me if this is plausible.

great resource thanks for making the effort!

Experimenting further, I've found if you reduce the ball speed, you can stop this from happening. Bruce has mentioned this previously as a solution. I do believe some tracks at high-speed are more prone to producing positioning errors that result in the ball hitting the bull pin, but I don't know why.

Centrifugal force? There's enough vertical distance between the magnet and the ball that maybe at high speed the radius is larger as it gets whipped around the outside. Just a guess. I'd do some science on it with a tripod-mounted camera and slow, medium, and high speed runs past the call catcher.

I've been having a problem reproducible with several tracks as well. https://photos.app.goo.gl/cBB4sEcefALM5RTG7

@dithermaster I believe one of these is yours as well, it seems to randomly stop or not make the pattern shown at all, and then the next homing totally wigs out, the rest are "dougo" tracks. Normally the first thing I would do is look at the file itself, but that's not possible it seems.

Yes, the first one is mine. Its does depend on the combination of table size and ball size to look "right" as it depends on the closer tracks looking different than the less-close tracks. It was designed on my 2' End Table and I haven't tried it on my Mini yet to see if it looks anything like it should. In the future I'd like to provide variants at different table sizes. As to why or how it messes up tracks afterwards, I'm not sure why that is happening on your table. It is possible to view the .thr files in a text editor, they are just theta rho pairs. Rho should always be 0.0 to 1.0 (a long time ago I had a track the went outside that, but it got fixed and re-posted). As far as I know, as long as Rho is 0.0 to 1.0 there is nothing a .thr can do that should "break" the table.

Posted by: dithermaster

Yes, the first one is mine. Its does depend on the combination of table size and ball size to look "right" as it depends on the closer tracks looking different than the less-close tracks. It was designed on my 2' End Table and I haven't tried it on my Mini yet to see if it looks anything like it should. In the future I'd like to provide variants at different table sizes. As to why or how it messes up tracks afterwards, I'm not sure why that is happening on your table. It is possible to view the .thr files in a text editor, they are just theta rho pairs. Rho should always be 0.0 to 1.0 (a long time ago I had a track the went outside that, but it got fixed and re-posted). As far as I know, as long as Rho is 0.0 to 1.0 there is nothing a .thr can do that should "break" the table.

AFAIK you cannot view files downloaded from community portal? But, I don't think the appearance is a table size issue, I don't think it's even completing the track, is it supposed to end mid table like that? I didn't think that was an option. Maybe the download was corrupt. I haven't gone full diagnosis on it.

@dithermaster -  "Centrifugal force?" - Nope. Although the magnet-ball coupling is flexible and can be broken by angular acceleration that is large enough, our tables don't go fast enough to lose the ball simply by going in a circle so fast that the ball flies off. I know this from having witnessed exactly that while testing high speeds on servo-driven large scale prototypes. The concern about higher speeds on the tables, is that tracks with sharp corners can cause position loss in the output of the motors (from the high accelerations at the corners). This is usually a tiny error - but can accumulate.

@burningamd - The track errors you're experiencing suggest something is wrong - possibly with the configuration of your table. But I would expect that all tracks would have problems. Are you saying that only certain community tracks go out of bounds? And do so reproducibly?

@burningamd, ah, right using the Community feature you can't see the track files. My tracks (same as in the Community) are downloadable here: https://github.com/Dithermaster/sisyphus

@Bruce, OK, good to know about it not being centrifugal force! Too much sci-fi on my part I'm sure. Could the ball park not be positioned correctly?

Posted by: Bruce

@dithermaster -  "Centrifugal force?" - Nope. Although the magnet-ball coupling is flexible and can be broken by angular acceleration that is large enough, our tables don't go fast enough to lose the ball simply by going in a circle so fast that the ball flies off. I know this from having witnessed exactly that while testing high speeds on servo-driven large scale prototypes. The concern about higher speeds on the tables, is that tracks with sharp corners can cause position loss in the output of the motors (from the high accelerations at the corners). This is usually a tiny error - but can accumulate.

@bruce, are you referring to losing steps?Is this specific to the motor which does the linear movement?

I just had another track go bad, it was heavy on movements reversing the linear motor (dougo-spiral2rev). The whole track is filled with linear reversals but it has a problem with one specific portion of the track.

If played from the inside it doesn't have a problem and gets to the outside with the ball in bounds, but then it starts moving back in and the ball quickly goes out of bounds. (switches movements at 27 seconds, out of bounds by end)  If played in reverse, it immediately starts drifting out of bounds. So seems to be an issue with linear reversal toward the outer perimeter (though inner or outer shouldn't really affect chance of skipping steps) or maybe it's a change in the length of the movement that triggers it.

Looking back at the other tracks that failed, they seem to have similar linear reversals.

@burningamd - Yes, position loss means losing steps (with stepper systems). It is not specific to Rho (linear) - Theta (rotation) can also suffer position loss. Rho position loss becomes apparent more quickly because the Theta axis has no physical limits, whereas, when Rho is out of position, it will soon cause the axis to hit a "hard limit" (physical stop). The images you posted look to me like Rho slippage, since Theta slippage tends to "smear" tracks rotationally. Your bad tracks look like pure Rho error. Errors like this can be caused both by software and/or hardware issues. So far, there is nothing in community thr files that we know of that could cause it (Rho is limited to values between 0 and 1). I suspect two possibilities: 

1. Lost steps from rapid change of direction in an axis.
2. shaft slippage inside pinion (Rho)  or pulley (Theta) from rapid change of direction in an axis.

Though both are worsened with higher speed, shaft slippage (from loose set-screws) usually worsens over time. On tracks that you find reproducibly produce the error, try running at very slow speed (I know, this takes patience :). If it is a weird software bug / or errant line in the track file, speed should not make a difference. If the track looks better or is fine at slow speed, that corroborates the above possibilities.

I forgot to mention I checked the pinion and found it tight, and yes slowing the track down does eliminate the growing out of bounds. So I'm going with skipping steps.

Slowed mine down last week and seemed to not have a issue for a couple days, then over the weekend i had to remove the main bal from the ball pen 3 times.

I was a running a playlist of mostly community tracks. I am gonna switch the stock track playlist for a couple days and see if it happens with those tracks.

Frustrating.

Do you have it pausing between tracks? Try to narrow it down to specific tracks that way. Also, are you resetting the playlist after removing the ball? If it's the same problem as me if you just put it back it's going to happen again until the table homes again (which it wont in between playlist tracks)

Im having the same issues with a lot of the "DougO" tracks, so much that i hate to run one.

When creating these custom tracks, does it allow the creator to make a track that can go outside the boundaries ever so slightly of the arms reach? Another gripe with some of the tracks is that they're just too messy along the edges. Im sure most Sisyphus owners are perfectionists and this probably bugs the hell out of them...it definitely does for me lol