On Fri, 27 Jan 2012 19:17:18 +0100, Spiderdab wrote:
> On ven, 2012-01-27 at 17:27 +0000, andy pugh wrote:
>> On 27 January 2012 17:18, Spiderdab <77...@tiscali.it> wrote:
>>
>> > I personally think this kind of bug are of a main importance, and 
>> that
>> > also should be simple to solve
>>
>> I am not sure it is, in the general case..
>>
>> Working out the boundary of the space that a non-trivial mechanism 
>> can
>> reach while staying inside its joint limits isn't especially easy.
>>
>> The only way I can think to do it is to virtually run through all
>> possible positions. I suspect that the answer should be that a
>> non-trivial machine shouldn't have soft limits in space, only on the
>> joints. It should be possible to check that the inverse kins returns
>> valid joint positions for all end-points of a G-code program, but
>> testing whether intermediate points of arcs are possible is not
>> particularly easy without running the G-code through "virtually"
>>
> Well if it's so difficult to retro calculate the possible
> volume-position from the kin module (and it seems like that..), we 
> could
> add a lot-simplified limits-volume. Let's say i want my machine to 
> warn
> when x,y,z position exceeds a box, or a sphere or a cylinder, given 
> by
> those dimensions (dimensions..).
> I think the 99% of machine can stay into similar limits.
> Then the machinist must take care of particularities, like holes in 
> the
> egg!
> In my opinion it should be simple and very effective.

If you can generate the full surface envelope, then you should also be 
able to define an offset-surface as a soft-limit/warning -- say withing 
1" of any limit envelope.  This is likely to be expensive, but only 
needs to be calculated once upfront during initial configuration.  Also, 
if you can take a limit surface as parameterization input, the surface 
itself could be generated by a CAD or CAGD tool and you would not have 
to worry about implementing some of these functions (which can use mind 
bending math).  In addition to hard/soft motion limits, there is also 
the "safety envelope" -- that extra margin you want to keep people/stuff 
out of.  This can be calculated in the say way as above.

One computationally expensive, but straight forward, approach would be 
to collect tool reference position iterated over the motion of each 
actuator.  Hmmm that is about as clear as mud...  Try this:

   for axis(1) start=left mechanical limit to finished=end mechanical 
limit, and some minimal step do

     for axis(2) ...

       for axis(3) ...

         .........

                      print position in XYZ (and axis positions if you 
care)

Now generate a constrained iso surface over the cloud.  If you do this 
right, you will get both the exterior surface and any holes.  One tool 
that should be able to calculate and visualize such an iso surface is 
the Visualization Tool Kit (VTK).

Hoe this helps.

   EBo --

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to