On Saturday, June 09, 2012 09:23:07 AM John Thornton did opine:
> Do you know if the same algorithm is used for G76? > > Thanks > John G76 is layered on top of the spindle synced motion that is at the core of G33, so yes, they both work the same. Keep in mind that I am recalling a conversation that I had with Chris probably four years ago. I didn't implement the fix, he did. It is possible that I'm mis-remembering something, especially about the fix. I know my description of the problem is accurate, but since I didn't do the fix, I wouldn't count on the details of the fix being right. Before editing the manuals, I would suggest contacting Chris and asking if my description is correct. (I'm not sure if he reads the users list consistently - there is a lot of traffic here. He does read the developers list.) On Sat, Jun 9, 2012, at 09:58 AM, gene heskett wrote: > > Here is my thought experiment: Rather than assume a lagging > index angle at the synch point, why not do that same math, > but use it to advance the start of motion to be that same > lag value, but used to issue the start motion at that calculated > angle in front of the _next_ index pulse, maintaining the > phase at effectively zero for all speeds at the time expense > of using 2 index pulse periods, 2 revs of the spindle to get > started for each pass. > > Or has this approach already been explored and turned down > in the back room for other perfectly valid reasons? I think it was discussed. I don't recall if there was some subtle problem that made it not work for some cases, or if it was simply a matter of being more complex, thus more difficult to implement and be sure that it was right. One thing to keep in mind - the spindle sync algorithms that are used for G76 and G33 lathe threading are also used for rigid tapping on mills. In that case, the spindle can reverse. Consider the situation where one index pulse arrives, we decide to start moving on the next one, calculate the offset so we can start before it arrives, then the spindle reverses and it never arrives. What if the reversal happens before we get to the calculated starting point? What if it happens after we get to the starting point, but we before get to the index? All those special cases need to be considered when designing an algorithm. The one we have now isn't perfect, but it is pretty good (based on the fact that it has been working for years before anybody ran into this issue.) There are a couple of sayings: "Good enough is the enemy of perfect" - meaning that when you have something that works fairly well, you tend to live with it rather than investing the work to make it better (and run the risk of making it worse). "Perfect is the enemy of good enough" - meaning that you can spend so much time trying to design something that will work perfectly for everyone under every circumstance, that you never get anything working at all. I don't claim to be an expert at finding the proper point between those two extremes... -- John Kasunich [email protected] ------------------------------------------------------------------------------ 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
