On Monday 03 May 2021 11:42:54 Jon Elson wrote: > On 05/03/2021 02:57 AM, Gene Heskett wrote: > > More specifically, which of the F's is suitable for forcing a closer > > to null settling point when there is considerable friction in the > > system? > > That's the problem! Friction is nonlinear, and it hurts > during acceleration but HELPS during deceleration. So, a > single FF2 setting can never be optimal. You have to use a > compromise value. > Or, my middle of the night idea about some jitter in the control signal. Derived by something like this outline.
Friction will of coarse vary, but assume the amplitude of the jitter is constantly reset to zero by a passing edge from the encoder, but it times out in 2 millisecs. Leaving the pwmgen outputing a very low duration pulse in one direction or the other because the combo of friction and a d term combines to coast it to a friction stop, some 30 arc-seconds from where the gcode sent it. Now, because the jitter control has timed out, a counter watching each direction pulse is free to increment its count. That counter is added to the control signal in the direction to reduce the error. And its incremented by the pulse from that pwgmen's dir+ or dir- output. And in a few milliseconds the motor will move enough to output an encoder edge. That resets the counters, and the motor will not have enough to keep moving. But the pwmgen isn't satisfied yet so it keeps on outputting a 1% duty pulse on one or the other of its dir signals, Wash, rinse repeat, the motor is constantly being tickled enough by a 1 count move in the wanted direction until the pwmgen sees a match and stops tickling the motor. > > Something that will see it sitting at 3% power constantly, and will > > raise the gain enough to move it another arc-second for a more > > perfect null. > > The FF's will never be of value there. Debateable, FF1 is someplace in the 20's to get a cruising error null. > This is what the I > term is SUPPOSED to help with, but I > have not found it to really accomplish much. I use it, but determining the value is a puzzle, Here is whats working fairly accurate, and stable for that BS-1 clone. #******************** # Axis A #******************** [AXIS_A] MAX_VELOCITY = 30.000 MAX_ACCELERATION = 1500.00 [JOINT_3] TYPE = ANGULAR HOME = 0.0 HOME_SEQUENCE = 3 HOME_SEARCH_VEL = 9.0 HOME_LATCH_VEL = -1.0 HOME_FINAL_VEL = 30 HOME_OFFSET = 4.498500 VOLATILE_HOME = 1 FERROR = 0.50 MIN_FERROR = 0.25 MAX_VELOCITY = 30.000 MAX_ACCELERATION = 1500.00 P = 6000 I = 0.500 D = 0.500 FF0 = 0 FF1 = 21.5 FF2 = 0.55 BIAS = 0 DEADBAND = 0.00015 BACKLASH = .00001 MAX_OUTPUT = 900.0000 SERVO_SCALE = 666.6666666666667 PWMGEN_TYPE = 2 Thr MAX_VELOCITY is restricted to keep it from overshooting and reversing the motor to come back, but at the higher speeds, that controller, a dual BTS-7960 tries to reverse it at speed, crowbaring a 450 watt 24 volt supply, which needs about 3 minutes to cool and recover. I can go to at least 25,000 for Pgain before it starts to oscillate but its noticeably less stable above 15,000. > That may have > more to do with the servo characteristics of my machines, > though. Each system seems to write its own rules. > Jon Take care and stay well Jon. > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
