On Wednesday 06 May 2020 12:16:17 John Dammeyer wrote: > Hi Gene, > Thanks for the details. > However, I'm trying to learn how LinuxCNC works at the simple level. > Not with a high speed co-processor tied on the output doing the heavy > lifting. Then it becomes LinuxMESA rather than LinuxCNC and those > appear to be very different animals. > > Kind of like saying in third gear my electric bicycle makes funny > noises and doesn't go as fast as I think it should and having someone > mention their Honda 350 motorcycle has no problem with speed and > doesn't make noise in third gear. > > Now I don't own either an electric bicycle nor a Honda 350 so it's > really just an example. I do own a MESA 7i92H and expect to be able > to tie onto a hi res spindle encoder with it when I finally get the > variable speed motor mounted. > > But right now it's all about the electric bike. > <BIG GRIN> > > John > > > -----Original Message----- > > From: Gene Heskett [mailto:ghesk...@shentel.net] > > Sent: May-06-20 6:35 AM > > To: emc-users@lists.sourceforge.net > > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder > > > > On Wednesday 06 May 2020 04:41:17 John Dammeyer wrote: > > > 1000 PPR encoder turning 300 RPS (18000 RPM) will produce 300,000 > > > Hz output. At 10000 RPM it's 167 RPS or 167Khz. > > > > > > I've been reading through the LinuxCNC source code for the last > > > hour or two. If one was just using a parallel port and not > > > sophisticated external hardware the hal_parport.c code looks like > > > it reads the input at the base_period rate; say 25kHz => 40 uS. > > > > > > If you figure a standard mill running max 3000 RPM (50 RPS) then a > > > you probably need to look at the spindle encoder at least twice > > > per encoder period. At 25kHz we're seeing a ParPort task run time > > > of 40 uS. So I'd guess the max pulse size from the spindle > > > encoder has to be at least 80 uS. > > > > > > The spindle at 50 RPS uses up 20mS. Divide that by the 80uS > > > implies the largest usable encoder is 250 lines. > > > > > > Have I got that right? I've not found the spindle support code > > > yet. Only the HAL install code. > > > > > > John > > > > Neither have I John. But I've made it a rule of thumb in my builds, > > that the instant I thought of a spindle encoder, my thoughts just > > assumed that it would be read by external hardware if for no other > > reason but to remove that 1 kilohertz servo sample rate with its > > propensity for missing the higher speed events, from the equation. > > I have given base thread rates down to 27 u-secs on the D-525-MW > > boards and simply did not get the desired results on either machine > > until I put a 5i25 Superport in the pci slot. With a 50 megacycle > > sample clock, it doesn't miss a lick. > > > > Low counts from the encoder finally got the best of me on the G0704 > > so although I was proud of the disk and photo-interrupter with 268 > > slots I'd made for it, I bought a 1000 line differential output > > omron encoder from fleabay for a $21 bill, made and installed an > > extension shaft to drive it on the rear of the motor and installed > > it there, but left the index signal from the spindle intact. Wrote > > some hal code to measure the counts, and put tally switches on the > > gearshift knob to tell hal which gear it was in. > > > > That 1000 line encoder had to have a pair of $2.00 rs485 > > transceivers wired as rx only to make a single ended ttl signal out > > of it that was actually rail to rail. Worked up to about 300 rpms > > and found the opto's in the sainsmart bob were way too slow, so I > > bypassed them, works great. Where before, the 268 count encoders > > quantization noise was banging on the motor hard enough it sounded > > like every bearing in the head was square and well on its way out, > > now it runs dead silent up until when rigid tapping with a 5/16 or > > bigger tap that works the motor too hard and I hear the iron in the > > motor squeak as the 17 amp current limit setting in the pwm-servo > > amplifier kicks in. > > > > That 704's head gears are plastic, and I've no clue why I haven't > > stripped them doing rigid tapping with it, but I haven't yet. That > > spindle, originally a 2250 rpm fwd, 1100 reverse, now with Jon's > > pwm-servo driver and a shop made psu good for 125 volts and a 20 amp > > surge, now turns 3000 revs in either direction. The effective > > encoder count/scale changes with the gear shift of coarse but that > > just more hal modules to fix. > > > > The scale in high gear is a bit over 7000 counts per spindle rev, > > and is a bit over 14,000 in low gear. So at 1500 revs in low gear, > > its about 14150 counts per rev, so (1500 * 14150)/60=353750 cps into > > that 5i25 cards A/B inputs, and hasn't missed a lick yet. My optical > > disk for an index came loose and ate the opticals up so there is now > > an ats667 reading a screw glued to the side of the drawbar cap for > > an index generator. > > > > Since the gears are plastic and not molded for easy gear shifting, I > > took advantage of the tally switches and swapped the mux2 that > > changes the scale for a mux4, and did a setp for about 15 revs at > > the motor to the unused inputs, so when between gears its turning > > slowly and the gear shift is without the drama of grabbing the > > spindle and manually re-engaging the gears by hand. And the control > > response is fast enough I can change gears while its running wide > > open. > > > > I have since run out of i/o on that machine, so that 5i25 is now > > driving a 7i76D on P3, but the machine runs the same. > > > > And I am still convinced the bare parport is a bad idea. But its a > > piece of cake for the 5i25.
I think that is the point of this whole, now lengthy thread, is that they really are two different critters, and that what the pair of OP's here needs/wants to do is beyond the ability of the "sampled at 30 microsecond intervals" parport can do, so while linuxcnc can do the math, it absolutely must have something like the mesa card to collect the non-synchronized data w/o any missfires. As long as linuxcnc is issueing steps the motor can follow, its fine because it knows when it issued that step, the motor if not overloaded will do it. You and your machine can do fine work that way. But, the instant you add an encoder to any axis of that mix, which generates signals that cannot be missed if its to work RIGHT, and does it when linuxcnc isn't watching every nanosecond, then something like the mesa card that functions to count and record that stuff and then hands off the TOTALS to linuxcnc at base (or servo) thread read times becomes a basic requirement. And since the likes of a mesa card does all the base thread stuff FOR linuxcnc, no base thread is needed. And because time is the most valuable thing that linuxcnc manages, the one place where its absolutely vital to assure that a signal from the likes of a mesa card will be received by the read, acted on, and the results issued at the write at the bottom of your addf list, you MUST pay attention to the order of that list so that incoming data literally falls thru its section of the list and is ready to be written by the next write. Every time a module is listed out of order it will be working on data that may be stale, adding 1 millisecond to linuxcnc's response time for every module in that signal chain thats listed out of order in the addf list of your .hal file. That point cannot be emphasized too strongly. Its not important which axis gets processed first, but each function you compose in your hal file should be addf'd in the order the signal falls thru it. Only if that function is prepareing data for another function does function order in the addf list count. For that reason alone I put probe, home and/or limit switches at or near the top of the addf list. Threads however, are independent and an in-completed slower thread can and will be interrupted by one that runs at a faster interval. The slower thread will be resumed when the faster one is done. Side trip: My rpi4 .hal file contains a servo thread and an even slower 200 hz repeating thread I call the jog thread, which services the 100 ppr hand jog dials on the new apron. The human hand can only turn a dial slowly in terms of linuxcnc time so checking them at 200 hz is plenty fast enough to feel like real time. And I'm not pushing that pi hard enough to heat it, its running at a fixed 800 mhz. Back to this: There simply is no other way to get around the non-synchronous nature of the encoder. Sure, you can do fine machining w/o it, but the instant you need to thread a bolt or nut, you MUST know where in its rotation the spindle is, and linuxcnc cannot know that w/o the encoder. Ditto for servo's where the motors encoder by whatever signal method, and there are several, tells linuxcnc where it is at base thread if there is one, or servo by default, read intervals. Linuxcnc then calculates what to do next and issues those motion commands at the next write occurrence. If your addf's are in the proper order... 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
