ok, not a Zen XY. But a neat “sand table” anyway.
And, Zach wins bonus points with me for mentioning sandify.
The mechanics are pretty cool too. I like that they don’t have anything electronic moving around.
This is me! Sandify is the best - I wouldn’t have been able to build this without it. It helped a lot with getting the mechanics and script running properly as well as with some of the demo patterns.
The “resolution” of this system isn’t particularly high so I can’t make very intricate patterns, but I’m working on a higher resolution system and looking forward to tackling more challenging geometry.
3 Likes
I designed a more straightforward system earlier that didn’t have any moving electronics either. I had to write a script to compensate for rho displacement that occurred because of a shared axis between theta and rho. I can probably dig that script up if people are interested.
6 Likes
Very nice, I wouldn’t have thought it by myself, sand table + fish !
You can also increase the pattern details by using a smaller diameter ball 
what kind of control board di you use ?
1 Like
I’m curious about the resolution limit as well. Is it a backlash issue?
The resolution issue is mostly due to the wet sand flowing, so a smaller ball might not help me much here. When the ball deflects the sand on a typical Sisyphus table, the sand does a pretty good job of staying put. In the case of Sisyphish, some of the sand flows back down into the channel.
Oh, you should try baking soda 
1 Like
Missed your question about the control board. It’s an Einsy Rambo running on an octopi server. I used it because I had it and because it supports StallGuard.
1 Like
I do like my shrimp 
I actually iterated through a bunch of different particulate types. The really small ones like clay sort of work, but they get stirred up way too easily. The larger particulate doesn’t resolve patterns at all. I found this fancy sand which works the best.
1 Like
Did you folks see this:
1 Like
I haven’t thank you for pointing that out. It looks like an extrusion based build, with dual X motors and a single Y.
I am not sure I like the idea of using a rectangular machine and a circular table. Especially if you build the table. But it is not my machine or table, so more power to them.
1 Like
I dug up the script and made it public here if people are interested. (I am not a software engineer, and I don’t pretend to be one on the internet.)
That is kinda funky to call it a zen table. They most definitely know about the zenXY since they use my ramps picture (twice), https://docs.v1engineering.com/electronics/ramps/#drivers (recognized my old desk under it and the way I positioned those wires).
It could certainly be simpler, but it looks robust enough. Nice work.
Hi, can you publish again the code? The link doesn’t work.
Yep, here you go: https://drive.google.com/file/d/1J3L6fBoFZm_LtHtU2m35gXUN6CAshyGb/view?usp=sharing I think I removed it from github because I wrote this when I was just starting out with programming, and it doesn’t look great if anyone prospective employers are looking at my github…
The critical number to figure out is how much your rho axis drifts in response to 360 degrees of theta rotation. Then you can plug that number into the script and should be good to go. This script formats the output to gcode which you can get rid of if you don’t need. I would also remove all the extra newlines from your .thr files as those can cause an index error.
Hi,
Thanks for sharing the script.
A little question here, what firmware do you use in the einsy rambo board?
Is it a fork of marlin?
Could you provide a link for the same?
I have built a 3 feet sand table earlier following alwaystinkering’s post.
After running it for a month i am facing issues such as belt loosening, material bending etc. and many more issues.
Every now and then i have to open up the table and tighten all those loosen bits which is seriously a pain in the ***
Of course i can overcome it by making the arms in metal and modifying some parts, but still i want to try out some other mechanisms and firmware is the only part where i am stuck with.
Currently my setup includes a board built around esp3, a4988 stepper motors and interrupt limit switches but esp32 sometime comes out unreliable so i have to reset the system.
Your build looks more sturdy and would be a good starting point to try out for anyone building a polar sand table.
It would be really helpful if you could help with dimensions, some details and firmware.
Thanks.
The software was unmodified Marlin I believe. Marlin supports Polar out of the box. The kinematic conversions necessary to make it work happened at the Gcode level rather than the embedded firmware level.
Looking through this design quickly, it looks like there are some very long moment arms involved, and I’m not surprised that you’re running into issues if you’re making the arms out of plastic. Two things that might help:
-
Make the magnet as small as you can without affecting ball motion. A stronger magnet linearly adds force to the system, so you really want to make this as small as you can.
-
Add some sort of low friction tape to the top of the magnet where it contacts the underside of the sand reservoir. I prefer UHMW for this because it has a pretty low friction coefficient and good wear characteristics. PTFE will technically work better, but it will also wear out faster.
My design would have the same sorts of issues you’re seeing on a very large table just because you’re dealing with such long arms. The only solution is to decrease friction as much as you can and strengthen the arms.
1 Like
Ok.
- Could you share design files for your pinion design or for your two gear design posted on your website fr sisyphish table?
- Does your double gear design also use marlin because as far as my understanding marlin oar firmware works on mechanism with rotating base and sliding arm but in your design even the sliding arm is performing a rotating function.
If I had the files I would share them, but unfortunately that rack pinion design has disappeared into the ether on me. It wouldn’t help you too much anyways because the gears weren’t parametrically designed, so you wouldn’t have been able to scale them up. I’m pretty sure I used a gear generator in Fusion 360 to make the gears, because no one has the time to be designing spur and pinion gears by scratch.
There’s a lot more that goes into the double gear design, and that’s running on custom firmware. I’m actually turning that into a product seen here, so the codebase and mechanics aren’t particularly friendly to work with. You wouldn’t want to use those mechanics for a large table either, because the resolution decreases as the radius gets larger. It’s really well optimized for the small size that I have, but you might have noticeable resolution loss at your table size.
I think the Rack and Pinion mechanics are really what you’ll want for a large table. I haven’t looked at Sisyphus mechanics much, but I think that’s what they use as well.