Hello everyone
I’m in the planning phase of my sandtable build and would like some feedback about if some things are possible the way I imagine them. First to the construction, I’m going to build a polar table similar to the sisyphus tables, I also want to be able to use 2 balls and a parking feature for 1 of the balls. The balls always move on opposite sides, if one is at the center the other is outside and vice versa. I hope you can understand what i mean
Since I couldn’t find any firmware specific for this kind of polar kinematics I will use marlin configured for a regular cartesian machine, but set it up so that Y 1 equals a half rotation (1 radian). Software endstops will be disabled to allow it to move infinitely in both directions.
I can then use a simple script to convert .thr files to gcode, starting the gcode with G92 Y0 and G91 makes this straight forward, since everything moves in relative coordinates I don’t have to worry about converting the crossing from 360 degrees to 0 degrees correctly. As I understand it the Thetha values in .thr files are also relative, but the Rho values are absolute? Still shouldn’t be an issue, since I can just use the delta between coordinates for the Rho value.
For the parking mechanism I will use some sort of hook shape that moves in and out with the Z axis motor. This way it doesn’t interfere with the drawing surface. Before parking/unparking the machine would need to be homed.
Everything gets controlled by a raspberry pi with octoprint. What I’m not sure about yet is if it is possible to also run NodeRed on the same pi to host a simple web interface to control an RGB led strip… Or if it’s somehow possible to enforce the rule that only patterns with the same starting Rho as the ending Rho of the last pattern can be selected.
Sorry if this is a bit all over the place, I have too much stuff that I’m thinking about at the same time
Check out this post where I worked some of this out to run a theta rho table with a marlin controller:
There is the caveat that Marlin has no idea you are dragging an arm. It thinks the numbers mean mm. So the feedrates will be a bit goofy, slowing down near the center and whipping around the outside edge.
The thetas are locally relative. So if you need to go from 355 to 365, that is different than going from 365 to 5. In between patterns, you need to reset the theta zero. Rho is always absolute, always zero to one in a thr file. No matter what size the table is.
For endstops, there are optical endstops that don’t restrict movement. Those would be good for the theta motor. The rhoish motor could probably use a regular microswitch, but an optical one could work too. Or maybe even sensorless homing. For the Z/ball deploy, what about using a servo? That would have a built in position and you can set it with M280 S0 or M280 S200. You can easily adjust it and Marlin won’t get confused and think there is a Z axis. I think Z would be fine too, but just a bit more complicated than it needs to be.
As for the second ball. You’ve definitely made a challenge there. Hopefully you have an idea of how to do the mechanics so the extra ball is driven by the same motors and you have some idea of how to deconflict at the center.
Also take a look at the sandypi software. It needs some more developers/users, but it seems like a great start for what you (and we all) want. I haven’t set it uo yet (my table is in progress, indefinitely, but I am trying to win a sisyphus table by vote (the tasting flight one is very close, so help is appreciated, you can vote every day for 1 more week). But I do plan on setting that up eventually and making some PRs to try to help it out.
This sounds like a super fun project. You’re in good company here. Please update us as much as you can.
I read through most of the ZenXY posts and found them very helpfull.
Since I will be using gcode and not .thr files I was thinking about adding some sort of feedrate scaling based on distance to the center to my converter script, I’ll experiment with it when I have the table built
I’m going to use optical endstops for theta and rho, seems the simplest and quietest solution. For the ball parking a mechanical switch, if it is even necessary.
Good idea with the servo, but I have a bunch of Nema17s lying around that I want to use for something
And for the second ball it’s less complicated than you think. They are moved by the same motor, it’s basicly a rack and pinion with a magnet at either end. The balls are always the same distance apart (the radius of the drawing surface). So when one moves to the center the other moves to the outside. I’ll post a picture of the design later, I’m in the middle of moving and don’t have access to my PC right now
As for samdypi, it looks great, I’m not sure if I would be a big help though. I have done some python programming and could maybe help with the led stuff?
