My experience corroborates Peter and John’s descriptions. I tried cutting an SFM that was above the capability of the Z-axis to move, just for fun. Rather than a thread, I essentially got a bored out cylinder with some thread-like lines as a finish. So it doesn’t slow the spindle to the axis limit.
Also, when I start very close to the beginning of the part/thread, the first thread is too wide. If I back off and start .125" or so from the part it works fine, the thread is consistent. I am sure this is related to my machine acceleration limits. I may also have some issues with spindle-at-speed not tracking the encoder, but rather the VFD. I am going to experiment with that config as well and see if it helps. -Tom > On Feb 7, 2018, at 3:02 PM, John Kasunich <[email protected]> wrote: > > > > On Wed, Feb 7, 2018, at 2:35 PM, Chris Albertson wrote: >> The G33 says to do a synchronized move. This is physically impossible. >> The Z axis has some limit on it's ability to go from zero speed to the >> commanded speed. So the controller is reducing the spindle speed so as to >> match the ability of the z-axis motor. > > Minor (or maybe not) nit to pick here. G33 is NOT like other multi-axis > moves. > LinuxCNC will NOT reduce the spindle speed based on the limits of your Z axis. > You need to choose a spindle speed and thread pitch that are within the > capability of your Z axis. You also need to start far enough away from the > part that Z will be able to accelerate to match its target speed before it > starts cutting. > > A concrete example: you want to cut a 1/4"-20tpi thread (0.050" lead) at > 1000 rpm. > Your Z axis needs to be able to move at least 0.050 x 1000 = 50 ipm. If it > can't, you will get a bad thread and maybe a following error depending on how > your limits are set. In practice, you really need some margin on Z speed, at > least 10-20%. > >> ALL multi-axis moves are this way. You see it best on a milling machine >> where perhaps the z-axis is also the slowest. Say you are milling a 45 >> degree ramp that climbs upward to the left. The X motor would have to slow >> to match the max speed of the z motor. >> >> When a lathe cuts threads it is in real-life cutting a ramp. The spinach is >> turning in x-direction the carnage in z. You can only cut as fast as the >> slowest motor can move. And nether of the motors has infinite acceleration. >> >> On Tue, Jan 30, 2018 at 2:42 PM, <[email protected]> wrote: >> >>> We have CSS on and are threading with a G33 on our Emco lathe and we are >>> seeing the spindle decelerating during the cut. Seems like the spindle >>> speed should be fairly steady at a given X location during a G33 and what >>> it seems like is that the spindle is still decelerating to speed while it’s >>> in the cut rather than before the cut. >>> >>> We are rapid-ing (G0 in Z) out of the part at the center of the part (X=0) >>> and so CSS spins the spindle up to full speed as I’d expect (*) but it >>> appears that our spindle is still decelerating to speed as the next >>> threading pass is happening. We read that G33 will wait for >>> spindle-at-speed before looking for the index pulse. But our >>> spindle-at-speed signal seems to be high during the full cycle once the >>> spindle speeds up the first time. It seems like spindle-at-speed should go >>> low after rapiding out of the part as it moves to it’s next X location and >>> decelerates to it’s next speed at the cutting diameter. Or are we >>> misunderstanding spindle-at-speed when CSS is in effect? >>> >>> >>> (*) Is it normal that a G0 move also triggers CSS to spin up (or down)? >>> Seems like the trajectory planner would know where the next cutting move is >>> and not adjust the spindle speed until it needs to. In our case we are >>> rapiding out of the part at X=0 and the spindle speeds up when it doesn’t >>> really need to. >>> >>> -Tom >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Emc-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-users >>> >> >> >> >> -- >> >> Chris Albertson >> Redondo Beach, California >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Emc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-users > > > -- > John Kasunich > [email protected] > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
