Polar Sand Table Curiousity

ZenXY Hardware Development
1

So, right now I have neither the time or money to build one but for some reason my headkeeps coming back to it.

If I built a table I’d want it to be circular so the polar and scara designs appeal to me. I also would like to run #software:sandify files so I’m not reinventing the wheel and having to learn math that eluded me 30 years ago and feels even more intimidating now.

To keep things simple I’m thinking about building an arm that pivots around a central point (slip ring) and a screw drive that handles movement along the arm (coreward <–> rimward). Does sandify handle this type of machine? If so do I design arm travel to be the radius or diameter of the circle?

Thanks!

2

I don’t have a sand table, but I remember reading this topic on the forum. It confirms that Sandify can produce code for a polar sand table, plus the Scara link in the second post has a animation about one radial arm design.

3

Perhaps Polar is a the wrong name for what I’m trying to do. I’m trying to do this with a single arm and a slider not a dual arm like a scara would use.

4

The term “Polar” is a good term, but that is not how a Scara arm works. So Sandify produces a code that must be interpreted by some firmware. In the case of the ZenXY design, the firmware is a version of Marlin, and he code is g-code. Any of the formats Sandify outputs could be used with your design, but the simplest might be the Theta Rho format. It is already a list of angles and distances, where the other two (g-code and SVG) are rectangular coordinates. According to the Sandify documentation:

Theta Rho is the format for Sisyphus tables. It is a long list of theta rho , which is just the angle from the center (absolute, accumulating with each rotation), and the normalized distance from the center (0,1).

If you look at a file output in the Theta Rho format, it is just a list of number pairs. So, in my mind the question is not if Sandify will output something you can use, but what firmware will you use to interpret the coordinates and drive your steppers. If you have some programming skills and some knowledge of how to drive stepper motors, it would be pretty easy to write some code to interpret these number pairs, but if you are looking for a ready-made open-source firmware, I’m not sure what is available. I believe the Sisyphus firmware is proprietary.

1 Like
5

Thanks looks like I need to do some reading.

6

That sounds very cool. Somewhere a long time ago, in one of the early ZenXY discussions. We talked about some polar designs.

A slip ring would work. Barry said they wouldn’t work for very long, but it is all relative. If you were able to tuck in the control board too, and only sent power and a signal through the ring, it might be easier. Otherwise, it is 4 pins per motor and 2 pins per endstop.

That kind of design has one motor that is 100% in charge of rotation and the other motor is 100% in charge of the radius. In a SCARA machine, changing the radius requires both motors to move (in opposite directions). And changing the angle requires both motors to move (in the same direction). So SCARA gcode won’t work for your machine.

Marlin or grbl (firmwares) can control those motors. But they will have no idea what they are controlling. You need the software (sandify or some intermediate layer) to write out a gcode script where X moves the angle and Y moves the radius. It has the same challenges as other polar machines (infinite rotation, lines become arcs, endstops need to be pass through). But it would be a different mode.

I can do that. If you are the only one using it, I would start with a python script to convert .thr into your polar gcode. After a few more people build it, I can add it to sandify. But I won’t write the python script until you have something to test it on. It is the same process we used for the SCARA builds.

There is another polar mechanism I came up with in those early polar talks. One motor would rotate a big ring (with a GT2 loop, so it would be infinite rotation). The other would be inside the ring, exactly in the center. It would have a gear for a rack and pinion. Both motors would stay stationary.

If the middle motor moved, it would push or pull the tool (magnet) out and in (the radius). If the outer ring rotated, it would turn the tool arm (angle). The only trick is that rotating the outer ring would also rotate the rack relative to the pinion. So any rotation would also have to have a small correction in the radius motor.

That’s another thing that would be easy to fix in a post processor script or within sandify. It has the advantage of no moving electronics. But the mechanism needs to keep good contact with the middle gear while rotating the rack, and it needs to support the tool. Let me know if you want to brainstorm more on it. I can make a quick drawing.

The other challenge is endstops. You need to be able to measure the end location (of at least the radius axis). Unless you are ok with rotated patterns, you also need to know the location of the rotational axis. But you also need to let the rotation (and possibly the radius extension) move through that endstop. So it can’t be a hard limit. Optical sensors and flags or reed switches and magnets work. But you need to do a little bit of software to come at them from the right direction. And ideally, the wired part would be stationary (or at least on the side with the controller).

3 Likes
7

Thanks @jeffeb3 between your advice and @robertbu I think I can move forward.

2 clarification questions:

  1. would it be easier from a coding perspective for the “gantry” to travel across the diameter or do I just need it to run on a radius?

  2. What are your thoughts about using a plain old drive wheel on the end of the gantry instead of using belts and gears.? Basically a robot that drives around the perimeter of the table. I cant imagine the slippage being too bad if I use some kind of rubber wheel and it would greatly simplify the device.

Thanks!

8
  1. Sandify doesn’t have any concept of driving through the center. All radiuses are positive. They Sisyphus table added a second magnet on the other end that will drive on the negative radius side, but the patterns just end up weird.
  2. Normal wheels work with gravity. You would be working against it. You would need something to push the wheel up to the bottom. That means your rotation mechanism has to support that torque, and the bottom of the sand (which has to be thin) needs to support the pressure the other way. I’m also not sure if powered wheels would have near enough precision. A DC motor is pretty sloppy compared to a stepper motor.
2 Likes
9

Sorry my words failed me on my description. I was thinking of a two story table with the wheel running on the lower story and the sand story above. I would use a stepper motor to drive the wheel and depend on friction to not have significant slippage.

The reason I’m curious about the design is that it could scale really big. Maybe not useful for a sand table but imagine a 15 foot zen garden that could have the sand groomed by a cnc. Drop the center of the machine in a piece of pipe and have it drag a trough to make the design.

Anyway the big one will probably never happen but its the way my brain works.

1 Like
10

You could also do a GT2 loop for the inner motor instead of the rack and pinion (drive pulley on motor going to an idler pulley on the edge, or if you wanted to go really fancy and allow a negative radius you could throw in another near the opposite edge and probably a couple more to help with tension). You might lose a little bit of the travel (the width of the pulley or so), but it would be fewer unique parts and less worry about holding the rack against the pinion. Though in exchange you have to tension the belt, so it’s not necessarily better, just different.

2 Likes
11

Yeah. The belt would work too. It doesn’t have to be a loop, since it doesn’t have to go on infinitely. It could be attached to the tool on both sides and then act like a loop.

1 Like