Hi Rod! On 04/12/2014 02:28 PM, Rod Fitzsimmons Frey wrote: > Turns out that when I actually CUT something other than air, using the > loose tolerances (even 0.02) gives me unacceptable faceting. I don't need > *accuracy* per se, but I do need smoothness. > > I don't think I'm trying to operate at outrageous speeds - about > 2500mm/min. Maybe my acceleration is set too low? Or too high? I didn't
Is this 2.5m/min your actual cutting speed? If so, then your problem might just as well be the update rate of the motion planner and/or the position controller. This is 41.7mm/s or 0.042mm/ms, so if your servo thread runs with the default 1kHz, the position deviation can be more than your set tolerance after half an update cycle already. What happens if you do a straight cut (one single G1 move) over, say, 30mm (just long enough to make sure that you reach the programmed feed)? If everything is fine, then I would try to lower the servo thread period and/or using the new TP. If it is only fine when just a single joint is moving but bad if you do a diagonal cut, then the problem may be the position controller. If you don't get a good result either way, then there could be a problem with the drives, a badly tuned position/velocity controller, time jitter, or something else. > give too much thought to the acceleration limits - I didn't know how to > determine it for a servo system. (On stepper systems I just increased it > until I lost steps, then backed off 10% or so -- scientific, hey?) > Wow, going to 10% below stall acceleration on a stepper system sounds quite adventurous to me. Anyway, figuring out the maximum with a servo system should be easier, at least if your hardware can handle the maximum torque of the drives. Just set the acceleration limit to some insanely large value (100'000mm/s^2 or so) and then do a G0 move with one joint at a time while logging the encoder feedback with halscope. You'll probably need to temporarily raise your FERROR and MIN_FERROR to about the magnitude of the move for this. What I would expect on the scope then is the typical response of a PT2 system (like this one, with or without the overshoot: http://buchholz.hs-bremen.de/rtfr/rtfr.htm). The slope of the first (rising) part of the curve is then your maximum acceleration. Lower it by a few percent and you should have a good value for the parameter. But remember that this is tough for your hardware, so if you are not sure if the drivers and the mechanics can handle the maximum current and torque of the motor, then you should be a bit more careful with the set acceleration value. A safer approach would be to start with a low value for the acceleration limit and increase it until you get a noticeable deviation from the programmed path at the start and end of the motion. Happy tuning! Regards, Philipp > > > > On Fri, Apr 11, 2014 at 4:48 PM, Robert Ellenberg <[email protected]> wrote: > >> Hi Rod, >> >> This is actually a good example of why G64 is a bit confusing at first. >> Since you haven't specified a Q word, G64 with a P tolerance by default >> uses the same tolerance for the naive cam detector. What that means is >> that your command here: >> >> G64 P0.05 >> >> Is interpreted by LinuxCNC to mean this: >> >> G64 P0.05 Q0.05 >> >> I'd be willing to bet that if you used this setting instead, it would >> revert to the "ugly" behavior: >> >> G64 P0.05 Q0.0 >> >> -Rob >> >> >> >> >> On Fri, Apr 11, 2014 at 4:19 PM, Rod Fitzsimmons Frey <[email protected] >>> wrote: >> >>> G0 P0.05 worked like a charm! Thanks Viesturs. I'll have to go read the >>> code to understand the behaviour. >>> >>> >>> On Fri, Apr 11, 2014 at 4:16 PM, Rod Fitzsimmons Frey <[email protected] >>>> wrote: >>> >>>> Perhaps I'm confused about G64? From the docs: >>>> >>>> G64 is just blending and the naive cam detector is not enabled. G64 >> and >>>> G64 P0 tell the planner to sacrifice path following accuracy in order >> to >>>> keep the feed rate up. ... G64 P0 has the same effect as G64 alone >>>> (above), which is necessary for backward compatibility for old G Code >>>> programs. >>>> >>>> I'll try the small value for G64 instead. I'm not concerned about >>>> accuracy in this application - .005" would be fine. >>>> >>>> I'll definitely have a look at the new trajectory planner too! >>>> >>>> >>>> On Fri, Apr 11, 2014 at 3:28 PM, Viesturs Lācis < >>> [email protected]>wrote: >>>> >>>>> 2014-04-11 22:15 GMT+03:00 Rod Fitzsimmons Frey <[email protected]>: >>>>> >>>>>> I've set G64 P0, which I think should eliminate motion mode >> concerns? >>>>> >>>>> >>>>> P0 means that max allowed deviation from defined path in order to >>> maintain >>>>> velocity is equal to as much as total zero, so it really eliminates >> not >>>>> only concerns about motion mode, but also any options to try to >> maintain >>>>> the velocity. Try increasing it to something like 0,02 and see, if it >> is >>>>> better. >>>>> >>>>> I would say that this particular case is a perfect guinea pig for the >>> new >>>>> trajectory planner :) >>>>> >>>>> Viesturs >>>>> >>>>> >>> >> ------------------------------------------------------------------------------ >>>>> Put Bad Developers to Shame >>>>> Dominate Development with Jenkins Continuous Integration >>>>> Continuously Automate Build, Test & Deployment >>>>> Start a new project now. Try Jenkins in the cloud. >>>>> http://p.sf.net/sfu/13600_Cloudbees >>>>> _______________________________________________ >>>>> Emc-users mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/emc-users >>>>> >>>> >>>> >>> >>> >> ------------------------------------------------------------------------------ >>> Put Bad Developers to Shame >>> Dominate Development with Jenkins Continuous Integration >>> Continuously Automate Build, Test & Deployment >>> Start a new project now. Try Jenkins in the cloud. >>> http://p.sf.net/sfu/13600_Cloudbees >>> _______________________________________________ >>> Emc-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-users >>> >> >> ------------------------------------------------------------------------------ >> Put Bad Developers to Shame >> Dominate Development with Jenkins Continuous Integration >> Continuously Automate Build, Test & Deployment >> Start a new project now. Try Jenkins in the cloud. >> http://p.sf.net/sfu/13600_Cloudbees >> _______________________________________________ >> Emc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
