Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Open (i think) design for a parallel robot (reprap ma
Yes, a flat plane and a bowl are excellent tests for a hexapod. You
might also include a parabola. The focus point would be a good (if analog) measurement of both the overall shape and the surface roughness. Use it to reflect the sun onto something. The fuzzyness would reflect the roughness. The evenness would reflect the shape accuracy. Carl Mikkelsen wrote: What are good ways to measure surface smoothness? It would beinteresting sometime to attempt to cut a plane, and see what the error actuallyis, and somehow estimate what portion is quantization related, vibrationrelated, calibration related, and simple actuator error related.One test I can think of is to try to cut a "bowl", the inside of a hemisphere. I would think a lot of motion artifacts would show up in that, especially stickiness or backlash in the struts. Jon Elson |
Carl Mikkelsen
A decent parabola would require a rather large billet to start with, and a lot of material to be removed. I agree that it would be a good test.
toggle quoted message
Show quoted text
The proposed test came out of a discussion of quantization error, which intrinsically prevents a hexapod from cutting a smooth plane, unlike a Cartesian machine which could cut a perfect plane. What I was curious about is how to measure the small-scale deviations from the desired shape. Isn't this property called surface roughness? What is a simple way to measure surface roughness? -- Carl At 11:44 AM 9/4/2006, gran3d wrote:
Yes, a flat plane and a bowl are excellent tests for a hexapod. You |
Carl Mikkelsen wrote:
A decent parabola would require a rather large billet to start with, and a lot of material to be removed. I agree that it would be a good test.There are instruments that do this, surface roughness indicators. But, one other way is to do this backwards. Maybe the plane is the easiest, here. You mount a dial test indicator in the spindle, lock the spindle and sweep the indicator across the surface by CNC control. The deviation of the indicator tells the error. Sweeping an indicator across a granite surface plate would sure tell you whether the machine could move in a straight line. To bring it up to multiple axes, you could obtain a new bearing ball of the largest size possible, like maybe 2 or 3" diameter, and sweep the indicator around that surface. You'd need to make a heavy "nest" to hold the ball so it doesn't move. Jon |
Carl Mikkelsen
Jon,
toggle quoted message
Show quoted text
The large-scale calibration is fairly well covered by the simulated annealing method of estimating the systematic error parameters. This discussion grew out of concerns about quantization, and (I speculate) that quantization will cause a surface roughness on nearly any surface machined with a hexapod. The quantization-roughness may be far less than the roughness that comes from servo control system errors, vibration, chatter, or other effects. Have you been looking at EMC for hexapod controls? Do you know if it can generate the transformed actuator commands, independent of the real-time actuator controls? I don't have a G-code interpreter as part of my system, which certainly limits how easily I can import files from other people. Also, if EMC handled the dynamics of acceleration and setting the cut rate, it would simplify the job ahead of me. I'm wondering if I should try using spindle load (as measured by the current consumption or some other means) as a moderator on cutting speed, or is the key just keeping the tool and work cool and flushing the chips well. There is so much about actually machining that I need to learn. -- Carl At 12:38 PM 9/5/2006, you wrote:
Carl Mikkelsen wrote:A decent parabola would require a rather large billet to start with, and aThere are instruments that do this, surface roughness indicators. |
Carl Mikkelsen wrote:
Jon,I'm not an expert in this area, but the general flow is : G code interpreter trajectory planner kinematics servo control Since EMC can jog a hexapod in cartesian coordinates once the struts are homed, I think that basically proves it can already do it. Jon |
Carl Mikkelsen
Does EMC only handle trajectory planning in XYZ Cartesian
toggle quoted message
Show quoted text
coordinates, or does it also handle G-code interpretation and motion planning for 5 or 6 axes? -- Carl At 11:21 PM 9/5/2006, Jon Elson wrote:
Carl Mikkelsen wrote:Jon,<snip>Have you been looking at EMC for hexapod controls? Do you know if itI'm not an expert in this area, but the general flow is : |
--- In CAD_CAM_EDM_DRO@..., Carl Mikkelsen
<c.mikkelsen@...> wrote: deviations from the desired shape. Isn't this property called surface roughness?What is a simple way to measure surface roughness?A weird thought, entirely unproven, is to light the surface from a small angle, say 5 to 10 degrees. Then take a digital picture. Then measure the amount of high frequency component in the photograph (using a 2-d fast fourier transform). It requires some complex software, but the gadgets are pretty cheap. The notion is that the rougher the surface, the more dark-light jitter, so the more high-frequency components. |
Carl Mikkelsen wrote:
Does EMC only handle trajectory planning in XYZ Cartesian coordinates, or does it also handle G-code interpretation and motion planning for 5 or 6 axes?It does six, but they are not totally coordinated. By that, I mean that the commanded move velocity is only calculated from the linear axes. So, if you had a 3" round part on an A axis, for instance, and asked for a velocity of 1 IPM, and the move was 360 degrees rotation of the A axis at the same time as a 1" linear move in X, then the move would take 1 minute. But the total move length would actually not be 1", but something like 9.5", and should take 9.5 minutes if you are concerned about velocity through the cut. The problem is that RS274-D has no way to specify the radius of the tool to the rotary axis' center. I think there has even been a new feature added to the interpreter to allow these radius calculations to be performed, but I'm pretty sure this is in the interpreter, NOT in the traj. planner. (If I'm wrong on this one, let me know.) Or, maybe I'm just thinking of inverse-time specification of the moves. There was some discussion on the EMC list of this about 2 months ago. Jon |
to navigate to use esc to dismiss