Thinking that a direct motor reverse is a bit brutal on both the motor, and probably explores the current limit facility built in the Pico pwm servo amp, I tried adding a limit3 between the signal from motion.spindle-speed and the input to pid.s.command, which was formerly a direct net in the .hal file.
Without it, a spindle reversal from 1000 rpms is accomplished in just a fraction of a second. But while it did slow down the turn around of the spindle, I am getting a huge overspeed in the new direction until it settles back to the commanded rpms. Not at all usable IMO when the spindle may be turning 350 revs driving a 4-40 tap in a G33.1 cycle, and the reversal runs the spindle up to 2850 revs. The head keeps up, but still it looks dangerous to me. It literally goes wide open and jerks the tap out of the hole, in perfect synch, beautiful threads. A larger tap would be self cleaning by spinning itself clean. Now theres a grin causing thought. :) One of the things I did in hacking up this filter, basically a 4 stage shift register with all 4 stages feeding a triplet of sum2's, with a weighting scale factor of .2500 so basically the final sum2's output is the updated average of the last 4 encoder transitions, unforch this results in single value being clocked thru the sample_holds by the servo-threads repetition cycle when the spindle is turning slow enough that we get the same reading several times in between transitions. Thats pretty slow as the encoder disk has 268 edges per revolution. So at low speeds, the filter degenerates into whatever the last edge transition set into the 5i25's registers by clocking that value all the way thru the shift registers the S_H's are in about 5 milliseconds. So I made a hold signal out of a comparison between the encoder out and the S_H's first stage out. But, and this is what I think is actually biting me, the encoder and the S_H's have to have a conv_float_to_s32 and vice versa wrapped around them. So I may as well just go ahead and either junk the whole idea, or figure out something that does not need all the float to s32 and vice versa. Sample_hold is s32 except bit "hold", and the man page doesn't even say what state is hold & what state is fall-thru. comp is float, incompatible with the S_H Sum2 is float, incompatible with the S_H So the processing chain is too long and likely in the wrong addf sequence. But it would be a huge help if we had a float version of the sample_hold. Any chance of that ever happening? I'll test the theory that the filter delay is the culprit by bypassing the filter. Another possibility is that at the instant of polarity reversal going into the .command port of pid.s, a reset signal could be slammed into the pid.s to cancel any effects of the spindles overshoots in the wrong direction, the lack of which is causing a windup in the pid. Halscope should be able to show me that I would think. But how to generate that, I haven't a clue, but that almost HAS to be the cause of the windup/catchup. A 2nd question then, pid.s.error-previous-target, bit in, should be what for a velocity loop such as a spindle? Currently set true, by pncconf & I haven't touched it. Anybody else got a better idea? Thanks all. 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) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
