On Tuesday 09 December 2014 03:53:08 Karl Jacobs did opine And Gene did reply: > Hi, > new to this list with a question about G95 (units per revolution) for > lathe operation in machinekit/emc/linuxcnc 2.7.0~pre0, running on a > BeagleBone Black. G76 (threading) and G33 (synchronized motion) works > nicely and the feed speed in Z reacts to the motion.spindle-speed-in > hal signal as expected. But G95 gives me feed speeds independent of > spindle-speed-in, corresponding to a constant one revolution per > second of the spindle/encoder speed. I see motion.spindle-speed-in > changing when I command it to change, but no change in Z motion speed > (well below the speed limits). > I can rule out hardware problems of an encoder by using a hal siggen > component to drive the hal encoder inputs (Phase A and Z, counter mode) > to simulate the spindle speed signal. That must be working correctly > because G76 and G33 both give the right result (my X and Z axis > components drive a real lathe so I can watch and check the motions). > What am I doing wrong or not understanding? > Karl > The obvious question, from somebody who has not yet used that command, is did you note the last paragraph in the "user" pdf for the G95 command? Page 160 in my copy.
It doesn't say so, but I would interpret that G95 line to say that you must do a new F or S word after switching to G95, so that it can calculate the z feed needed for the speed in effect. Or perhaps an S word I have no clue if its the speed the spindle is doing or the "S"word speed in effect when these calculations take place. This relatively unlocked from the spindle speed mode would probably make me want to use a G33, which does synchronize the spindle and the carriage. This is one way sync only, and to me is ideally suited for turning to size loops, with CSS (G96) in effect. Its been my experience that CSS does not error out when the spindle is at max revs when doing small diameter stuff, so the job gets done regardless. G95 OTOH, I would assume stays at the same feed as CSS cranks up the speed which should give a pretty fine effective feed speed for the finish cuts, and not being fully synchronized, the feed pattern may not be so obvious at the end of the loop. Reading The Fine Manual I find, often leads to some experimentation & notes scribbled in the white space, on one's own hardware to fill in the gaps in what that Fine Manual does not say. ;-) That remark is not intended to be heavily sarcastic. LinuxCNC is actually one of the better documented bits of software in any linux "nitch" project I have used. So I have no trouble tipping my hat in deference and acknowledgement to the folks here who do take the time, to both answer my own questions, and even reword the stuff in the manual to help clarify. 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> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
