I am designing an oval sand table and was wondering if one of the choices for Type could be ellipse. Before I start building anything I want to be sure I can actually fill in the area. Thanks
Pete
I am designing an oval sand table and was wondering if one of the choices for Type could be ellipse. Before I start building anything I want to be sure I can actually fill in the area. Thanks
Pete
What kind of mechanism are thinking? What size?
With a little extra border, a SCARA could work. Those have trouble being rigid at large sizes. You would have to be careful with the inputs because the firmware won’t limit the mechanism and it can collide with the small size.
Sandify can’t make an ellipse mask. It can do a circular mask and then scale the whole pattern. So you’ll have some more work to do to make patterns.
Thanks for you quick reply Jeff. The size of the drawing oval will be 24" by 15". I am using a theta-rho mechanism that can extend beyond the 15 inches when its in the long end of the ellipse. I figured that if Sandify can’t mask the ellipse, I will have to generate my own patterns to get into those regions outside the central circle within the ellipse. I’m a software engineer, so I have no problem writing a post-processor for the .thr file. But I have no idea how I would remap things in the ellipse ends if generated by Sandify.
If your extension amount was based in firmware on the theta and not on coordinates, then circular patterns would automatically be stretched to fill the ellipse.
Another possibility is to have a mode or feature where the pattern would be clipped to the ellipse, either in firmware or by postprocessing.
I’m pretty good at math, but figuring out where and how to clip is probably beyond me. And it’s not just a simple clip. I think I would have to then plot a line connecting the clipped one to the clipped line that would have returned from the edge of the circle (or maybe it wouldn’t have). I haven’t thought about this enough to understand the implications of clipping (would it make the drawing look bad?).
The clipping code is deceptively complex. Most of the issue is deciding where to add a vertex that clips the line.
Theta rho is already a bit weird though. If you asked it to go from X,Y: 10,10 to X,Y 10,200, and just converted those coordinates to thr, it would draw an arc. It is also a bit tricky because theta can roll over (in fact, it has to).
So sandify computes everything in X,Y. Then it clips to the machine shape (which is a bit of an estimate for a circle and would definitely be more complex for an ellipse). Then it subsamples all of the XY lines to be fine resolution, then converts those 70,000 point to thr, keeping the angles consistent as it rolls over.
That would all still work for you, but there wouldn’t be an ellipse clipping. But I do have a work around. If you make whatever pattern you want and then add these three effects, it should work:
I’m sure there will be weird quirks. For example, there isn’t really a good way to add these effects for every layer, and the resize may have to be computed every time. You could probably have a process where you use someone’s pattern, or save you own, then import it into a layer that just has these effects set up first.
I’m confident you would be able to make some patterns that were 98%+ right. But there are just a few things that would be hard or impossible to actually perfectly fix.
However, I have a lot of confidence that you could get it to work. I am happy to help you, but probably unwilling to change sandify for this edge case until there are more elliptical tables in existance. The SCARA tables were the same way. I started with a post processing script, and eventually got it into sandify when there were a half dozen users or so.
If you’re not making your own firmware, I don’t think the machine will have any ability to protect itself from bogus inputs. So you need to make sure you don’t add any gcode/thr files that will make it crash. If you do write your own firmware, it would be easiest to just break up every move into a ton of small moves and it if ever crosses over the polar equation for your ellipse, clip the max radius on that tiny segment and it will be good enough.
I’m kind of looking forward to figuring out how to do it. I totally understand you don’t want to modify Sandify unless there is more of a need.
I’m not writing my own firmware. I’m using a Raspberry Pi to input and post-process the files and then send them to a Grbl board after converting to the appropriate GCode.
For the rho limit checking, I think I will avoid trying to do it in software and instead wrap a conductive strip around the inside of the limiting ellipse and attach a sensor to the end of the magnet arm. Feed the sensor output into the Grbl board and it just might work.
Ok. You should be able to just convert the theta and rho directly, since you still have a polar machine.
Make sure you have a way to clear the offset and home the machine. Both angle and radius. You don’t want it to unwind 100 rotations to get to the 0 angle in the next pattern.
Homing on polar machines is a little tricky, since optical endstops have a significant width. You might be able to trick it with a sequence like:
That should keep the homing position on one edge of the optical endstop.
A regular microswitch will feel the edge, without having to use metal tape or trusting the connection from the wire to the tape.
I think you can easily detect when the thr exceeds the limits in your post processor. Even if you just stopped when that happened, that would save your butt at least once. If you just put in the smaller vertex, some lines would be weird, but that would still be better than crashing.
Keep me posted. It sounds interesting.
I appreciate your observations and recommendations. I hope to have the basic theta-rho mechanics ready next week and will hook up the electronics and we’ll see what happens.
Okay. So I got distracted by some other projects, but have now found my way back. I have completed the base mechanism for theta-rho and have been testing it with software I wrote on the PC (Windoze) driving a SKR Mini E3 V3.0 stepper controller that is Marlin-based. There are issues.
Before I continue, I’d like to make sure that after all this time, someone is still paying attention. I have viewed all posts in this forum related to theta-rho gcode generation but haven’t found anything that totally relates to my issues. And most of those were a few years ago. Anyone still working on this or finished solving it?
Theta rho is still working fine for the thousands of sisyphus machines out there. Sandify is still under active development.
I’m not sure what you’re asking though.
I’m trying to figure out how to get theta-rho coordinates to work on a Cartesian coordinate system as implemented on a Marlin (or grbl) controller.
I scaled the Marlin X motor to steps/radian (theta) and the Y to steps/mm (rho). I had to change the thetas from absolute to relative, since Marlin didn’t like negative numbers as a coordinate. This worked ok, but when I used Sandify to generate a circle, both motors stuttered a bit. The rho stuttered because it was changing very slightly (in the fourth and fifth digits) above and below the actual radius. I eliminated this by rounding to the nearest thousandth of a mm. I think the theta axis is stuttering because of the motion planner, but I’m not sure. In addition, the X and Y speeds are not constant and depend on how much each one has to travel with respect to the other.
I have seen people in the forum trying to do the same thing, but they never finish the thread with their solution. Maybe it can’t be done using a standard CNC controller and gcode. I have some further ideas to try, but was hoping someone could save me some time.
Sisyphus probably uses custom code to generate the stepper control and I doubt they would be willing to share it. It probably wouldn’t work with a CNC controller anyway.
It should be fine with negative numbers. Do you have soft limits enabled? You should be able to turn those off for one axis or both.
Can you paste the first 50 lines of a converted gcode? I want to look for anything glaringly wrong.
This can be done. I have helped people do this and some have succeeded. You’re a SWE, so I think the remaining issues are in our wheelhouse.
They did share their raspberry pi image at one point. They use a grbl controller under the hood. They may have edits now, but it used to just be a basic grbl. But you don’t need it. You are really close. I think it would mostly be a distraction at this point.
Can you share some pictures of your machine? I am curious about the mechanism and the overall look.
The following spreadsheet shows about 40 lines of a 200 mm diameter circle in a space with a 150 mm max radius. The first 18 lines it’s moving rho to the radius and the remaining it’s sweeping the theta. Notice that when its rotating, the rho values vary in places 4 and 5, going below and above a central value. I wouldn’t think the stepper controller would even show this deviation, but the stutter is there.
The theta values are either monotonically increasing or decreasing, which is what they should do, but I still get a stutter. It almost seems like the motion planner is bringing the stepper to a complete stop, and then doing the next motion.
The other issue is the wide variation is speeds of theta and rho. I think I know why that is happening, but it would mean updating max travel speed on one of them each time certain conditions are met. I would love to know how Sisyphus handles this.
What steps per unit do you have set on X and Y in Marlin? Ideally, those are not too low or too high. Our usual machines are in the 50-200 range and we use 3-4 decimal places. You can play games with marlin because you aren’t exactly using mm. You can change the steps per mm and the precision of your output.
Can you also paste the actual gcode you are sending to the skr?
What microstepping are you using? I would use 16 and the TMC setup has an interpolated microsteps, which I usually leave at the default of 256
My table moves at lot slower in the middle of the table. It isn’t about to win any races.
I would set a max X and max Y speed and then just use a very high F speed on every move. But you also need to have a reasonable acceleration for the units you use. The steps per unit will be a big clue. I think you are close. You just need some tuning.
I’m a little confused by that. The steps/unit are fixed by the physical drive mechanisms: pulley ratio, threaded rod TPI and stepper microsteps. Marlin says there’s a gcode to change the latter, but it doesn’t work. They seem to have fixed it at 4. Therefore I get 2675 usteps/radian and 1200 usteps/mm. These seem good to me in light of the small values generated by Sandify. Once you get down to a small number of usteps, I think motion and accuracy get dicey. Many of the theta values in my circle are 0.02 radians or less. This works out to 53 usteps. The table in the previous response has the gcode values.
The issue I have with varying speed is with it changing significantly within the outer areas. This happens with an ellipse where theta is changing rapidly and rho is almost constant, and the reverse. I have been using a high, constant F, and setting the max X and Y. It seems like I will have to do more post-processing and insert new max values when theta and rho are changing at very different rates. I have messed with the acceleration a little and will continue to do so.
You don’t have to use mm or radians for your machine. You can choose whatever units you want (even make up new ones).
That seems quite high, but a radian is a big number.
I would change that to something easy to understand and in a more sensible range. Degrees would make a lot of sense, actually. That would put your usteps/unit to 46.67 (although redo your math from the rotation, you’ll probably get a better precision number). Then make your script output degrees. That should fix the rounding errors.
Then I would make up a unit for your rho that was about 360 from center to the end. That way, if you put in F3600, it will move 10x rotations in one minute, or 10x extensions in one minute, or any combination in between.
You can decide what unit to use. It can be 1/4mms if you want. You just have to match the unit in your gcode output and the markin usteps/unit.
I had assumed that the choice of units was somewhat arbitrary, since no matter what the units and corresponding conversion factors, the end result of a given value (whether in degrees, radians or furloughs) has to be the same number of steps to the motor.
However, since this wasn’t working, I took your advice and used degrees and 1/10mm as the units. This worked much better. This leads me to believe that the Merlin software (the motion planner?) does not like dealing with numbers less than 1.
However, it still suffers from noticeable speed changes when theta and rho are changing by very different amounts (as in the aforementioned flattened ellipse). Are you using a Sisyphus? I assume the movement of the ball is very steady, even when it slows down near the center. I keep thinking I am missing something obvious. I’m running out of ideas.
It can run on very old processors and the limiting code is probably reading the gcode. Reading the 6th decimal place is not fun in highly optimized code. So my guess is that it has more to do with the number of decimal points or even the total number character length.
I have one. I don’t use it every day. It does go much slower in the middle (the angular speed is pretty much constant). It also moves pretty slow, in general (it can go faster than I use it. I want it to be relaxing).
Now that your units are tuned, what are the values of acceleration and speed for those axis? And what F speeds are you sending?
A video (posted to youtube or google photos with a link here) would help me see the problem explicitly.
I think you’re pretty close. Don’t give up. We can fix this.
I have put a video, screenshot and thr/gcode files on my OneDrive directory
The parms for this run were:
theta - ustep/deg = 46.55, max speed 45 deg/sec, max accel 50 deg/sec/sec
rho - ustep/1/10mm = 120, max speed = 500, accel = 2000
F was set to 5000 units/min