Filipe - thanks for the feedback. It's important, particularly while we're still fiddling with early implementation.
From: andy pugh [mailto:[email protected]] > On 3 December 2016 at 21:23, Filipe Tomaz <[email protected]> wrote: > > The G71 on most all machines take the current position (before the > > cycle) as the "stock". > > In your implementation this is not taken in account, and you look > > for the maximum programmed X value as the stock (if I add a extra > > movement, for example to X=40 it would be ok). > The version we have been working on is meant to take the starting X as the > stock boundary. > The problem you are seeing is actually that the profile has no "end" > move to it. The code doesn't know where to end the cuts, so doesn't start > them. Bug present in both the python and C implementations. It _should_ pretend the final move is to X infinity. Discussion ongoing on the best way to handle this. > I agree that this isn't correct behaviour. The solution is likely to be to > add a retract move to starting X at the end of the profile. > Or, possibly, to flag an error if the profile has no end-of-cut segment. I'm of the 'flag an error' school of thought. I feel it's better to train the user then to make assumptions about what they intended. If not, see above. > If you add a G0 X30 to your profile block in the first example then you will > get the expected behaviour. > A "feature" (and I don't know if it is a standard one) of this implementation > of the cycle is that there is no X-clearance added to > G0 moves, which I why I suggest a G0, as the area between entry and exit G0 > moves will be cut completely. > > Also, the retract that is implemented to make the pockets are to > > the Xmax position that you have. I understand that it is for safety, > > but at the same time is seams unproductive. Image attached also, > > where a looong retract is shown. > A more intelligent retract is something I intend to look at. Initially only > retracting as far as the highest inter-pocket peak is probably a good start. > I suppose a fully-optimised version could only retract the minimum it needs > to to get from A to B (but that needs an extra data structure just to store > the retracts) Getting the most efficient retract is fiddly, I'd rather have a safe retract than a fully efficient (but potentially unsafe) one. Will bear in mind. > > I also tested with compensation. I think that the compensation is > > not taken in account. Am I correct? > That is correct. We fully intend to support compensation, it's important. The > reason that it isn't in this Python "mock up" is that I would have had to > re-create the entire tool compensation code, and that wasn't the point of the > exercise. Compensation in one direction is pretty straightforward in the C code. Compensation in two directions _shouldn't_ be much harder, but I'm reserving judgement until it's done. Also, compensation for type1 isn't hard, type2 comp is tied into anti-gouging. Note to self: get a good offset algorithm. > > I normally use the back tool post, so I hope that I am not saying > > anything silly. Either way another fine work, thank you Andy. Oh good! a tester using the back toolpost. Since I normally work (and think) in terms of a front toolpost it's sometimes really hard to think the other way around. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
