On Thu, 7 Jun 2012 14:17:32 +0100 andy pugh <[email protected]> wrote:
> On 7 June 2012 14:00, charles green <[email protected]> wrote: > > > i see only two approaches: the rotation axes are purely for > > indexing between various angular offsets without any coordination > > of other movements (i.e. stay clear of spinning mechanism), or > > incorporate the absolute cartesian positions of the rotation axes > > into a calculation of resulting movements. > > The rotary axes typically roatate to reach their endpoint at the same > time as the linear move. This works fine when there is a linear move, > but does mean that the feed rate needs to be compensated or you get > the helical feedrate problem you mentioned. > The simplest way to achieve what is required is to use "inverse time" > feed rate, where you say how long the cut should take (presumably > having hand-calculated the actual cut length). > > With the cylindrical kinematics idea being discussed here I _think_ > that the rotary would be seen as a linear, and the feedrate calcs > would just work. But I could be wrong. > Rethinking this a bit. Since g-code has sin() and cos() it should be possible to do the transformation directly in g-code at least for testing. Takes a bit more thought in writing code tho. ;-) Dave ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
