On Wednesday 05 August 2015 11:26:23 Gene Heskett wrote: > On Monday 03 August 2015 16:52:33 Gene Heskett wrote: > > An update, PS, whatever And a second one. > > > On Monday 03 August 2015 10:46:58 John Kasunich wrote: > > > On Mon, Aug 3, 2015, at 04:19 AM, Gene Heskett wrote: > > > > The discussion is nice, but it still doesn't get me a signal I > > > > can strobe the .hold lines with. > > > > > > In my first reply to Andy I also included something aimed at you: > > > >> Gene: > > > >> > > > >> If you XOR the two quadrature signals together you'll get > > > >> one edge (rising or falling) on every transition. > > > >> > > > >> The HAL oneshot component can be configured to produce > > > >> a pulse on both rising and falling edges. > > > > > > Although now I see that you aren't using the software encoder > > > counter, you have a 5i25. So that means the individual quadrature > > > signals don't exist in HAL and what I described won't work. > > > > Correct. > > > > > Which raises the question: how fast are your quadrature signals? > > > If you are using a hardware encoder counter because your signals > > > are too fast to count in software, then your scheme is doomed from > > > the start. If they are too fast for HAL to count, they are also > > > too fast for HAL to do the summation, etc, on every quadrature > > > edge (or every fourth edge). > > > > > > Have you actually looked at a halscope trace of the velocity > > > feedback using the 5i25 counter with the spindle running at your > > > expected min and max speeds? Do you really know how bad the > > > jitter is, and what frequency it is jittering at? Is the dominant > > > jitter frequency one cycle per slot, or one cycle per revolution, > > > or something else? > > > > > > I don't remember every detail of every message about this encoder > > > project. Can you repeat the basics: > > > > > > 1) what is the lowest expected operating speed > > > > 50 rpm for sensing > > > > > 2) what is the highest expected operating speed > > > > 2500 if the motor is pushed to its short term limit > > > > > 3) how many slots on the wheel > > > > 67 > > > > This has to get thru one of those damned slow opto-couplers on the > > BOB's input. Because one of them was too slow, its been excised > > from the BOB and replaced by a jumper from the opto driver to P14. > > I may excise a few more of them before I am satisfied. > > That will get tested yet today, by cranking the spindle wide open, in > this case as fast as a resetable thermal in the motor will let me, > which is an s2200 the highest it will run without going into a 30 > second cooldown stop about once a minute. However, the encoder says > that it is actually turning something north of 2600 revs when asked > for 2200. > > The motor itself is under cover, and is not kicking any noticable hot > air out of the vents even after half an hour at 2600 indicated. And > this is with a dc supply of only about 118 volts when the motor is > off. > > The bottom of the quill is by then up to about 100F in a 72F room, > those spindle bearings are shit even when loosened up from the > excessive preload they shipped with. Before I loosened them up, it > would have been north of 150F by then. The bearing fit is excessively > tight, makes adjusting the preload pretty much a pad the shaft with > some alu and beat it with a hammer, check feel, when loose, drive > adjuster nut back about 1 degree at a time until no play can be felt. > Hell of a way to run a train IMNSHO. > > > > Thanks, > > > > > > John > > > > Thanks John. > > > > > > This is what I have written so far: > > and grep'ed from my working .hal > > #loadrt stuff > loadrt sample_hold names=enc0,enc1,enc2,enc3 > loadrt sum2 names=sum01,sum23,sumenc > loadrt conv_float_s32 count=1 > loadrt conv_s32_float count=4 > loadrt scale names=scaleX60 > > #addf category > > #************************************ > # encoder-velocity noise filter > # arrange these to save the previous modules state, > # otherwise it cascades thru in one cycle > addf scaleX60 servo-thread > addf conv-float-s32.0 servo-thread > addf enc3 servo-thread # so it saves enc2's output > addf enc2 servo-thread # so it saves enc1's output > addf enc1 servo-thread # so it saves enc0's output > addf enc0 servo-thread # so it saves encoder velocity > addf conv-s32-float.3 servo-thread > addf conv-s32-float.2 servo-thread > addf conv-s32-float.1 servo-thread > addf conv-s32-float.0 servo-thread > addf sum01 servo-thread # now total it up > addf sum23 servo-thread # ditto > addf sumenc servo-thread # ditto > # end of encoder filter sequencing > > #setp's needed > #*********************************** > # stuff for encoder noise filter > setp scaleX60.gain 60.000 > setp sumenc.gain0 .2500 # scale it back to unity > setp sumenc.gain1 .2500 # scale it back to unity > setp enc3.hold false > setp enc2.hold false > setp enc1.hold false > setp enc0.hold false > > #Then the working stanza stuffs > > # feed enc0.in > net spindle-vel-fb-rps <= hm2_5i25.0.encoder.00.velocity => > scaleX60.in net spindle-index-enable <=> > hm2_5i25.0.encoder.00.index-enable > > # gotta scale it to rpms, and convert to signed 32 for Sample_hold's > net encfilter.rpm0 scaleX60.out conv-float-s32.0.in > net encfilter.rpm1 conv-float-s32.0.out enc0.in > > net encoderfilter-1 enc0.out enc1.in > conv-s32-float.3.in > net encoderfilter-11 conv-s32-float.3.out sum01.in0 # link > output > net encoderfilter-2 enc1.out enc2.in > conv-s32-float.2.in > net encoderfilter-22 conv-s32-float.2.out sum01.in1 # link > output > net encoderfilter-3 enc2.out enc3.in > conv-s32-float.1.in > net encoderfilter-33 conv-s32-float.1.out sum23.in0 > net encoderfilter-4 enc3.out conv-s32-float.0.in > net encoderfilter-44 conv-s32-float.0.out sum23.in1 # link > output > net encoderfilter-5 sum01.out sumenc.in0 # put > it all together > net encoderfilter-6 sum23.out sumenc.in1 # put > it all together > net spndl-velocity sumenc.out # to where ever needed, > watch with > halscope > > I have not hooked sumenc.out to pid.s.feedback yet, but sumenc.out is > a heck of a lot cleaner than scaleX60's output. Mathematically it > should be 4x quieter, and its at least that much quieter on the > halscope view. It pains me to have to do all that data conversion back > & forth, it would greatly simplicate things if sample_hold was float. > Now I am going to hook it up to pid.s.feedback & see how much PGain I > can use before it starts stuttering.
Hooked up, Pgain at 500, control is stiffer than an oak timber. Stable, but too stiff as issuing a slower s command kills the motor in milliseconds! Then it has to be turned off & back on to reboot Jon's servo driver. So that will have to be a compromise unless I can restrict the pwmgen from going below 1% duty. Looks great at 2100 revs, very quiet output. My digital scope on the encoders logic A/B outputs looks pretty good, so those opto's would appear to be fast enough. Doesn't look so great at 60 rpms because a single quad value falls all the way thru it at the servo-thread rate. Need to concoct a value changed detector to trigger the sample-hold.hold's. And edge detector won't do that, but a comp of the in vs out of the first sampler might do it, but do I have to convert it back to float? Short answer is yes. This could be tricky at the addf stage. I do not want to addf an extra servo-thread delay. News at 5... > Comments? Shoot me downs? > > Cheers, Gene Heskett 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
