Phillip, et al, Turns out, I don't think it has to do with the ferror settings. The head is pneumatic, so I am using M64 and M65 for head up and down. The last thing I did before going home was to disable the head up / down output. When I run that way, the following errors go away entirely. There is still a dwell, so the axes have time to come to a complete stop, just as if the head were going up and down.
The head is relatively heavy and does shake the gantry when it goes up and down, particularly down. But I am using this same technique on other machines without an issue. This head is larger and heavier than on any other machine, however. But again, looking at the joints ferror when the head is going up and down is still trivially small, a couple hundredths at most. Regards, Eric On August 26, 2017 5:20:47 PM EDT, Philipp Burch <[email protected]> wrote: >Hi Eric! > >On 26.08.2017 22:48, Eric H. Johnson wrote: >> Jon, >> >> ... >> >> After doing this however (and possibly other config changes I have >made along the way), I am getting persistent following errors. >> >> At the moment they always occur at head lifts / drops, when X and Y >have basically come to a stop. Head lifts are performed by an air >cylinder and give the system a bit of a jerk. Mostly I am now getting >following errors in X and A. >> >> I cannot reproduce this with individual MDI moves, for example. I set >the following errors in the config absurdly high, but does not seem to >have any effect. Watching the joint ferrors with halmeter or halscope >shows these ferrors to rarely exceed 0.01". My positional accuracy is >quite good too, hitting end points within 0.001 or 0.002 at worst. >> > >As far as I remember, there are two kinds of following error tolerance. >One is the velocity-dependent tolerance FERROR and then there's the >static MIN_FERROR, which is used when a joint is in position (or moving >very slowly). In case you did only extend the former, that would not >have changed anything for the described problem when the joints are not >moving. > >Bye, >Philipp > >> Regards, >> Eric >> >> On August 26, 2017 3:15:02 PM EDT, Jon Elson <[email protected]> >wrote: >>> On 08/26/2017 12:39 PM, Eric H. Johnson wrote: >>>> Andy, >>>> >>>> Yes, as TYPE = ANGULAR in the joint section. >>>> >>>> As for P, yes that would seem to agree with what I am seeing. >>>> >>>> I made some headway by starting at 24000 counts per degree (actual >>> counts per revolution). Tuned that in, then did the same at 1000, >500, >>> 250 and 125. Still struggling at 66.6666. Can get it to run slowly, >but >>> goes unstable at speed and sometimes when nearing the end point. >>>> >>>> >>> Yes, the problem with the PID is that when the scale value >>> going in is very low, the jumps in the user units when the >>> encoder or step count changes by one is much larger. Since >>> position is quantized by either step count or encoder >>> counts, there isn't a whole lot you can do about this. The >>> best is to set the FF1 as closely as you possibly can with P >>> and D very low, use FF2 (with real servos only) in tiny >>> increments to help with acceleration, and then raise P until >>> the error is acceptable. D should be at the minimum you can >>> live with, as increasing D just amplifies the encoder count >>> jumps. >>> >>> Some systems have velocity estimation that tries to smooth >>> out the velocity jumps caused by this. If you are NOT using >>> velocity estimation where it is available, I think you will >>> find it helpful. >>> >>> Jon >>> >>> >------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Emc-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-users >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
